On 04/21/2013 07:50 AM, Daniel Cristian Cruz wrote:
>
>
>
> 2013/4/21 Adrian Klaver <adrian.klaver@gmail.com
> <mailto:adrian.klaver@gmail.com>>
>
> On 04/21/2013 06:37 AM, Daniel Cristian Cruz wrote:
>
> 2013/4/21 Tom Lane <tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>
> <mailto:tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>>>
>
>
> Tomas Vondra <tv@fuzzy.cz <mailto:tv@fuzzy.cz>
> <mailto:tv@fuzzy.cz <mailto:tv@fuzzy.cz>>> writes:
> > I do have a log with the memory context info printed
> after the OOM
> > killed the session - see it attached.
>
> The only thing that seems rather bloated is the
> CacheMemoryContext,
> which seems to be because the backend has cached info about
> several
> thousand tables and indexes. Given that you say there's
> 9500 relations
> in their schema, it's hard to believe that 9.2.4 is
> suddenly doing that
> where 9.2.3 didn't. I'm wondering if they've done
> something else that
> restricted the amount of memory available to a backend.
>
>
> Maybe, since I'm running the same server and top shows a RES
> size a bit
> large for idle sessions. Not so large than 9.2. Bellow is the actual
> server top.
>
>
> Just to be clear the below is for the 9.1.4 server you rolled backed to?
>
>
> Yes.
To recap for those following along, there are two different cases in
play here.
1)
Major upgrade from 9.1.4 to 9.2.4.
Used pg_upgrade
Tested on VM with 9.2.4 and no problems.
Same machine used for production server 9.1.4 and 9.2.4
When complex queries where run on production server under 9.2.4 memory
usage climbed out of control.
Unanswered questions:
a) Data set sizes between test and production machines, how do they differ?
b) What are the EXPLAIN/ANALYZE results for a query on 9.1.4, 9.2.4 test
and 9.2.4 production?
2)
Minor upgrade 9.2.3 to 9.2.4
No test server, went production to production.
Same machine.
When some combination of queries where run on 9.2.4 memory usage climbed
out of control.
>
> --
> Daniel Cristian Cruz
> クルズ クリスチアン ダニエル
>
> --
> Daniel Cristian Cruz
> クルズ クリスチアン ダニエル
--
Adrian Klaver
adrian.klaver@gmail.com