Solved. I made everything like at TS-1133 (shared memory) and restart Tirex. Now it works really fast. Greetings Tim Am 08.08.2011 22:40, schrieb Tim Alder:

Hello, During this night we rendered 23.000 Metatiles. Speed: 10.000 tiles in 3.5h. I'm happy with that. The "buffers hits" were really well at this time. This morning I restart the db-updating process (diff-import incl. expire.rb). This process can take a while. We are not seeing on munin the db-replag, so we are flying blind. :-( Greetings Tim Zitat von Peter Körner <osm-lists(a)mazdermind.de>de>:

Am 10.08.2011 13:42, schrieb Peter Körner: I also opened access to the log-files: <http://toolserver.org/~mazder/tirex-replag/logs/> You can see that it is still importing: <http://toolserver.org/~mazder/tirex-replag/logs/run.log> Peter

Am 10.08.2011 18:07, schrieb Tim Alder: I switched the maxInterval from 6 hours to 24 hours. I don't see any point in switching to daily diff files, because downloading and merging only takes 30 seconds for the 6 hours worth of diffs. We could certainly do that. I tried tirex-rendering-control but it seems to hang: osm@ptolemy:~$ tirex-rendering-control --config tirex/etc/tirex/ --debug --stop Buckets cmdline: (), all: (missing, dirty, bulk, background), live: (missing), want: (dirty, bulk, background) sending: bucket=dirty id=tirex-rendering-control.13304 type=stop_rendering_bucket So I think I'll better kill tirex and disable the watchdog. Peter

Am 12.08.2011 17:37, schrieb Kai Krueger: I tried so and got it to compile, but it doesn't run properly: osm@ptolemy:~/src/osm2pgsql-intarray$ ./osm2pgsql ld.so.1: osm2pgsql: fatal: libpq.so.5: open failed: No such file or directory Killed Some idea? Peter

Am 15.08.2011 14:55, schrieb Julian Picht: Well, there are some libraries installed.. Using LD_LIBRARY_PATH=/opt/ts/postgres/9.0/lib/ ./osm2pgsql works. Peter

On 08/15/2011 12:58 PM, Peter Körner wrote: Unfortunately, the first batch didn't look to promising that it was any faster. :-( The majority of the time is still spent in processing relations it seems, with a single relation taking multiple seconds to process. I will try and see if I can at some point figure out what stage of processing relations takes so long, although that would presumably require to rebuild osm2pgsql with some extra instrumentation. The second batch just crashed some 4 hours into processing and has restarted, so that won't make it any faster either... Going over pending ways WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. pending_ways failed: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. (7) Error occurred, cleaning up Somehow the postgresql server crashed. Earlier, when connecting directly to the database and trying to run some test queries, I noticed that I got some odd error messages. I can't remember the exact wording, but it was something along the line that it failed to write a temporary transaction log file. I am not sure how reproducible that error is, or if it is connected to the crash in osm2pgsql, but it may give some hints. Kai