Sorry, I answered to Tomas only...
--
Daniel Cristian Cruz
クルズ クリスチアン ダニエル
---------- Forwarded message ----------
From: Daniel Cristian Cruz <danielcristian@xxxxxxxxx>
Date: 2013/4/21
Subject: Re: Memory usage after upgrade to 9.2.4
To: Tomas Vondra <tv@xxxxxxxx>
From: Daniel Cristian Cruz <danielcristian@xxxxxxxxx>
Date: 2013/4/21
Subject: Re: Memory usage after upgrade to 9.2.4
To: Tomas Vondra <tv@xxxxxxxx>
I had the same environment, almost:
Thanks Tomas, at least I'm not so alone now...
--
Daniel Cristian Cruz
クルズ クリスチアン ダニエル
2013/4/21 Tomas Vondra <tv@xxxxxxxx>
> 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.
We had many tables, not that many, 743 right now.
It's in production for a long time and so far it was running fine, until
> 3) Is it still in test mode or in production?
the upgrade to 9.2.4.
Same here.
It was working fine in the production (exactly the same workload) for a
> 4) You seem to imply that in test mode everything worked alright, is
> that the case?
long time (few months at least).
Production is working on 9.1.4; Test environments are on 9.2.4 for some time (they use a dump from production, updated daily or at request)
Simple selects, mostly index scans, nothing complex or time consuming.
> 5) In either case, test/production, what is being done in the session(s)?
There's not a particular query that crashes, it's rather about a
combination of queries.
I can say that there is mostly simple queries, but there is more complex queries showing in the log.
I do have a log with the memory context info printed after the OOM
> 6) Is there anything in the Postgres logs that might shed light?
killed the session - see it attached.
I didn't let the OOM killer works, since I was the session killer...
Thanks Tomas, at least I'm not so alone now...
--
Daniel Cristian Cruz
クルズ クリスチアン ダニエル
Daniel Cristian Cruz
クルズ クリスチアン ダニエル