27.02.2017 10:08, I wrote: [...]
So, what I've observed is that Wait* functions _usually_ go to sleep nicely when the state is not signalled, but _sometimes_, depending on unknown criteria, it can choose to instead do a busy-loop wait or something CPU-expensive. Maybe it tries to optimize the delay, or maybe it is a bug. The effect somewhat varies depending on windows version, CPU cores, selected system timer frequency, and Wait* call pattern (frequency). I can not currently see how it can be fixed in a generic and reliable way in postgres without sacrificing some performance. On the other hand, leaving it as-is is exposing the server to a substantial CPU abuse (even unintentional, as it initially happened in my case).
Ok, I've finally found what happened. False alarm, in short. The server is perfectly fine.
My mistake was that I was using most basic ways of monitoring CPU load, i.e. provided by GetProcessTimes() and taskmgr.exe and such. And because they only operate at the scheduler granularity (usually 16ms approx), some rounding has to happen in cpu consumption calculation. With this approach, this rounding can apparently distort the measurement dramatically (in some corner cases).
Now, xperf employs a more fair approach to cpu consumption measurement, based on all the exact times of process switching-in and -out, which apparently gives a much better result.
So, in my case the results of taskmgr and xperf are very different, and considering the above, taskmgr's report should be dismissed as bogus. And xperf indicates that my stress-tests actually do not cause postgres backend process to consume any noticable cpu percentage al all. That's good.
Regards, Nikolai
Regards, Nikolai
-- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
