Univention Bugzilla – Bug 29582
UMC-Webserver: many select() poll() timeouts
Last modified: 2023-06-09 16:26:52 CEST
Ein strace -f -p $(pgrep -f univention-management-console-web-server) zeigt sehr viele poll() und select()-Aufrufe, mit sehr kleinen Timeout-Werten: [pid 2426] select(0, NULL, NULL, NULL, {0, 100000} <unfinished ...> [pid 2427] select(0, NULL, NULL, NULL, {0, 100000} <unfinished ...> [pid 2428] <... select resumed> ) = 0 (Timeout) [pid 2428] gettimeofday({1354777313, 743284}, NULL) = 0 [pid 2428] select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) [pid 2428] gettimeofday({1354777313, 794804}, NULL) = 0 [pid 2428] select(0, NULL, NULL, NULL, {0, 50000} <unfinished ...> [pid 2426] <... select resumed> ) = 0 (Timeout) [pid 2426] gettimeofday({1354777313, 802617}, NULL) = 0 [pid 2426] select(0, NULL, NULL, NULL, {0, 100000} <unfinished ...> [pid 2427] <... select resumed> ) = 0 (Timeout) [pid 2427] select(0, NULL, NULL, NULL, {0, 100000} <unfinished ...> [pid 2428] <... select resumed> ) = 0 (Timeout) [pid 2428] gettimeofday({1354777313, 845738}, NULL) = 0 [pid 2428] select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) [pid 2428] gettimeofday({1354777313, 897524}, NULL) = 0 [pid 2428] select(0, NULL, NULL, NULL, {0, 50000} <unfinished ...> [pid 2426] <... select resumed> ) = 0 (Timeout) [pid 2427] <... select resumed> ) = 0 (Timeout) [pid 2427] select(0, NULL, NULL, NULL, {0, 100000} <unfinished ...> [pid 2426] gettimeofday({1354777313, 903995}, NULL) = 0 [pid 2426] select(0, NULL, NULL, NULL, {0, 100000} <unfinished ...> [pid 2428] <... select resumed> ) = 0 (Timeout) [pid 2428] gettimeofday({1354777313, 948896}, NULL) = 0 [pid 2428] select(0, NULL, NULL, NULL, {0, 50000}^C <unfinished ...> Das ist ein Zeichen schlechten Designs, da der ständig laufende Prozeß dadurch unnötig Ressourcen verbraucht, was insbesondere auf Laptop zu erhöhtem Stromverbrauch führt. Hier sollte mal untersucht werden, ob man das dem UMC-Web-Server nicht abgewöhnen kann.
Wahrscheinlich in UMCP_Dispatcher.check_queue() in Verbindung mit python-notifier?
python-notifier ist die Ursache, weil hier mit einem eigenen Dispatcher für das check_queue gearbeitet wird, wartet die Mainloop nicht via select bis zum nächsten Timerevent bzw. Socketevent, sondern ruft den Dispatcher regelmäßig auf.
Mit Bug 31752 sollte das Problem dann eigentlich behoben sein, oder?
(In reply to Alexander Kläser from comment #3) > Mit Bug 31752 sollte das Problem dann eigentlich behoben sein, oder? No, of course not. The problem is notifier, not (py)inotify.
You can set dispatch.MIN_TIMER to a higher number of seconds. It wouldn't "fix" the problem but reduce the number of interrupted select calls. A "real" solution would require to remove the dipatcher.
python-notifier has also a twisted implementation. Maybe the notifier.GENERIC implementation can be replaced by notifier.TWISTED (if this doesn't interfere with cherrypy). At least the module processes could use this.
It is still using much resources with UCS 4.2.
(In reply to Florian Best from comment #7) > It is still using much resources with UCS 4.2. To be honest: the problem ist not pynotifier but the way we implemented univention-management-console-web-server. u-m-c-w-s registers a dispatching function (similar to a recurring timer that triggers every 50ms or 100ms). If u-m-c-w-s wants to get called every 50ms to 100ms, pynotifier has to wakeup that often. Btw: has anyone measured the impact of waking up every 10/20 times per second? I think on a server system this is nearly irrelevant since u-m-c-w-s usually has nothing to do and jumps to the next select() call.
This still is the case and makes `strace`ing UMC-web-server nearly impossible.
This will be fixed when switching to the UMC implementation in Bug #43633.
obsolete by Bug #43633 *** This bug has been marked as a duplicate of bug 43633 ***