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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
