Thanks for the refs & links - some useful stuff there...<br><br>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.<br>Thanks for those references. I've upped it to 128MB and shared_memory to a conservative 64MB (from 28MB) but the same result.<br>
(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)<br>
<br><br>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.<br>
<br><br>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)<br>
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.<br><br>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). <br>
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?<br>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)<br>
<br>I've now switched to Asia. If I'm right with the above paragraph, it will probably fail with India but not China<br>(China has lots of cities but a large number are not matched with road data, so they are skipped)<br>
So far it is running okay, but it has only reached Armenia...<br><br><br>Thanks for the suggestions - they are helping!<br><br>Richard<br><br><br><div class="gmail_quote">On Mon, Feb 28, 2011 at 9:11 PM, Stephen Woodbridge <span dir="ltr"><<a href="mailto:woodbri@swoodbridge.com">woodbri@swoodbridge.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On 2/28/2011 8:54 PM, Richard Marsden wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Thanks for the reply and suggestions.<br>
<br>
Well I have now run the same script but with just one thread/process. I<br>
would have expected this to have worked if it was a "bulk" out of memory<br>
problem (only one pgRouting process running). It failed. Also with<br>
better diagnostics of my I own, I tried to recreate the SQL statements<br>
on the command line - unfortunately these worked!<br>
<br>
I have been using the System Monitor for a while. Previously this showed<br>
it hitting swap memory occasionally , so I've bumped the machine memory<br>
from 4GB to 8GB, and it hasn't done since.<br>
(Yes this is running 32 bit mainly because PostGIS is 32 bit, but I<br>
</blockquote>
<br></div>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
understand modern Linux has a way to handle more memory (but limited per<br>
process) - and it was using the full 4GB). I do note that it does not<br>
appear to have gone beyond a full 4GB (+ephemera) memory usage.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<div class="im"><br></div></blockquote><div><br><br><useful stuff deleted for brevity - no need to repeat!><br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hope this helps,<br>
-Steve<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
Otherwise it is difficult to watch with top or the system monitor<br>
because so far it has had to run a while (hours) before the crash occurs.<br>
<br>
<br>
I guess as a kludgy workaround I could try trapping the client error,<br>
wait, and skip (or try again). This should work for a single thread, but<br>
might pose problems for my multi-threaded app. That's the problem when<br>
the server dies - all client threads have trouble until it restarts.<br>
<br>
<br>
Richard Marsden<br>
<br></div></blockquote></blockquote></div><br>