Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks

Поиск
Список
Период
Сортировка
От Emre Hasegeli
Тема Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks
Дата
Msg-id op.wtx4iqq3k2xoe5@hasegeli.local
обсуждение исходный текст
Ответ на PostgreSQL 9.2.3 performance problem caused Exclusive locks  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks
Список pgsql-performance
On Thu, 14 Mar 2013 06:53:55 +0200, Jeff Janes <jeff.janes@gmail.com>
wrote:

> On Friday, March 8, 2013, Emre Hasegeli wrote:
>
> PostgreSQL writes several following logs during the problem which I never
>> saw before 9.2.3:
>>
>> LOG:  process 4793 acquired ExclusiveLock on extension of relation
>> 305605
>> of database 16396 after 2348.675 ms
>>
>
> The key here is not that it is an ExclusiveLock, but rather than it is
> the
> relation extension lock.  I don't think the extension lock is ever held
> across user-code, or transaction boundaries, or anything like that.  It
> is
> held over some small IOs.  So if it blocked on that for over 2 seconds,
> you
> almost surely have some serious IO congestion.
>
> And this particular message is probably more a symptom of that congestion
> than anything else.
>
> You said you rolled back to 9.2.2 and the stalling is still there.  Are
> you
> still seeing the log message, or are you now seeing silently stalls?  Did
> you roll back all other changes that were made at the same time as the
> upgrade to 9.2.3 (kernel versions, filesystem changes/versions, etc.)?

I did not try with different kernel or file system. It was not because of
9.2.3, same problem occurred in both 9.2.2 and 9.2.3. Increasing max
connections make it worse. It lasts almost 15 minutes in the last time.

There were not much disk utilization while it is happening, "top" was
pointing out most of the CPU usage on the %sy column, there were no IO
wait.
I saw "allocstalls" increasing on "atop". There were a lot of slow insert
statements in the logs except ExclusiveLock waits.

We were using 64 GiB of shared buffers. RhodiumToad suggested to reduce it
on the IRC channel. It did not happen since then.

It was a real problem for us. I could not find anything related to it. I
cannot let it happen again on the production environment but I would be
happy to share more experience, if it would help you fix it.


В списке pgsql-performance по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: PostgreSQL 9.2.3 performance problem caused Exclusive locks
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: New server setup