On 12/6/2013 11:04 AM, 吕晓旭 wrote:
I find something with top : CPU usage of each postgres process is not so high when low concurrency, the highest one is about 50%.
but when concurrency gradually increased, some postgres process cpu usage reach 100%, and keep a moment. and at these high concurrency period runq-sz(with sar -q) is very long, sometime 50 process waiting the CPU time.
so is there something like spin-lock keep the CPU time?
some configurations on the both system:
shared_buffers = 8192MB
work_mem =256MB
maintenance_work_mem = 160MB
full_page_writes = off
wal_buffers = 10MB
wal_keep_segments = 150
50 concurrent active queries with work_mem = 256MB would use like 13GB ram, or possibly more if the queries are complex and require multiple work_mems. I see you have 64GB ram on the 'slow' system, so that /shouldn't/ be an issue, unless you end up with much higher concurrent query counts.
seems to be a lot of variables here, one system is running CentOS 5.x and the other CentOS 6.x, if I remember correctly from your first post. different memory sizes. different disk controllers. both CentOS versions are quite out of date (5.7 and 6.5 are both direct inplace upgrades). I also recall CentOS 6.2 had some file system bugs relating to XFS, but I dunno if that applies here. hmmmm, kernel 3.2.34 ? thats not the centos 6.2 kernel, where is it from ?
btw, those CPUs have 12 threads, not 24
--
john r pierce 37N 122W
somewhere on the middle of the left coast