03.02.2017 13:52, I wrote:
[...]
> Adding this "Sleep(15)" before "goto retry" into secure_read() has
> apparently eliminated the effect at our production server too. That is,
> my load-bug-detector has been quiet for > 24hr or more.
>
> Now by adding more debigging stuff into secure_read() and secure_write()
> I've found that:
>
> * secure_write() is likely irrelevant, as "goto retry" there was never
> actually hit yet;
>
> * in secure_read(), during the intervals of excessive cpu load,
> WaitLatchOrSocket() was never observed to indicate latch event, and was
> never observed to (erroneously) indicate socket readiness more than once
> (with socket read attempt in between), which I was suspecting happening,
> so I can not blame secure_read() itself and this all makes me wonder
> even more...
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
>
> Note: I'm testing with SSL off now.
>
> As always, and hints greatly appreciated!
>
>
> Thank you.
> Nikolai
>
>>
>> --- be-secure.c.orig 2017-02-01 22:37:37.228032608 +0300
>> +++ be-secure.c 2017-02-01 22:51:17.655751292 +0300
>> @@ -159,6 +159,7 @@
>> * socket to become ready again.
>> */
>> }
>> + Sleep(15); /* n.zhubr */
>> goto retry;
>> }
>>
>> @@ -238,6 +239,7 @@
>> * socket to become ready again.
>> */
>> }
>> + Sleep(15); /* n.zhubr */
>> goto retry;
>> }
>>
>>
>> Thank you.
>>
>> Nikolai
>>
>>>
>>>
>>> Thank you.
>>>
>>> Nikolai
>>>
>>>>
>>>> Regards,
>>>>
>>>> Andres
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
