-- David Rader dav...@openscg.com On Tue, Feb 14, 2017 at 5:28 AM, Nikolai Zhubr <n-a-zh...@yandex.ru> wrote:
> 14.02.2017 12:47, John R Pierce: > >> On 2/13/2017 11:03 PM, Nikolai Zhubr wrote: >> >>> Now I'd like to locate a CPU eater more precisely - supposedly there >>> is some issue with communication, that is why I don't want to mix in >>> anything else. >>> >> >> use iperf to test the network transport layer, without any postgres in >> the loop? >> > > No, the network performance in general is fine. However, some specific > continuous communication pattern causes something to go very wrong on > windows periodically. (And there is no such problem on linux btw) While the > issue now seems rather related to windows itself and not postgres, but the > pattern typical for some of my postgres uses is apparently a reliable > trigger. Therefore, I'm thinking to first isolate the problem inside > postgres, and if it still triggers then, second step, create a test > "server" consisting of communication code of postgres to run without any > other parts of postgres. > > > Regards, > Nikolai > > > >> >> > Try the libpq call from pg_isready. It does actually make a round trip to the postgres server and asks the server if it is ready to accept connections. So you are running the socket communication code of postgres and a small bit of "status" check but not any sql. from mirror: https://github.com/postgres/postgres/blob/master/src/bin/scripts/pg_isready.c relevant call is PQping: rv = PQpingParams(keywords, values, 1);
