Quoting Kai Krueger <kakrueger@gmail.com>:
> 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