Re: Causeless CPU load waves in backend, on windows, 9.5.5 (EDB binary).

From: "Rader, David" <davidr(at)openscg(dot)com>
To: Nikolai Zhubr <n-a-zhubr(at)yandex(dot)ru>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Causeless CPU load waves in backend, on windows, 9.5.5 (EDB binary).
Date: 2017-02-13 20:58:54
Message-ID: CAABt7R6dzMkxZK0ORhfv-Zm2eHPOXppc9tqF40TKxtgry37Hdw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

How about using pg_isready?
https://www.postgresql.org/docs/current/static/app-pg-isready.html

--
David Rader
davidr(at)openscg(dot)com

On Sun, Feb 12, 2017 at 12:23 PM, Nikolai Zhubr <n-a-zhubr(at)yandex(dot)ru> wrote:

> Hello all,
>
> In order to locate the problem more precisely, I'd like to prepare a test,
> involving some ping-like communication between the server and a test
> client. That is, I'd like to repeatedly send something valid to the server
> and get some valid replies from it, but without any kind of real activity
> happening on the server. I've looked through the main loop in
> PostgresMain() but could not find any suitable candidates.
>
> Any thoughts?
>
> Thank you.
>
> Nikolai
>
>
> 03.02.2017 16:30, I wrote:
> [...]
>
>> Ok, secure_read() is likely irrelevant too.
>>
>> I think what happened after I inserted "Sleep(15)" into secure_read() is
>> that this "Sleep(15)" was essentially added into the main "for(;;)" loop
>> of PostgresMain (through ReadCommand), introducing an artifical
>> additional CPU relaxation step along with every incoming query and
>> therefore just masking a real CPU eater.
>>
>> So probably I'll have to somehow profile this "for(;;)" in PostgresMain.
>>
>>
>> Thank you.
>>
>> Nikolai
>>
>>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2017-02-13 21:13:53 Re: Postgres
Previous Message David Hinkle 2017-02-13 20:43:10 Re: Bad planning data resulting in OOM killing of postgres