Hi, we got a report of (probably) the same issue on a local mailing list. Maybe it'll help in finding the root cause, so I'm resending the info here too. On 21.4.2013 01:19, Adrian Klaver wrote: > On 04/20/2013 04:08 PM, Daniel Cristian Cruz wrote: >> I think I didn't make it clear: the session memory usage is growing up >> too fast, until all server memory got used and swap occurs. >> >> Never saw something like that. The version is under a test enviroment >> for a long time... >> >> Thanks if someone could help me. > > Before any one can help I would think more information is needed; > > 1) Is it on the same machine/OS as the old version? Yes. This was an upgrade from 9.2.3 to 9.2.4, so this was the usual minor upgrade procedure - stop, install 9.2.4 package, start. AFAIK there was no other change (e.g. update of kernel). > 2) What are the hardware specs for the machine? 32GB of RAM, 6 cores. I don't know which linux distribution they run. The interesting part is they have a lot of tables due to a partitioned schema. In total there's ~9500 tables. > 3) Is it still in test mode or in production? It's in production for a long time and so far it was running fine, until the upgrade to 9.2.4. > 4) You seem to imply that in test mode everything worked alright, is > that the case? It was working fine in the production (exactly the same workload) for a long time (few months at least). > 5) In either case, test/production, what is being done in the session(s)? Simple selects, mostly index scans, nothing complex or time consuming. There's not a particular query that crashes, it's rather about a combination of queries. > 6) Is there anything in the Postgres logs that might shed light? I do have a log with the memory context info printed after the OOM killed the session - see it attached. Tomas
Attachment:
crash.log.gz
Description: application/gzip
-- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
