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 /home/project/o/s/m/osm/tools/diff-import/load-next (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.
Peter
Am 19.11.2010 11:58, schrieb River Tarnell:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
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.
- river.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD)
iEYEARECAAYFAkzmWEkACgkQIXd7fCuc5vLqAQCguzjEGzMXZTcRfQFKKISsw0hI 8ggAoMDmU+HOp4VPZBIp9SBuWrdY/Ua7 =TpV4 -----END PGP SIGNATURE-----
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l