Re: Cpu usage 100% on slave. s_lock problem.

From: Дмитрий Дегтярёв <degtyaryov(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Cpu usage 100% on slave. s_lock problem.
Date: 2013-09-17 11:55:01
Message-ID: CAFcrtwHU_iEfhoz-atgNXwVsw=3F4k8x5hfsrAxtB=ftOnWYBw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hello.

We have not been able to reproduce this problem on a test servers. Use this
patch to production servers do not dare.

In the course of studying the problems we have identified that many queries
are executed on the slave several times slower. On master function
heap_hot_search_buffer execute 100 cycles, on the slave the same query with
the same plan function heap_hot_search_buffer execute 2000 cycles.
Also, we were able to reproduce the problem on the master and detect that
there s_lock of slow queries.

We have solved this problem. A large number of queries used 4 frequently
changing index. In these indexes, 99% of the dead tuples. Autovacuum and
even VACUUM FULL these tuples can not be removed because of
autovacuum_freeze_max_age.

We've added cron that 2-3 times a day, performs CREATE INDEX CONCURRENTLY
idx_name_new; DROP INDEX CONCURRENTLY idx_name; ALTER INDEX idx_name_new
RENAME TO idx_name; for this 4 indexes.

As a result s_lock not exists in listed perf top.

2013/8/29 Merlin Moncure <mmoncure(at)gmail(dot)com>

>
> so -- are you in a position where you might be able to test this patch?
>
> merlin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Andres Freund 2013-09-17 11:59:26 Re: Cpu usage 100% on slave. s_lock problem.
Previous Message Robert Haas 2013-09-16 23:40:28 Re: function execute on v.9.2 slow down