Re: Postgres Replaying WAL slowly
От | Jeff Frost |
---|---|
Тема | Re: Postgres Replaying WAL slowly |
Дата | |
Msg-id | 8DA8C140-818D-4184-AAE6-CA37278B983C@pgexperts.com обсуждение исходный текст |
Ответ на | Re: Postgres Replaying WAL slowly (Soni M <diptatapa@gmail.com>) |
Ответы |
Re: Postgres Replaying WAL slowly
Re: Postgres Replaying WAL slowly |
Список | pgsql-performance |
On Jun 30, 2014, at 10:29 AM, Soni M <diptatapa@gmail.com> wrote:
On Tue, Jul 1, 2014 at 12:14 AM, Andres Freund <andres@2ndquadrant.com> wrote:My guess it's a spinlock, probably xlogctl->info_lck via
RecoveryInProgress(). Unfortunately inline assembler doesn't always seem
to show up correctly in profiles...
What worked for me was to build with -fno-omit-frame-pointer - that
normally shows the callers, even if it can't generate a proper symbol
name.
Soni: Do you use Hot Standby? Are there connections active while you
have that problem? Any other processes with high cpu load?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
It is96.62% postgres [.] StandbyReleaseLocksas Jeff said. It runs quite long time, more than 5 minutes i thinki also use hot standby. we have 4 streaming replica, some of them has active connection some has not. this issue has last more than 4 days. On one of the standby, above postgres process is the only process that consume high cpu load.
compiled with -fno-omit-frame-pointer doesn't yield much more info:
76.24% postgres [.] StandbyReleaseLocks
2.64% libcrypto.so.1.0.1e [.] md5_block_asm_data_order
2.19% libcrypto.so.1.0.1e [.] RC4
2.17% postgres [.] RecordIsValid
1.20% [kernel] [k] copy_user_generic_unrolled
1.18% [kernel] [k] _spin_unlock_irqrestore
0.97% [vmxnet3] [k] vmxnet3_poll_rx_only
0.87% [kernel] [k] __do_softirq
0.77% [vmxnet3] [k] vmxnet3_xmit_frame
0.69% postgres [.] hash_search_with_hash_value
0.68% [kernel] [k] fin
However, this server started progressing through the WAL files quite a bit better before I finished compiling, so we'll leave it running with this version and see if there's more info available the next time it starts replaying slowly.
В списке pgsql-performance по дате отправления: