[pgrouting-dev] SSL SYSCALL error: EOF detected

[Stephen Woodbridge]

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

> Regards,
>
> Luís
>
> On 23 February 2015 at 20:01, Stephen Woodbridge
> <woodbri at swoodbridge.com> wrote:
>> Hi Luis,
>>
>> This is the easiest way to find a memory leak:
>>
>> http://blog.cleverelephant.ca/2008/08/valgrinding-postgis.html
>>
>> You only need to run one query that you think is leaking and this will
>> report what, how much and where in the code.
>>
>> -Steve
>>
>>
>>
>> _______________________________________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev