Bug 29582 - UMC-Webserver: many select() poll() timeouts
UMC-Webserver: many select() poll() timeouts
Status: RESOLVED DUPLICATE of bug 43633
Product: UCS
Classification: Unclassified
Component: UMC (Generic)
UCS 5.0
Other Linux
: P5 enhancement (vote)
: UCS 3.x
Assigned To: UMC maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-06 08:04 CET by Philipp Hahn
Modified: 2023-06-09 16:26 CEST (History)
5 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 2: Improvement: Would be a product improvement
Who will be affected by this bug?: 5: Will affect all installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.114
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2021092721000177
Bug group (optional): UCS Performance
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Hahn univentionstaff 2012-12-06 08:04:01 CET
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.
Comment 1 Alexander Kläser univentionstaff 2012-12-06 12:53:43 CET
Wahrscheinlich in UMCP_Dispatcher.check_queue() in Verbindung mit python-notifier?
Comment 2 Sönke Schwardt-Krummrich univentionstaff 2012-12-06 12:57:09 CET
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.
Comment 3 Alexander Kläser univentionstaff 2013-07-18 18:08:52 CEST
Mit Bug 31752 sollte das Problem dann eigentlich behoben sein, oder?
Comment 4 Florian Best univentionstaff 2013-07-19 08:16:14 CEST
(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.
Comment 5 Andreas Büsching 2013-12-10 07:34:17 CET
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.
Comment 6 Florian Best univentionstaff 2014-02-04 21:57:18 CET
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.
Comment 7 Florian Best univentionstaff 2016-09-22 18:39:57 CEST
It is still using much resources with UCS 4.2.
Comment 8 Sönke Schwardt-Krummrich univentionstaff 2018-05-04 13:23:47 CEST
(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.
Comment 9 Philipp Hahn univentionstaff 2021-10-08 15:45:09 CEST
This still is the case and makes `strace`ing UMC-web-server nearly impossible.
Comment 10 Florian Best univentionstaff 2021-10-08 15:49:57 CEST
This will be fixed when switching to the UMC implementation in Bug #43633.
Comment 11 Florian Best univentionstaff 2023-06-09 16:26:52 CEST
obsolete by Bug #43633

*** This bug has been marked as a duplicate of bug 43633 ***