[pgrouting-dev] SSL SYSCALL error: EOF detected

[Stephen Woodbridge]

On 2/25/2015 10:18 AM, Luís de Sousa wrote:
> Hi Steve,
>
> I am sorry if I did not make this clear before: PyWPS is running on a
> different server. Postgres and pgRouting run on a dedicated server; it
> is always a postgres process taking up the RAM.

You may have and I may have forgotten :)

Anyway, try using pgr_trsp() and see if it happen with that.

Tell me about the postgresql server:

What OS/Distribution?
Are you using pgrouting installed from a package or compiled from source?

select * from pgr_version();
"2.0.0";"pgrouting-2.0.0";"78";"abde224";"develop";"1.46.1"

My version is built from source and the "develop" branch using Boost 
v1.46.1 with 78 commits ahead of master.

Since pgr_trsp uses different code from pgr_dijkstra I would not expect 
to see the same behavior.

-Steve

> Thank you,
>
> Luís
>
> On 25 February 2015 at 15:56, Stephen Woodbridge
> <woodbri at swoodbridge.com> wrote:
>> Luis,
>>
>> Have tried running this query using pgr_trsp() instead of pgr_dijkstra()
>>
>> SELECT seq, id1 AS node, id2 AS edge, cost, ST_AsGeoJSON(b.the_geom)
>> FROM pgr_trsp('
>>             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)
>>
>> If this leaks the same way then I'm guessing the issue is with psycopg2 or
>> how you are calling it. I have not used python interface to pg but in other
>> languages the pattern looks like:
>>
>> connect to database
>> prepare a query
>> execute the query
>> loop through the results
>> free the results     <=======   **** this is a leak if not done ****
>> loop back to prepare or execute
>> disconnect from database
>>
>> Q: have you watched the processes in top? is the postgres process growing in
>> size or is it the python or apache or other process that is consuming all
>> the memory?
>>
>> If some other process consumes all the memory then postgres will fail when
>> it needs memory because there is none available.
>>
>> -Steve
>>
>>
>> On 2/25/2015 4:28 AM, Luís de Sousa wrote:
>>>
>>> Just as an addendum, the network tables in this schema sum up to less
>>> than 34 Mb:
>>>
>>> # SELECT sum(c.relpages) * 8
>>>     FROM pg_class c,
>>>          pg_namespace n
>>>    WHERE c.relnamespace = n.oid
>>>      AND n.nspname LIKE 'lux_2po_2169'
>>>      AND c.relname LIKE 'ways%';
>>>    ?column?
>>> ----------
>>>       33952
>>> (1 row)
>>>
>>> Thank you,
>>>
>>> Luís
>>>
>>> On 25 February 2015 at 10:06, Luís de Sousa <luis.a.de.sousa at gmail.com>
>>> wrote:
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> pgrouting-dev mailing list
>>> pgrouting-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>>
>>
>> _______________________________________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>