On Sat, Jun 3, 2017 at 1:51 AM, Mengxing Liu <liu-m...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
