On Tue, Feb 14, 2017 at 5:28 AM, Nikolai Zhubr <n-a-zhubr@xxxxxxxxx> 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.
relevant call is PQping:
| rv = PQpingParams(keywords, values, 1); |
