Re: Would like to know how analyze works technically

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: TonyS <tony(at)exquisiteimages(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Would like to know how analyze works technically
Date: 2015-04-01 13:34:46
Message-ID: 2120305478.2856813.1427895286278.JavaMail.yahoo@mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

TonyS <tony(at)exquisiteimages(dot)com> wrote:

> The postgresql log has these entries at the crash point:
> 2015-04-01 06:24:37 EDT LOG: server process (PID 1384) was terminated by signal 9: Killed
> 2015-04-01 06:24:38 EDT DETAIL: Failed process was running: analyze verbose;

That was almost certainly the action of the OS's Out Of Memory
Killer process.

> Is there anything else that would be helpful?

Unfortunately, leaving the OOM killer enabled causes the best
evidence to be destroyed. If you disable the OOM killer and run
this again, when memory is exhausted the database process
attempting to allocate memory will dump a map of where its memory
was allocated. That should give us something to work with
regarding the cause. Try:

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

Also, it would be useful to see the output of this:

SELECT name, current_setting(name), source
FROM pg_settings
WHERE source NOT IN ('default', 'override');

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rémi Cura 2015-04-01 13:40:41 partitoning expert : Partitonning with specialization of one column type
Previous Message Igor Neyman 2015-04-01 13:32:09 Re: how would you speed up this long query?