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