On Sat, Jun 3, 2017 at 1:51 AM, Mengxing Liu
<liu-mx15@mails.tsinghua.edu.cn> wrote:
> I tried 30 cores. But the CPU utilization is about 45%~70%.
> How can we distinguish where the problem is? Is disk I/O or Lock?
A simple way is to run `vmstat 1` for a bit during the test. Can
you post a portion of the output of that here? If you can configure
the WAL directory to a separate mount point (e.g., use the --waldir
option of initdb), a snippet of `iostat 1` output would be even
better.
I think the best thing may be if you can generate a CPU flame graph
of the worst case you can make for these lists:
http://www.brendangregg.com/flamegraphs.html IMO, such a graph
highlights the nature of the problem better than anything else.
> Does "traversing these list" means the function "RWConflictExists"?
> And "10% waiting on the corresponding kernel mutexes" means the
> lock in the function CheckForSerializableIn/out ?
Since they seemed to be talking specifically about the conflict
list, I had read that as SerializableXactHashLock, although the
wording is a bit vague -- they may mean something more inclusive.
> If I used 30 cores for server, and 90 clients, RWConflictExists
> consumes 1.0% CPU cycles, and CheckForSerializableIn/out takes 5%
> in all.
> But the total CPU utilization of PG is about 50%. So the result
> seems to be matched.
> If we can solve this problem, we can use this benchmark for the
> future work.
If you can get a flame graph of CPU usage on this load, that would
be ideal. At that point, we can discuss what is best to attack.
Reducing something that is 10% of the total PostgreSQL CPU load in a
particular workload sounds like it could still have significant
value, although if you see a way to attack the other 90% (or some
portion of it larger than 10%) instead, I think we could adjust the
scope based on those results.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/