I'm sorry I hadn't had any time for these and many other things, but I
got a lot to do at and it will stay that way some weeks like that.
I disabled the tile expiry so that the server can catch up with the tile
queues. Our expiry plan was like that:
re-render z0-6 on the 1st of each month
expire z7-9 on the 1st of each month
expire z10 on the 8th and 22th of each month
expire z11 each sunday at 20 o' clock
expire z12 each sunday at 20 o' clock
expire z13-18 during the database import as the data changes
I disabled everything now. All of this can be managed in the crontab of
the osm project on ptolemy except the expire-on-change which is
controlled by a section in
(look for "expiring tiles").
All these rules are just guesses and it seems they were not so good, so
if anyone has a better plan, please post it.
Am 19.11.2010 11:58, schrieb River Tarnell:
-----BEGIN PGP SIGNED MESSAGE-----
As I understand it, our database/tile server (ptolemy) is higher spec than the
equivalent hardware at OSM.org
, yet it performs much worse (e.g. at rendering
tiles). Is this correct?
If so, has anyone compared the indices on ptolemy's database to OSM's?
If that is not the problem, I would like to test performance without VxVM
between the filesystem and the disk. While Vx doesn't hurt performance with
MySQL, I noticed during testing that it significantly reduced import
performance with Postgres. I believe that was fixed by putting pg_xlog on a
separate (non-Vx) disk, but it may still be hurting read performance.
Testing this will require some downtime for conversion; based on the amount of
data, I would estimate about 8 hours to copy the data off and back again.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (FreeBSD)
-----END PGP SIGNATURE-----
Maps-l mailing list