On Tue, Dec 2, 2014 at 5:07 PM, Xiaoyulei <xiaoyulei(at)huawei(dot)com> wrote:
> Test configuration:
> Hardware:
> 4P intel server, 60 core 120 hard thread.
> Memory:512G
> SSD:2.4T
>
> PG:
> max_connections = 160 # (change requires restart)
> shared_buffers = 32GB
> work_mem = 128MB
> maintenance_work_mem = 32MB
> bgwriter_delay = 100ms # 10-10000ms between rounds
> bgwriter_lru_maxpages = 200 # 0-1000 max buffers written/round
> bgwriter_lru_multiplier = 2.0 # 0-10.0 multipler on buffers scanned/round
> wal_level = minimal # minimal, archive, or hot_standby
> wal_buffers = 256MB # min 32kB, -1 sets based on shared_buffers
> autovacuum = off
> checkpoint_timeout=60min
> checkpoint_segments = 1000
> archive_mode = off
> synchronous_commit = off
> fsync = off
> full_page_writes = off
>
>
> We use tpcc and pgbench to test postgresql 9.4beat2 performance. And we found the tps/tpmc could not increase with the terminal increase. The detail information is in attachment.
>
> Many processes is blocked, I dump the call stack, and found these processes is blocked at: ProcArrayLock. 60% processes is blocked in ProcArrayEndTransaction with ProcArrayLock EXCLUSIVE, 20% is in GetSnapshotData with ProcArrayLock SHARED. Others locks like XLogFlush and WALInsertLock are not very heavy.
>
> Is there any way we solve this problem?
Providing complete backtraces showing in which code paths those
processes are blocked would help better in understand what may be
going on.
--
Michael