Re: SELECT outage in semop - Mailing list pgsql-performance

From Albe Laurenz
Subject Re: SELECT outage in semop
Date
Msg-id A737B7A37273E048B164557ADEF4A58B17CFF4FE@ntex2010i.host.magwien.gv.at
Whole thread Raw
In response to SELECT outage in semop  (Сурен Арустамян <suren-a@inbox.ru>)
Responses Re[2]: [PERFORM] SELECT outage in semop  (Suren Arustamyan <suren-a@inbox.ru>)
List pgsql-performance
Сурен Арустамян wrote:

> I'm using postgresql 9.3.4 on Red Hat Enterprise Linux Server release 6.5 (Santiago)
> 
> Linux 193-45-142-74 2.6.32-431.17.1.el6.x86_64 #1 SMP Fri Apr 11 17:27:00 EDT 2014 x86_64 x86_64
> x86_64 GNU/Linux
> 
> Server specs:
> 4x Intel(R) Xeon(R) CPU E7- 4870  @ 2.40GHz (40 physical cores in total)
> 
> 
> 441 GB of RAM
> 
> I have a schema when multi process daemon is setted up on the system and each process holds 1
> postgresql session.
> 
> Each process of this daemon run readonly queries over the database.
> In normal situation it at most 35 ms for queries but from time to time (at a random point of time)
> each database session hanges in some very strange semop call. Here is a part of the strace:

[...]

> 41733 20:15:09.682507 semop(393228, {{0, -1, 0}}, 1) = 0 <2.080439>

[...]

> You may see that semop took 2 seconds from the whole system call.
> Same semops could be find in other database sessions.
> 
> Could you point me how can i find

What is your PostgreSQL configuration?

Is your database workload read-only?
If not, could these be locks?
You could set log_lock_waits and see if anything is logged.

Anything noteworthy in the database server log?
How busy is the I/O system and the CPU when this happens?

Yours,
Laurenz Albe

pgsql-performance by date:

Previous
From: Сурен Арустамян
Date:
Subject: Re: SELECT outage in semop
Next
From: Suren Arustamyan
Date:
Subject: Re[2]: [PERFORM] SELECT outage in semop