From: | Thom Brown <thombrown(at)gmail(dot)com> |
---|---|
To: | Sam <sam(at)palo-verde(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Help me stop postgres from crashing. |
Date: | 2010-04-24 22:53:07 |
Message-ID: | g2xbddc86151004241553j2884fa37le5e2e8e54fd51612@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 24 April 2010 18:48, Sam <sam(at)palo-verde(dot)us> wrote:
> Hi,
>
> I am a web developer, I've been using postgesql for a few years but
> administratively I am a novice.
>
> A particular web application I am working has a staging version
> running one a vps, and a production version running on another vps.
> They both get about the same usage, but the production version keeps
> crashing and has to be re-started daily for the last couple days. The
> log file at the time of crash looks like this:
>
> LOG: could not accept new connection: Cannot allocate memory
> LOG: select() failed in postmaster: Cannot allocate memory
> FATAL: semctl(2457615, 0, SETVAL, 0) failed: Invalid argument
> LOG: logger shutting down
> LOG: database system was interrupted at 2010-04-24 09:33:39 PDT
>
> It ran out of memory.
>
> I am looking for a way to track down what is actually causing the
> memory shortage and how to prevent it or increase the memory
> available.
>
> The vps in question is a media temple DV running CentOS and postgres
> 8.1.18
>
>
> Could you provide some more information? What do you get if you run
"sysctl -a | grep kernel.shm" and "sysctl -a | grep sem"? And what are you
developing in which connects to the database? Are you using persistent
connections? And how many connections to you estimate are in use? What
have you got max_connections and shared_buffers in your postgresql.conf
file? And how much memory does your VPS have?
Thom
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-04-24 23:03:28 | Re: [GENERAL] trouble with to_char('L') |
Previous Message | Andre Lopes | 2010-04-24 20:46:51 | Lock table, best option? |