[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Maposmatic-dev] [task #10040] Gracefuly handle maposmaticd job timeouts

From: David Decotigny
Subject: [Maposmatic-dev] [task #10040] Gracefuly handle maposmaticd job timeouts
Date: Tue, 05 Jan 2010 08:52:48 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.5.6


                 Summary: Gracefuly handle maposmaticd job timeouts
                 Project: MapOSMatic
            Submitted by: daviddecotigny
            Submitted on: Tue 05 Jan 2010 08:52:47 AM GMT
         Should Start On: Tue 05 Jan 2010 12:00:00 AM GMT
   Should be Finished on: Tue 05 Jan 2010 12:00:00 AM GMT
                Category: maposmaticd
                Priority: 8
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                  Effort: 0.00



We experienced a general failure of the rendering after one ocitysmap job
(from maposmaticd) timed out. The failed job appeared to have been stuck (and
killed) in the middle of the big street_index queries, and left the
corresponding postgresql worker process eating 100% CPU.

This had the exceptional benefit of preventing any other rendering coming
afterwards to time out too. The most annoying feature of this behavior being
that, if a daily planet update appears, then it will probably take a veeeeery
long time to complete. Note that it could be too dangerous to kill the faulty
pgsql worker process eating the CPU while the update has already been started
(because in that case, I bet nothing would guarantee the consistency of the
DB, so we'd better restart the whole pgsql server and, hence, the daily
update; but I'm afraid the update process is not idempotent).

One solution we could try: instead of executing the big street_index queries
synchronously, run them asynchronously and attach a process
atexit/int/quit/term signal handler that calls pg_cancel_query. This /might/
(?) help... maybe.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]