[pgrouting-users] dijkstra_sp_delta throwing a signal 6 (SIGABRT?)

[Richard Marsden]

Thanks for the refs & links - some useful stuff there...

Oh the wonders of Linux documentation - of course all the forks and versions
don't help - the references I found to SHMMEM must have been old.
Thanks for those references. I've upped it to 128MB and shared_memory to a
conservative 64MB (from 28MB) but the same result.
(I'm also printing off those two Postgres pages about recommended
configurations, whilst I type - I'll probably adjust them further.   I have
the Apress "From Beginner to Expert" PostGres book but of course it is
cross-platform and is more interested in covering a wide range of topics
including basic SQL)


After a few runs now, I'm seeing the abort occurs at different places in
processing. Assuming that pgrouting's search through the graph is
deterministic (and I haven't seen anything to say otherwise), this suggests
the problem is not data (graph) specific.


I said "threads/processes": Python's implementation of multithreading is
broken from the multi-core processing perspective - basically there's one
giant lock on the interpreter!  Luckily the standard libraries include an
alternative which uses OS processes in a thread-like way. I'm using the
multiprocessing 'Pool' functions to implement what Google have christened
"MapReduce" across 1-3 cpus (haven't dared try 4 yet)
The problem occurs with once process as well as 3 processes, so I don't
think it is a bulk memory limit - instead it is a single process limit.

So far I've only seen the problem with Brazil (I'm batch processing
country-wide mileage charts). This is the biggest chart I've tried
(Australia was the previous largest and it wasn't that much smaller).
One thought is that it could be related to the number of calls on a
connection: perhaps a server-side garbage collector is not getting the
chance to run?  Or there's a memory leak?
The maximum number of pgRouting calls per connection is currently 2000.
Brazil is going to be in the 950-1900ish range (I first try with a small
delta. If that fails to find a route, I try a larger delta - hence the
two-fold uncertainty)

I've now switched to Asia. If I'm right with the above paragraph, it will
probably fail with India but not China
(China has lots of cities but a large number are not matched with road data,
so they are skipped)
So far it is running okay, but it has only reached Armenia...


Thanks for the suggestions - they are helping!

Richard


On Mon, Feb 28, 2011 at 9:11 PM, Stephen Woodbridge <woodbri at swoodbridge.com
> wrote:

> On 2/28/2011 8:54 PM, Richard Marsden wrote:
>
>> Thanks for the reply and suggestions.
>>
>> Well I have now run the same script but with just one thread/process. I
>> would have expected this to have worked if it was a "bulk" out of memory
>> problem (only one pgRouting process running). It failed. Also with
>> better diagnostics of my I own, I tried to recreate the SQL statements
>> on the command line - unfortunately these worked!
>>
>> I have been using the System Monitor for a while. Previously this showed
>> it hitting swap memory occasionally , so I've bumped the machine memory
>> from 4GB to 8GB, and it hasn't done since.
>> (Yes this is running 32 bit mainly because PostGIS is 32 bit, but I
>>
>
> I run Postgres on my amd64 boxes and I'm pretty sure they are all 64bit
> processes. I do not have that much memory though. I'm running Debian.
>
>
>  understand modern Linux has a way to handle more memory (but limited per
>> process) - and it was using the full 4GB). I do note that it does not
>> appear to have gone beyond a full 4GB (+ephemera) memory usage.
>>
>
> Off hand I would stay it is not good that you are running close to 4GB
> because if I recall this is one of those magic boundaries where a 32bit
> points warps back to around or overflows.
>
> Also, since you run threads all your threads are in the same process memory
> and their combined memeory can not exceed whatever the process limit is.
>
>

<useful stuff deleted for brevity - no need to repeat!>



> Hope this helps,
>  -Steve
>
>  Otherwise it is difficult to watch with top or the system monitor
>> because so far it has had to run a while (hours) before the crash occurs.
>>
>>
>> I guess as a kludgy workaround I could try trapping the client error,
>> wait, and skip (or try again). This should work for a single thread, but
>> might pose problems for my multi-threaded app. That's the problem when
>> the server dies - all client threads have trouble until it restarts.
>>
>>
>> Richard Marsden
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/pgrouting-users/attachments/20110301/e6369f0f/attachment.html