On Tue, Nov 30, 2010 at 10:12:47AM +, Florian Weimer wrote:
> * hubert depesz lubaczewski:
>
> > Now, the question is: why did it hang? Is there anything we can do to
> > make it *not* hang?
>
> It might be some general system overload issue. Try running "echo w >
> /proc/sysrq-trigger" as r
On Mon, Nov 29, 2010 at 03:57:29PM -0500, Vick Khera wrote:
> On Mon, Nov 29, 2010 at 1:23 PM, Tom Lane wrote:
> > hubert depesz lubaczewski writes:
> >> straced postmaster when the problem was happening, and I was opening new
> >> connections. strace looks like this:
> >> [ backend hangs on semo
* hubert depesz lubaczewski:
> Now, the question is: why did it hang? Is there anything we can do to
> make it *not* hang?
It might be some general system overload issue. Try running "echo w >
/proc/sysrq-trigger" as root the next time it happens. This will dump
kernel backtraces to dmesg, whic
On Tue, Nov 30, 2010 at 10:20 AM, Craig Ringer
wrote:
> On 11/30/2010 03:28 PM, Dusan Misic wrote:
>
>>We're having similar issues on 8.4.[245]... occasionally psql takes
>>anywhere from a few to several dozen seconds to connect. I've been
>>unsuccessfully trying to blame spikes in the
On 11/30/2010 03:28 PM, Dusan Misic wrote:
We're having similar issues on 8.4.[245]... occasionally psql takes
anywhere from a few to several dozen seconds to connect. I've been
unsuccessfully trying to blame spikes in the OS run queue (we
desperately need some connection pooling)
On Mon, Nov 29, 2010 at 10:03 PM, Ben Chobot wrote:
> On Nov 29, 2010, at 12:57 PM, Vick Khera wrote:
>
> > On Mon, Nov 29, 2010 at 1:23 PM, Tom Lane wrote:
> >> hubert depesz lubaczewski writes:
> >>> straced postmaster when the problem was happening, and I was opening
> new
> >>> connections.
On Nov 29, 2010, at 12:57 PM, Vick Khera wrote:
> On Mon, Nov 29, 2010 at 1:23 PM, Tom Lane wrote:
>> hubert depesz lubaczewski writes:
>>> straced postmaster when the problem was happening, and I was opening new
>>> connections. strace looks like this:
>>> [ backend hangs on semop immediately a
On Mon, 2010-11-29 at 15:57 -0500, Vick Khera wrote:
> On Mon, Nov 29, 2010 at 1:23 PM, Tom Lane wrote:
> > hubert depesz lubaczewski writes:
> >> straced postmaster when the problem was happening, and I was opening new
> >> connections. strace looks like this:
> >> [ backend hangs on semop immed
On Mon, Nov 29, 2010 at 1:23 PM, Tom Lane wrote:
> hubert depesz lubaczewski writes:
>> straced postmaster when the problem was happening, and I was opening new
>> connections. strace looks like this:
>> [ backend hangs on semop immediately after reading global/pg_database ]
>
> It looks like som
On Mon, Nov 29, 2010 at 01:23:00PM -0500, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > straced postmaster when the problem was happening, and I was opening new
> > connections. strace looks like this:
> > [ backend hangs on semop immediately after reading global/pg_database ]
>
> It lo
On Mon, Nov 29, 2010 at 01:23:00PM -0500, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > straced postmaster when the problem was happening, and I was opening new
> > connections. strace looks like this:
> > [ backend hangs on semop immediately after reading global/pg_database ]
>
> It lo
hubert depesz lubaczewski writes:
> straced postmaster when the problem was happening, and I was opening new
> connections. strace looks like this:
> [ backend hangs on semop immediately after reading global/pg_database ]
It looks like something had exclusive lock on the database that new
connect
hi,
got (another time, it's not the first thing) this situation:
1. server: 64gb of ram, 24 cores of xeon processors (hyperthreading is off),
storage is fusion io.
2. at one point load skyrocketed to 48 (i know, it's not high with this
hardware)
3. we were not able to connect to PostgreSQL from ps
13 matches
Mail list logo
