Re: Postgre Eating Up Too Much RAM - Mailing list pgsql-admin

From Scott Marlowe
Subject Re: Postgre Eating Up Too Much RAM
Date
Msg-id CAOR=d=3rg+4GdvS18DPZEu4076g5q=ZUQQscTXeAYgT5KKp+iA@mail.gmail.com
Whole thread Raw
In response to Re: Postgre Eating Up Too Much RAM  (Fernando Hevia <fhevia@gmail.com>)
List pgsql-admin
On Wed, Nov 14, 2012 at 3:51 PM, Fernando Hevia <fhevia@gmail.com> wrote:
>
>
>
> On Wed, Nov 14, 2012 at 2:30 AM, Aaron Bono <aaron.bono@aranya.com> wrote:
>>
>> On our old server, our hosting company said the server was running out of
>> RAM and then became unresponsive.  I haven't checked about the new server
>> yet.
>
>
> Unresponsive how? Can you ssh to it? Can you log to Postgres?
> For how long does it happen? Till you reboot?
> If it is a server crash then that is not a normal behavior and you should
> check your hardware. An exhaustive memory test is recommended.
>
>>
>> Is there any kind of diagnostics you can think of that would help get to
>> the root of the problem - something I could put in a cron job or a monitor
>> app I could run on the server that would at least tell us what is going on
>> if / when it happens again?
>>
>
> Increase logging on PostgreSQL. Especially log checkpoints and locks.
> While experiencing the problem and if you are able to log to the server, a
> vmstat 1 10 will tell you what is going on with your I/O system in a 10
> second span.

also turning on sysstat / sar processes is a good idea.  On linux
boxen go to /etc/default and edit the sysstat file and change the line
ENABLED="false" to ENABLED="true" then start sysstat collection with
"sudo /etc/init.d/sysstat start"

then read them with sar.  Sar's a great post-mortem analysis tool.


pgsql-admin by date:

Previous
From: Christian Kratzer
Date:
Subject: Re: Postgre Eating Up Too Much RAM
Next
From: Ronit Allen
Date:
Subject: Re: Date range for pg_stat_all_tables?