Quoting Kai Krueger <kakrueger(a)gmail.com>om>:
Hello,
...
*The rendering
of the>200 styles for the different languages make it
difficult to handle the server.
Is that still the memory issue, or did the move to tirex mitigate this?
It is more the point that it is difficult to restart tirex (waiting 15
min...).
So it makes no fun to install new styles and experiment.
The memory usage seems acceptable.
On nearly all tile servers I have seen so far, the bottleneck has
always been the I/O performance. So it wouldn't be surprising that
the read IOPS of the disks are maxed out. There are two aspects to
I/O performance. For one the postgis access and secondly tile
access. With only ca. 100 tiles/s I wouldn't think the tile access
would be a significant I/O bottleneck. Postgis on the other hand
will likely take all I/O performance it can get as long as there is
something to render.
Ok, if all requests from en.wp goes to nearly the same points on the
earth that if also have on de.wp it should work and we could do the
same trick that we use at we start at de.wp, because we know the
coordinates we could pre-render the areas. That could work.
(A upgrade to SSD's would be very
interesting for
I/O-power. I my eyes we would need only 400 GB so it shouldn't cost too
much if we could speed-up the rendering perhaps by factor 5! This would
also speed-up the other tools which uses the OSM-database. A solution by
brain-power would be off course better.)
You would presumably only want to put the
postgis-DB on an SSD? The
tiles are probably better off on larger but slower disks.
Yes, I thought about
postGIS-DB.
Greetings
Kolossos