nice für X
Hauke Laging
es gibt inzwischen nice für die CPU-Priorität und ionice für die
I/O-Priorität. Nun gibt es aber auch auf höheren Ebenen eine Art
Scheduling. Ich erlebe es immer mal wieder, dass Firefox auf
bestimmten Webseiten die eigene CPU-Last und auch die des X-Servers
hochreißt, ohne dass das aus Anwendersicht gerechtfertigt ist (weil
z.B. das Fenster gar nicht zu sehen ist).
Gibt es die Möglichkeit, die Priorität, mit denen X die einzelnen
Clients behandelt, zu beeinflussen?
CU
Markus Raab
> es gibt inzwischen nice fï¿œr die CPU-Prioritï¿œt und ionice fï¿œr die
> I/O-Prioritï¿œt.
Die CPU Prioritï¿œt die du mit nice vergibst ist aber noch nicht der Wert wie
der Scheduler den Prozess tatsï¿œchlich behandelt.
Die sog. Prioritï¿œt kannst du mit schedtool betrachten.
> Nun gibt es aber auch auf hï¿œheren Ebenen eine Art
> Scheduling.
Ich weiￜ nicht genau was du meinst?
> Ich erlebe es immer mal wieder, dass Firefox auf
> bestimmten Webseiten die eigene CPU-Last und auch die des X-Servers
> hochreiï¿œt, ohne dass das aus Anwendersicht gerechtfertigt ist (weil
> z.B. das Fenster gar nicht zu sehen ist).
Manche Programme haben das Feature dass sie sich inaktiv schalten wenn sie
nicht betrachtet werden (z.b. kaffeine). Wenn es das Feature nicht hat und
z.b. ein Flashplugin massig CPU Last verbraucht ist das halt eine blï¿œde
Situation.
> Gibt es die Mï¿œglichkeit, die Prioritï¿œt, mit denen X die einzelnen
> Clients behandelt, zu beeinflussen?
Du kï¿œnntest z.b. die Flash Prozesse niedriger priorisieren um dein Problem
zu beheben. Oder ein Bugreport schreiben, dass wenn das Programm nicht
angeschaut wird, auch gefï¿œlligst nichts animieren soll.
Welche Fenster angezeigt werden und welche nicht ist afaik eher eine Sache
des Windowmanagers und nicht direkt X. Deshalb macht xnice imho eher
weniger Sinn? Wir kï¿œnnen das aber gerne diskutieren. Ich kenne auf jeden
Fall nichts in diese Richtung.
mfg Markus
--
http://www.markus-raab.org | Wenn Menschen Liebe gepredigt wird, lernen
-o) | sie nicht lieben, sondern predigen. --
Kernel 2.6.24-1-a /\ | Alice Miller
on a x86_64 _\_v |
Hauke Laging
> Die CPU Priorität die du mit nice vergibst ist aber noch nicht der
> Wert wie der Scheduler den Prozess tatsächlich behandelt.
OK, aber das sind Details; es geht ums Prinzip. Wenn von zwei
normalen der eine Prozess nice +10 kriegt und der andere -10, dann
ändert sich was.
>> Nun gibt es aber auch auf höheren Ebenen eine Art
>> Scheduling.
>
> Ich weiß nicht genau was du meinst?
Na, genau das. CPU-Zeit ist sehr low-level (um mal gutes Deutsch zu
benutzen, haha), I/O auch. Aber auch auf Anwendungsebene
konkurrieren typischerweise Prozesse um Ressourcen. Ich weiß nicht,
ob man bei Web- und Datenbankservern die Client-Priorität
beeinflussen kann, aber zumindest auf einem Desktoprechner erscheint
es mir wichtig, den Ressourcenverbrauch der einzelnen Prozesse
begrenzen zu können.
Ich nehme an, dass es normalerweise so ist, dass ein X-Server
unterschiedslos alle Anfragen abarbeitet, ohne das irgendwie zu
begrenzen. Dadurch bremst eine X-Anwendung womöglich den ganzen
Rechner aus (und wer hat nicht schon mal ein quasi-Einfrieren des
GUIs erlebt...).
Ich möchte die Möglichkeit haben, die Last, die ein Client auf dem
X-Server erzeugt, zu begrenzen. Das ist relativ zu den anderen
Clients denkbar (über Prioritätsclassen, etwa so was wie idle) oder
relativ zur Rechnerlast. Man könnte etwa sagen, dass nicht mehr als
5% der CPU-Zeit des Rechners auf die Auslastung des X-Servers durch
einen einzelnen Client entfallen sollen. Also weniger als Grundregel
als vielmehr als Vorgabe für einzelne Clients (wie etwa einen Amok
laufenden Firefox mit seinem Sch***-Flashspielkram).
> Manche Programme haben das Feature dass sie sich inaktiv schalten
> wenn sie nicht betrachtet werden (z.b. kaffeine). Wenn es das
> Feature nicht hat und z.b. ein Flashplugin massig CPU Last
> verbraucht ist das halt eine blöde Situation.
Und genau da kommt ein Betriebssystem (was ein X-Server ja irgendwo
für einen X-Client ist) ins Spiel. Es hat dafür zu sorgen, dass auch
unkooperative Programme keinen unangemessenen Schaden anrichten.
Wenn immer alles nur eitel Sonnenschein wäre, hätten wir auch bei
DOS bleiben können...
> Du könntest z.b. die Flash Prozesse niedriger priorisieren um dein
> Problem zu beheben. Oder ein Bugreport schreiben, dass wenn das
> Programm nicht angeschaut wird, auch gefälligst nichts animieren
> soll.
Das ist auf Applikationsebene eine sinnvolle Userreaktion. Aber ist
es wegen dieser rein organisatorischen Möglichkeit nicht
erstrebenswert, das Problem auch "hart", also durch Technik lösen zu
können? Klar, wegen eines Problems, das nur der Laging ab und zu
hat, wird wohl keiner einen X-Server umschreiben... Aber vielleicht
gibt es so was ja schon. Oder jemand wollte das schon immer mal
machen und bekommt durch die Usernachfrage jetzt den letzten Anstoß
dafür... ;-)
> Welche Fenster angezeigt werden und welche nicht ist afaik eher
> eine Sache des Windowmanagers und nicht direkt X. Deshalb macht
> xnice imho eher weniger Sinn?
Ich kenne mich mit der X-Architektur nicht aus. An welcher Stelle so
eine Bremse sinnvollerweise implementiert wird, kann ich nicht
beurteilen. Wenn das im Windowmanager wäre – meinetwegen. Der könnte
dann auch gleich in den frame controls eine entsprechende
Möglichkeit anbieten.
Hat man denn die Möglichkeit, sich mit halbwegs einfachen Mitteln
anzusehen, welche Prozesse/Clients X gerade unter Last setzen? Das
müssen ja nicht die gewesen sein, denen ich das unterstelle.
Wenn ich mich recht erinnere, was das letzte Ärgernis dieser Art
folgendes: Ich hatte ein Firefox-Fenster mit dem Fernsehprogramm
offen. tv-spielfilm.de. Voll mit Spielkram, alles blinkte,
rotierte... Zwei Tabs in FF. Ich hatte den FF auf einem virtuellen
Desktop, der nicht aktiv war. Trotzdem lagen FF und X zusammen so
bei 60% CPU-Last. Nachdem ich FF beendet habe, verschwand dann die
X-Last auf wundersame Weise.
So was möchte ich verhindern. Wenn es so ein Feature gäbe, könnte der
Windowmanager das entsprechend nutzen: Immer, wenn er ein Fenster
ausblendet, minimiert er dessen X-Priorität.
Markus Raab
> Markus Raab schrieb am Mittwoch 04 November 2009 22:00:
>
>> Die CPU Prioritï¿œt die du mit nice vergibst ist aber noch nicht der
>> Wert wie der Scheduler den Prozess tatsï¿œchlich behandelt.
>
> OK, aber das sind Details; es geht ums Prinzip. Wenn von zwei
> normalen der eine Prozess nice +10 kriegt und der andere -10, dann
> ï¿œndert sich was.
Klar :-)
>>> Nun gibt es aber auch auf hï¿œheren Ebenen eine Art
>>> Scheduling.
>>
>> Ich weiￜ nicht genau was du meinst?
>
> Na, genau das. CPU-Zeit ist sehr low-level (um mal gutes Deutsch zu
> benutzen, haha), I/O auch. Aber auch auf Anwendungsebene
> konkurrieren typischerweise Prozesse um Ressourcen. Ich weiￜ nicht,
> ob man bei Web- und Datenbankservern die Client-Prioritï¿œt
> beeinflussen kann, aber zumindest auf einem Desktoprechner erscheint
> es mir wichtig, den Ressourcenverbrauch der einzelnen Prozesse
> begrenzen zu kï¿œnnen.
Prinzipiell ist es natï¿œrlich erstrebenswert mï¿œglichst jede Resource des
Systems gut kontrollieren zu kï¿œnnen..
> Ich nehme an, dass es normalerweise so ist, dass ein X-Server
> unterschiedslos alle Anfragen abarbeitet, ohne das irgendwie zu
> begrenzen. Dadurch bremst eine X-Anwendung womï¿œglich den ganzen
> Rechner aus (und wer hat nicht schon mal ein quasi-Einfrieren des
> GUIs erlebt...).
Ja, meines Wissens nach arbeitet der X-Server einfach alle Abfragen der
Reihe nach ab. Allerdings sind die Abfragen grￜￜtenteils sehr primitv, wie
z.b. ein komplett leeres Fenster ï¿œffnen (XCreateWindow), ein Text zeigen
(XDrawString) oder ein Rechteck malen (XDrawRectangle). Also um so einen
normalen Qt/Gtk Dialog zu machen sind sicherlich schon einige Operationen
notwendig.
Also ich vermute dass wenn der X-Server so einfriert wird er eher
ï¿œberschwemmt von Anfragen (oder es gibt irgendeinen Bug mit
Endlosschleife). Wenn das so ist, nï¿œtzt dir die X-Prioritï¿œt aber nichts
mehr - auch eine fork-bombe mit nice-Wert von 19 legt dir den Rechner lahm.
Wenn diese Annahme stimmt wï¿œre eine einfache Begrenzung von Abfragen von
einem Prozess ï¿œhnlich wie ulimit (xlimit ;)) bereits effektiv.
Auf jeden Fall ist es verdammt viel Arbeit und mï¿œhselig all diese
Kombinationen wirklich durchzuspielen und fundierte Aussagen darï¿œber zu
machen wo jetzt tatsï¿œchlich der Hund begraben ist. Und die X-Server
Entwickler machen da bereits eine sehr gute Arbeit, subjektiv hat sich die
Situation verbessert.
> Ich mï¿œchte die Mï¿œglichkeit haben, die Last, die ein Client auf dem
> X-Server erzeugt, zu begrenzen. Das ist relativ zu den anderen
> Clients denkbar (ï¿œber Prioritï¿œtsclassen, etwa so was wie idle) oder
> relativ zur Rechnerlast. Man kï¿œnnte etwa sagen, dass nicht mehr als
> 5% der CPU-Zeit des Rechners auf die Auslastung des X-Servers durch
> einen einzelnen Client entfallen sollen. Also weniger als Grundregel
> als vielmehr als Vorgabe fï¿œr einzelne Clients (wie etwa einen Amok
> laufenden Firefox mit seinem Sch***-Flashspielkram).
Flash ist aber (zumindest bei mir) ein separater Prozess, und der macht die
Probleme. Verursacht *X* auch eine Last wenn es das Programm gar nicht
angezeigt wird?
Ansonsten ist X eher das wichtigste Programm um gute Benutzerinaktivitï¿œt zu
erhalten. X weniger CPU Zeit zu geben, bzw. da Begrenzungen einfï¿œhren
kï¿œnnen auch schnell mal den gegenteiligen Effekt haben.
>> Manche Programme haben das Feature dass sie sich inaktiv schalten
>> wenn sie nicht betrachtet werden (z.b. kaffeine). Wenn es das
>> Feature nicht hat und z.b. ein Flashplugin massig CPU Last
>> verbraucht ist das halt eine blï¿œde Situation.
>
> Und genau da kommt ein Betriebssystem (was ein X-Server ja irgendwo
> fï¿œr einen X-Client ist) ins Spiel. Es hat dafï¿œr zu sorgen, dass auch
> unkooperative Programme keinen unangemessenen Schaden anrichten.
> Wenn immer alles nur eitel Sonnenschein wï¿œre, hï¿œtten wir auch bei
> DOS bleiben kï¿œnnen...
Gegen Schaden wï¿œre eher etwas wie ulimit und keine Prioritï¿œt.
Und wirklich nicht vertrauenswï¿œrdige Programme sollte man sowieso in eine
Sandbox einsperren. Z.b. vserver leistet da sehr gute Arbeit: Selbst wenn
ein vserver quasi unbedienbar ist, funktionieren die anderen noch recht
gut.
Ok, anscheinend ist es aus der Mode gekommen mehrere X-Server auf einem
Rechner zu starten. Das Feature ist aber da, und wirkt bei vielen Problemen
Wunder.
>> Welche Fenster angezeigt werden und welche nicht ist afaik eher
>> eine Sache des Windowmanagers und nicht direkt X. Deshalb macht
>> xnice imho eher weniger Sinn?
>
> Ich kenne mich mit der X-Architektur nicht aus. An welcher Stelle so
> eine Bremse sinnvollerweise implementiert wird, kann ich nicht
> beurteilen. Wenn das im Windowmanager wï¿œre ? meinetwegen. Der kï¿œnnte
> dann auch gleich in den frame controls eine entsprechende
> Mï¿œglichkeit anbieten.
Die X-Server Architektur ist auch sehr kompliziert. (Nicht das X-Server und
X-Client Modell) Ich kann mir aber gut vorstellen dass das Auffinden der
richtigen Stelle ein nicht unwesentliches Problem darstellt.
> Hat man denn die Mï¿œglichkeit, sich mit halbwegs einfachen Mitteln
> anzusehen, welche Prozesse/Clients X gerade unter Last setzen? Das
> mï¿œssen ja nicht die gewesen sein, denen ich das unterstelle.
Nicht das ich wï¿œsste, wï¿œrde mich aber auch interessieren. Irgendeine
Debugging Mï¿œglichkeit mï¿œssen die Entwickler aber haben...
> Wenn ich mich recht erinnere, was das letzte ï¿œrgernis dieser Art
> folgendes: Ich hatte ein Firefox-Fenster mit dem Fernsehprogramm
> offen. tv-spielfilm.de. Voll mit Spielkram, alles blinkte,
> rotierte... Zwei Tabs in FF. Ich hatte den FF auf einem virtuellen
> Desktop, der nicht aktiv war. Trotzdem lagen FF und X zusammen so
> bei 60% CPU-Last. Nachdem ich FF beendet habe, verschwand dann die
> X-Last auf wundersame Weise.
Ok, damit ist die Frage geklï¿œrt ob es eine bedeutende CPU Last von X gibt
obwohl man es sich gar nicht anschaut.
> So was mï¿œchte ich verhindern. Wenn es so ein Feature gï¿œbe, kï¿œnnte der
> Windowmanager das entsprechend nutzen: Immer, wenn er ein Fenster
> ausblendet, minimiert er dessen X-Prioritï¿œt.
In der Sache finde ich es besser, wenn ein Fenster Animationen stoppt wenn
es nicht angezeigt wird. Ansonsten ist deine Idee (die ich erst mit dem
zweiten Beitrag kapiert habe), aber sehr interessant.
mfg Markus
--
http://www.markus-raab.org | Wenn ich etwas weiter sah als andere, so
-o) | deshalb, weil ich auf den Schultern von
Kernel 2.6.24-1-a /\ | Riesen stand. -- Sir Isaac Newton
Hauke Laging
> Also ich vermute dass wenn der X-Server so einfriert wird er eher
> überschwemmt von Anfragen (oder es gibt irgendeinen Bug mit
> Endlosschleife).
Gegen die Bugthese (bezogen auf den Server) spricht in meinem Fall
wohl, dass die CPU-Last von Server und Client hoch war und die des
Servers auf Normalwert fiel, nachdem der Client gekillt wurde.
Ich hatte früher[TM] auch so manches Mal ein Kompletteinfrieren von
X. Wenn ich es dann (mit viel Geduld) noch geschafft habe, auf eine
virtuelle Konsole zu kommen (was der sabotierende Prozess übrigens
durch Ressourcenverbrauch sabotieren kann, weil sich dann der
Passwortprompt beim Login so stark verzögert, dass das Passwort
nicht mehr akzeptiert wird, hahaha, deshalb auch
http://www.hauke-laging.de/software/emergency-root-shell/), habe ich
mir mit top den Störenfried rausgesucht (später sogar per
Hintergrundscript automatisch gestoppt (kill -SIGSTOP)),
kaltgemacht – und danach war wieder eitel Sonnenschein angesagt.
> Wenn das so ist, nützt dir die X-Priorität aber
> nichts mehr - auch eine fork-bombe mit nice-Wert von 19 legt dir
> den Rechner lahm.
Klar, aber nice ist ja auch nicht dafür gedacht, Forkbomben,
I/O-Blockaden oder Speicherlecks zu verhindern, steht dem aber auch
nicht im Weg. One tool, one job...
> Wenn diese Annahme stimmt wäre eine einfache Begrenzung von
> Abfragen von einem Prozess ähnlich wie ulimit (xlimit ;)) bereits
> effektiv.
Ich würde sagen, das ist sogar egal. Der X-Server sollte einfach
beachten, wie viel CPU-Zeit pro Client draufgeht. Wofür der Client
die nutzt, ist ja erst mal egal.
> Auf jeden Fall ist es verdammt viel Arbeit und mühselig all diese
> Kombinationen wirklich durchzuspielen und fundierte Aussagen
> darüber zu machen wo jetzt tatsächlich der Hund begraben ist.
Was aber vermutlich gar nicht nötig ist. Erstens, weil der gerade
skizzierte Ansatz schon alle Eventualitäten erschlagen könnte,
zweitens, weil man erst mal die stupide Lösung versuchen kann und
weiteren Entwicklungsaufwand so lange aufschiebt, bis klar ist, dass
die stupide Lösung noch nicht zu einem befriedigenden Ergebnis
führt.
> Flash ist aber (zumindest bei mir) ein separater Prozess, und der
> macht die Probleme.
Bei mir auch (npviewer.bin). Und natürlich kann man diese Prozesse
alle im Hintergrund zurechtstutzen, wobei ein Nicht-X-Programm
vermutlich nicht wissen kann, ob das Flash-Programm gerade im
Vordergrund ist, oder? Und es auch dann niederzuhalten, mag
kontraproduktiv sein.
Außerdem stört mich an dieser Betrachtung, dass man nur so lange auf
der sicheren Seite ist, bis mal ein neues Programm durchdreht (oder
das alte seinen Namen ändert). Zudem steht diese
Eingriffsmöglichkeit nur technisch versierten Leuten offen. Wenn es
einen allgemeinen Mechanismus gäbe, dann könnte die
Standardkonfiguration so aussehen, dass ein Vordergrundprozess
zusammen mit X nicht mehr als 40%, ein Hintergrundprozess nicht mehr
als 5% X-CPU-Last erzeugen darf. Der Windowmanager würde dann beim
Umsortieren der Fenster automatisch den Wert für den jeweiligen
Client anpassen. Damit wäre auch Joe User geholfen.
> Ansonsten ist X eher das wichtigste Programm um gute
> Benutzerinaktivität zu erhalten. X weniger CPU Zeit zu geben, bzw.
> da Begrenzungen einführen können auch schnell mal den gegenteiligen
> Effekt haben.
Eben. Das muss schon von innen heraus geschehen, weil man das Problem
sonst wohl nur verschlimmert.
> Und wirklich nicht vertrauenswürdige Programme
War nicht im Sinne von IT-Sicherheit gemeint, sondern im Sinne
schlechter Programmierqualität. Auch diese Megaaufwand-Variante
kommt für die Masse der User nicht in Frage. Und ich sehe eigentlich
nicht ein, dass man sich diese Arbeit machen müssen soll.
> Die X-Server Architektur ist auch sehr kompliziert. (Nicht das
> X-Server und X-Client Modell) Ich kann mir aber gut vorstellen dass
> das Auffinden der richtigen Stelle ein nicht unwesentliches Problem
> darstellt.
S.o., braucht man ja wahrscheinlich nicht. Zusammen mit einem ersten
Lösungsversuch wäre ein Monitorprogramm hilfreich, das einem zeigt,
was da gerade passiert, damit man nicht nur sagen könnte "Das
Problem ist bei mir nicht gelöst...", sondern etwas
konstruktiver: "Das Problem ist bei mir nicht gelöst, weil folgendes
passiert..."
> In der Sache finde ich es besser, wenn ein Fenster Animationen
> stoppt wenn es nicht angezeigt wird.
Und auch, dass Applikationen nicht abstürzen, nehme ich an... ;-)
Mein Vorschlag soll nicht die Verbreitung schlechter Software
fördern. Im Idealfall wird so eine Sicherung eingebaut, muss aber
nie eingreifen.
> Ansonsten ist deine Idee (die
> ich erst mit dem zweiten Beitrag kapiert habe), aber sehr
> interessant.
Tja, dann müssen sich ja nur noch 20 andere Leute hier so äußern,
damit das auch ernst genommen wird, wenn einer es einreicht. ;-)
Mit meinen letzten beiden Versuchen auf Entwicklungs-Mailinglisten
hatte ich nicht so die großen Erfolge.
Was wäre denn eine sinnvolle Vorgehensweise?