Re: [HACKERS] Backend memory growing too much
Hi Andrew
On Tue, 17 Jul 2007, Andrew Dunstan wrote:
Date: Tue, 17 Jul 2007 11:30:43 -0400
From: Andrew Dunstan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Backend memory growing too much
[EMAIL PROTECTED] wrote:
I don't know much about DBI/DBD but I know sqlgrey uses a lot of
prepare/prepare_cached statements.
You can inhibit DBD::Pg from using server side prepares if you need to,
by executing:
$dbh-{pg_server_prepare} = 0;
(as documented in the excellent DBD::Pg docs).
cheers
andrew
Thanks! That made the trick!
I assume this is because sqlgrey prepares statements (always the same) and
neither finish them.
Best regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: [EMAIL PROTECTED]
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[HACKERS] Backend memory growing too much
Hi everyone, I've been using sqlgrey for some time now and I'm very surprised by the memory taken by the backends to which sqlgrey is connected. look at process 4111 and 28108 . They roughly take twice the space the other backend take. Could there be a memory leak? I don't know much about DBI/DBD but I know sqlgrey uses a lot of prepare/prepare_cached statements. What could cause? shared_buffer is 400MB here. TIA -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) 2 S postgres 1610 1604 TS 80 20 0 e6c19540 107480 e6a773cc jun 29 ? 568:26 /databases/pgsql-v8.2/bin/postgres 2 S postgres 2441 1604 TS 80 20 0 e2f17fe0 107714 e33685b0 jun 29 ? 0:13 /databases/pgsql-v8.2/bin/postgres 42 S postgres 1604 1 TS 80 20 0 e6c3dfc0 107418 e69886ec jun 29 ? 8:18 /databases/pgsql-v8.2/bin/postgres 2 S postgres 1611 1604 TS 80 20 0 e6c88500 1737 e6a7723c jun 29 ? 136:30 /databases/pgsql-v8.2/bin/postgres 2 S postgres 2124 1604 TS 80 20 0 e2f17540 108188 e690a230 jun 29 ? 0:01 /databases/pgsql-v8.2/bin/postgres 2 S postgres 4111 1604 TS 80 20 0 ef1db500 256516 f73eb330 jul 15 ? 2:28 /databases/pgsql-v8.2/bin/postgres 2 S postgres 28673 1604 TS 80 20 0 d04aa540 107713 e7efc250 15:10:52 ? 0:00 /databases/pgsql-v8.2/bin/postgres 2 S postgres 28499 1604 TS 80 20 0 d9c7d500 107715 e32e0af0 15:09:31 ? 0:00 /databases/pgsql-v8.2/bin/postgres 2 S postgres 28108 1604 TS 80 20 0 d5171a60 223750 e7efb2c0 23:58:49 ? 2:18 /databases/pgsql-v8.2/bin/postgres 2 S postgres 28256 1604 TS 80 20 0 d1f5daa0 107713 de7f1480 15:06:26 ? 0:00 /databases/pgsql-v8.2/bin/postgres 2 S postgres 26463 1604 TS 80 20 0 df639fc0 107715 de52f1d0 14:40:09 ? 0:01 /databases/pgsql-v8.2/bin/postgres 2 S postgres 26464 1604 TS 80 20 0 d9c7b520 107711 e9acc9f0 14:40:09 ? 0:00 /databases/pgsql-v8.2/bin/postgres 2 S postgres 27972 1604 TS 80 20 0 e6bcdfe0 107711 e6a75dd0 15:01:10 ? 0:00 /databases/pgsql-v8.2/bin/postgres 2 S postgres 28720 1604 TS 80 20 0 dea14540 107713 e34c9c80 15:11:22 ? 0:00 /databases/pgsql-v8.2/bin/postgres ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Backend memory growing too much
[EMAIL PROTECTED] writes: I don't know much about DBI/DBD but I know sqlgrey uses a lot of prepare/prepare_cached statements. Well, those aren't exactly free. Possibly you could learn something about it by attaching to one of these backends with gdb and executing call MemoryContextStats(TopMemoryContext) This will dump a memory map to stderr. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Backend memory growing too much
[EMAIL PROTECTED] wrote:
I don't know much about DBI/DBD but I know sqlgrey uses a lot of
prepare/prepare_cached statements.
You can inhibit DBD::Pg from using server side prepares if you need to,
by executing:
$dbh-{pg_server_prepare} = 0;
(as documented in the excellent DBD::Pg docs).
cheers
andrew
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
