[pgrouting-dev] SSL SYSCALL error: EOF detected

[Luís de Sousa]

Hi again Steve,

I have ran valgrind with 4 and 10 queries, and as you expected, the
report is essentially the same (logs attached).

I have postgres crashing twice a day. The way psycopg2 opens and
maintains the connection is the only alternative suspect, but the
memory swell only takes place with the pgr_dijkstra function. Would
you have other suggestions? Or would you advise a different forum to
pose this issue?

Thank you,

Luís



On 24 February 2015 at 17:52, Stephen Woodbridge
<woodbri at swoodbridge.com> wrote:
> On 2/24/2015 9:22 AM, Luís de Sousa wrote:
>>
>> Hi Steve,
>>
>> Paul's post is bit old, things don't work exactly the way same
>> anymore, but I eventually succeeded running it (the log is attached).
>> I used this query:
>>
>> SELECT seq, id1 AS node, id2 AS edge, cost, ST_AsGeoJSON(b.the_geom)
>> FROM pgr_dijkstra('
>>            SELECT gid AS id,
>>                 source::integer,
>>                 target::integer,
>>                 to_cost::double precision AS cost,
>>                 reverse_cost::double precision
>>            FROM  lux_2po.ways',
>>            10000 ,  20000 , true, true) a LEFT JOIN  lux_2po.ways b ON
>> (a.id2 = b.gid)
>>
>> I had to feed it to valgrind from a file (without line breaks):
>>
>> $ cat query.sql  | valgrind --leak-check=yes --log-file=valgrindlog
>> /usr/lib/postgresql/9.1/bin/postgres --single -D
>> /etc/postgresql/9.1/main lamilo_routing
>>
>> If I am reading it correctly, this query left behind some 3 kb of
>> memory. Not as much as my back-of-the-envelope calculation pointed,
>> but in the same order of magnitude. It may happen that between
>> different nodes the leak is larger.
>
>
> So basically this report is very clean. I do not see any leaks from
> pgrouting. All the leaks listed are one-time leaks from the postgresql
> server so the do not accumulate on a per query basis.
>
> One thing you might try is to run your command 2-3 time from the input file.
> If you can only run one command then try "select ... union all select ...
> union all select ..." or "select ...; select ...; select ...;"
>
> So when you read the log file all the leaks that are immediately from main
> are just things that postgresql is doing when it starts up and they all go
> away when the server shuts down so not a problem. pgrouting leaks will have
> a much longer call stack associated with them.
>
> You could be running out of memory if lux_2po.ways is a hug table because
> you are loading the whole thing. We typically load ways based on a bounding
> box about the start and end points and expanding that a little. You have to
> be careful if you have a bbox the is a horizontal or vertical line and you
> need to expand that more than a diagonal line between the points.
>
> -Steve
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrindlog.4
Type: application/octet-stream
Size: 3758 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20150225/a70d6ded/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrindlog.10
Type: application/octet-stream
Size: 3762 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20150225/a70d6ded/attachment-0001.obj>