Probleme mit dem Scheduling

mj

mj

Technische Administration, Dinosaurier, ,
Mitglied seit
17.10.2000
Beiträge
19.529
Renomée
272
Standort
Austin, TX
Mir ist heute aufgefallen, dass mit dem Scheduling hier irgendwas nicht stimmen kann. Ich habe einen 600e Quadcore mit 4GB RAM und verspüre einen deutlichen Performanceeinbrauch selbst bei geringen Belastungen.

Beispiel: heute vormittag habe ich ein paar größere Dateien (ca. 2GB pro Datei) auf eine externe Festplatte kopiert. Während des Kopiervorgangs stand das System praktisch, obwohl nur mit durchschnittlich 10MB/s kopiert wurde. Aber selbst das Starten eines Terminals (gnome-terminal) hat fast eine Minute gedauert, jede Aktion hat einen mehrsekündigen Lag verursacht.

Beispiel: aktuell läuft im Hintergrund in einer Virtualbox-Session die Installation einer weiteren openSUSE 11.2 Instanz. Dieser sind hardwaremäßig zwei Prozessoren und 1.024MB Arbeitsspeicher zugewiesen. Diese Last lässt sich auch in top ablesen, trotzdem ist das System extrem träge. Beispielsweise hängt der Cursor beim Tippen dieses Beitrags immer wieder um mehrere Sekunden hinterher, genauso beim Verfassen einer E-Mail in Thunderbird. Fensterwechsel dauern ca. 10 Sekunden, das Starten einer neuen Anwendung braucht ebenfalls übermäßig lang. Und das obwohl ein Prozessor voll und einer nur halb ausgelastet sind, es stehen also rein rechnerisch noch weitere 2,5 Prozessoren zur Verfügung. Swap wird auch nicht genutzt, der Arbeitsspeicher ist zu 45% für Programme und 55% als Cache genutzt. IO-Last ist gering:
Cpu0 : 0.7%us, 95.3%sy, 0.0%ni, 3.7%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 12.2%us, 2.3%sy, 0.0%ni, 81.6%id, 3.3%wa, 0.3%hi, 0.3%si, 0.0%st
Cpu2 : 4.9%us, 3.2%sy, 0.0%ni, 91.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 7.3%us, 2.6%sy, 0.0%ni, 90.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Zum Vergrößern anklicken....


Ich vermute, dass der von mir verwendete Kernel (2.6.31-desktop), eine Spezialanpassung von Novell für den "Desktopbetrieb", irgendwas verpfuscht hat. Bevor ich allerdings wieder wild herumstochere und Kernel installiere und teste wollte ich mich erst erkundigen ob es tatsächlich daran liegt, oder ob evtl. etwas anderes dazwischenfunken könnte. Oder ob es irgendwo Informationen gibt, was genau Novell beim kernel-desktop Kernel im Vergleich zu Vanilla geändert hat. Außer kernel-desktop habe ich noch zur Verfügung: kernel-default, kernel-pae, kernel-rt, kernel-vanilla und kernel-xen. In früheren openSUSE-Versionen gab es noch kernel-server, der scheint mittlerweile allerdings nicht mehr verfügbar zu sein.
 
Ich glaube Novell ist hier unschuldig. Das Problem trat auch beim Vanilla-Kernel auf, dass I/O-lastige Prozesse das gesamte System blockiert haben. Muss ich mal nach suchen, ob ich das wiederfinde. Weiß nicht mehr genau, was und wo das war. Kann aber sein, dass das erst mit 2.6.32 gefixt wurde.
 
Haste mal versucht die Kopieraktion auf einer Konsole mit mc zu machen z.b.?
Ich hatte früher unter KDE3.x manchmal das problem dass konqueror häppchenweise kopierte und es mit MC rasend schnell ging....
 
Danke dir, ich werde testen und berichten.
 
PuckPoltergeist schrieb:
Ich glaube Novell ist hier unschuldig. Das Problem trat auch beim Vanilla-Kernel auf, dass I/O-lastige Prozesse das gesamte System blockiert haben. Muss ich mal nach suchen, ob ich das wiederfinde. Weiß nicht mehr genau, was und wo das war. Kann aber sein, dass das erst mit 2.6.32 gefixt wurde.
Zum Vergrößern anklicken....
Siehe auch:
http://www.heise.de/open/artikel/Dateisysteme-Block-Layer-Devtmpfs-870440.html
http://thread.gmane.org/gmane.linux.kernel/900461/focus=900483

Hatte das Problem früher auch. Mit 2.6.32 ist es besser.
Gab glaub früher auch noch die Möglichkeit dem über bestimmte Kernel-Konfigurationen aus dem Weg zu gehen. Hat bei mir aber nie wirklich funktioniert.

Edit: Novell ist hier übrigens mal ausnahmsweise unschuldig, das ist ein Problem des Vanilla Kernels, bzw. war es.
Und zwar bestimmt schon seit 2 Jahren.
 
Berniyh schrieb:
Und zwar bestimmt schon seit 2 Jahren.
Zum Vergrößern anklicken....
:o Da frage ich mich allen Ernstes: wie kann so etwas passieren? Ich will mir gar nicht vorstellen, wie schnell die Linux-Gemeinde Microsoft oder Apple zerfleischt hätte, wenn dort ein ähnlicher Fehler auch nur für wenige Wochen ungefixt geblieben wäre...
 
mj schrieb:
:o Da frage ich mich allen Ernstes: wie kann so etwas passieren? Ich will mir gar nicht vorstellen, wie schnell die Linux-Gemeinde Microsoft oder Apple zerfleischt hätte, wenn dort ein ähnlicher Fehler auch nur für wenige Wochen ungefixt geblieben wäre...
Zum Vergrößern anklicken....

Weil nicht wirklich jemand diesen Bug reported hatte und wahrscheinlich auch nicht viele Leute den so mitbekommen haben. Und ganz so alt ist er glaube auch noch nicht. Wenn ich das jetzt nicht durcheinander bringe, ist diese Regression erst mit den letzten Kernel-Versionen so aufgekommen. Und da die großen Linux-Distributionen nicht auf jeden neuen Vanilla-Kernel aufspringen, fällt das den Endnutzern nicht so ins Auge. Red Hat liefert nach wie vor noch 2.6.18, SuSE dürfte ähnlich sein.
Dazu kommt noch, dass die Regression Workload- und Rechner-abhängig ist. Ein Problem ist wohl auch, dass die Entwickler in dem Bereich hauptsächlich mit recht potenten Maschinen arbeiten. Bei den "passenden" Zugriffsmustern fällt denen dann gar nicht so sehr auf, wie das Verhalten des Kernels in bestimmten Situationen abbaut. Deshalb hat auch Con Kolivas' BFS so stark eingeschlagen.

Größtes Problem bei dieser Sache ist, dass das Problem nach wie vor schwer zu quantifizieren ist. Einen trägen Desktop fühlt jeder Nutzer. Aber mach das mal in Zahlen deutlich, die man messen kann. Und ohne letzteres kann man nicht optimieren.

Btw: Hat der Hack geholfen?
 
PuckPoltergeist schrieb:
Btw: Hat der Hack geholfen?
Zum Vergrößern anklicken....
Ja, bisher sieht's sehr gut aus. Ich hab vorhin Last, auch IO-Last, erzeugt und konnte keine Verlangsamung feststellen. Danke für den Tipp, ich hab den Befehl mittlerweile in die boot.local aufgenommen.

Und was die Aktualität der Kernel angeht: zu Redhat kann ich nichts sagen, aber bekanntermaßen zu openSUSE und dort hatte bereits 11.1 den damals aktuellen Kernel 2.6.27, 11.2 setzt auf 2.6.31. Die sind da eigentlich immer sehr flink und aktuell, genauso wie Ubuntu. Und trotz deiner an sich absolut logischen Erklärung macht sich bei mir primär Unverständnis breit - ausgerechnet der Scheduler, die Schaltzentrale eines Multiuser Multitasking Betriebssystems wie Linux hat einen Fehler, der das System derart dramatisch abbremst, dass es selbst mit einem Quadcore an den Rand der Benutzbarkeit schlittert? Und zu allem Überfluss dann auch noch für mehrere Wochen oder Monate unbemerkt und ungefixt bleibt? Mutet für meinen Geschmack in Anbetracht der geballten Kompetenz im Kernel-Entwickler-Team etwas komisch an.

Und dazu nochmal eine blöde Frage: macht sich dieser Fehler nur in einer trägen Benutzeroberfläche bemerkbar, oder kann es passieren, dass ein Server bei Anfragen genauso träge reagiert wenn die IO-Last steigt? Ich frage deshalb, weil wir demnächst diverse openSUSE 11.2 Maschinen zu Kunden ausliefern werden und diese unter Last auf keinen Fall das hier skizzierte Verhalten zeigen dürfen.
 
So wie mir das aussieht ist da aber nur ein Zusammenhang mit dem CFQ IO-Scheduler gegeben.
Wer den einsetzt ist allerdings eh selbst schuld ...
Ich konnte dem noch nie was abgewinnen.

@mj: io-scheduler nicht mit prozess-scheduler verwechseln ;)

Von je her setze ich entweder auf noop oder deadline und bin damit immer bestens gefahren.
Das boot läuft übrigens auch auf deadline und das ganz gut.

Ich frage mich allerdings warum die Entwickler hier immer wieder herumdoktern und sowas dann noch
als "stable kernel" raus bringen :]

lg
__tom
 
PuckPoltergeist schrieb:
Weil nicht wirklich jemand diesen Bug reported hatte und wahrscheinlich auch nicht viele Leute den so mitbekommen haben. Und ganz so alt ist er glaube auch noch nicht. Wenn ich das jetzt nicht durcheinander bringe, ist diese Regression erst mit den letzten Kernel-Versionen so aufgekommen. Und da die großen Linux-Distributionen nicht auf jeden neuen Vanilla-Kernel aufspringen, fällt das den Endnutzern nicht so ins Auge. Red Hat liefert nach wie vor noch 2.6.18, SuSE dürfte ähnlich sein.
Dazu kommt noch, dass die Regression Workload- und Rechner-abhängig ist. Ein Problem ist wohl auch, dass die Entwickler in dem Bereich hauptsächlich mit recht potenten Maschinen arbeiten. Bei den "passenden" Zugriffsmustern fällt denen dann gar nicht so sehr auf, wie das Verhalten des Kernels in bestimmten Situationen abbaut. Deshalb hat auch Con Kolivas' BFS so stark eingeschlagen.
Zum Vergrößern anklicken....
Nein, das Problem besteht schon recht lange, wobei es da glaube ich mehrere Probleme gibt. Gut möglich, dass es vom letzten Kernel eine Regression gab, die dazu führte, dass man endlich in die Richtung gearbeitet hat.

Auf meinem System bestand ein derartiges Problem allerdings seit 2 Jahren schon, gebessert hat es sich erst mit der Anpassung des IO-Schedulers in 2.6.32.
.
EDIT :
.
tomturbo schrieb:
So wie mir das aussieht ist da aber nur ein Zusammenhang mit dem CFQ IO-Scheduler gegeben.
Zum Vergrößern anklicken....
Du hattest mir in dem Zusammenhang vor etwa einem Jahr schon mal den Deadline-Scheduler empfohlen, mit dem war es allerdings kein bisschen besser, leider.
Mit dem habe ich das Problem auch jetzt noch, Dateien verschieben/kopieren/etc. = System weitgehend unbenutzbar.

Mit der neuen Version des CFQ ist das besser.
.
EDIT :
.
mj schrieb:
Und dazu nochmal eine blöde Frage: macht sich dieser Fehler nur in einer trägen Benutzeroberfläche bemerkbar, oder kann es passieren, dass ein Server bei Anfragen genauso träge reagiert wenn die IO-Last steigt?
Zum Vergrößern anklicken....
Meines Wissens ein Desktop-Problem, was auch mit ein Grund dafür sein könnte, dass es so lange bestanden hat, denn Nutzer, die meckern »Mein System ist zu langsam« gibt es sicherlich reichlich und ich könnte mir vorstellen, dass man die ignoriert, wenn sie ihr Problem nicht einigermaßen klassifizieren können.
 
Wenn es ein reines Desktop-Problem ist, dann wird es die Hälfte der Server betreffen. Denn auf denen arbeiten zeitweise bis zu 200 Anwender via XDMCP parallel und erzeugen Last. Ich müsste mal in unseren Support-Logs wühlen, ob sich dort jemand über mangelnde Performance unter 11.1 beklagt hat. Und die openSUSE Archive darf ich bei der Gelegenheit auch gleich durchwühlen, vielleicht verstecken sich irgendwo zuverlässige Informationen zu den einzelnen mitgelieferten Kerneln. Evtl. setzt ja einer der angebotenen Kandidaten auf noop oder deadline. Kernel selber backen fällt leider aus zeitlichen und politischen Gründen flach, beziehungsweise bleibt eine absolute Notlösung.
 
Super, danke. Damit kann ich mich an's experimentieren machen :)
 
tomturbo schrieb:
So wie mir das aussieht ist da aber nur ein Zusammenhang mit dem CFQ IO-Scheduler gegeben.
Zum Vergrößern anklicken....
Nein, betrifft auch die anderen I/O-Scheduler, wenn auch nicht in diesem Ausmaß.

Wer den einsetzt ist allerdings eh selbst schuld ...
Ich konnte dem noch nie was abgewinnen.
Zum Vergrößern anklicken....
Für Desktop-Workloads ist der eine recht gute Wahl. Auf Servern, wo es eher auf Durchsatz denn Latenz ankommt, mag der Deadline besser sein.

Ich frage mich allerdings warum die Entwickler hier immer wieder herumdoktern und sowas dann noch
als "stable kernel" raus bringen :]
Zum Vergrößern anklicken....
Das, was du als herumdoktoren bezeichnest, ist an sich ein ganz normaler Entwicklungsprozess. Derartige Änderungen leben meist ziemlich lange in eigenen git-trees und werden dort ausgiebig getestet, bevor sie in den mainline kernel übernommen werden. Der Unterschied zu früher ist, dass es jetzt nicht mehr Jahre dauert, sondern nur noch Monate, und dass solche Änderungen viel gezielter getestet werden.
 
Man muss sich auch vor augen halten dass trotz Desktop-Hype um Suse, Ubuntu und Co. Der Haupt-Einsatzzweck von Linux immernoch auf servern liegt!
Bis vor wenigen Jahren gab es gar keinen ordentlichen, Desktop-Optimierten Scheduler, nur Anticipatory und Deadline.
Die Mehrzahl der Entwickler steht auf der Gehaltsliste von Hardware-Unternehmen oder Firmen im Server-Umfeld, (Oracle beispielsweise) die in erster Linie ein Interesse daran haben dass ihr neuestes DB-Produkt optimal performant läuft.
D.h. Desktop-Workloads stellen eine Minderheit dar! - ich schätze mal Grob 90% aller (non-embedded-) Linuxmaschinen da draußen lassen sich als Webserver, DB-Server, FTP-Server oder LAMP charakterisieren.
Wir Desktopuser sind eine Minderheit. Dazu kommt dass user gerne maulen ohne konkret einen Hinweis geben zu können warum etwas langsam ist... ich höre meine Verwandtschaft auch immer maulen der PC wäre langsam, nur weil grade die Webseite n großes Flash nachlädt...
wie soll man solche Leute ohne quantifizeirbare Informationen von denen unterscheiden die ein echtes Problem haben?
Und wer hier glaubt so einen Scheduler schreibt ein Azubi in der Mittagspause der soll sich bitteschön mal daran versuchen... zumal es nicht unbedingt direkt am Scheduler leigen muss sondern möglicherweise nur in bestimmten Situationen / zugriffsmustern auftritt....
Debug das mal!
Auch die Linuxentwickler sind nicht perfekt.
Und es stimmt, Apple oder MS hätten hiebe bekommen... aber schließlich kann ich für die Kosten einer einzigen Windows7-Lizenz auch meine gesamte Nachbarschaft mit Linuxen ausstatten...
 
tomturbo schrieb:
YMMD *lol*

Vom User getestet ... ;D

lg
__tom
Zum Vergrößern anklicken....

Sicherlich auch, wie bei jedem System. Zeig mir das System, das absolut fehlerfrei released wird. Es gibt immer wieder Fälle, die nicht vorher abgefasst werden können.

Und ja, mit dem neuen Entwicklungsmodell können die einzelnen Subsysteme viel gezielter getestet werden als früher. Früher kam alles im Development-Tree (2.3, 2.5) zusammen, und war da ein Konglomerat aus allen Änderungen an allen Subsystemen. Das sinnvoll zu testen, ist unmöglich. Wenn jetzt die Entwicklungen in einzelnen git-trees erfolgt, können dort die Änderungen isoliert getestet werden, laufen dann zusammen und können dann zusammen getestet werden. (das ganze jetzt etwas sehr idealisiert dargestellt)
 
Du hast schon recht Puck.

ABER

Es scheint mir so also da etwas released wird dass keiner getestet haben kann, hat man den Eindruck.
Das ist zu kritisieren und nicht das Problem an sich.

lg
__tom
 
Nicht unter allen Bedigungen getestet meinst du wohl!?
Wie viele Use-Cases gibt es für ien Betriebssystem?
Wie viele Zugriffsmuster auf wie viele verschiedene DEvices und dateisysteme.
Dazu je nach host-Hardware unterschiedlich viele unterbrechungen durch interrupts usw.
Ist ja nicht so als würden die Kernel jährlich released... also wie zum Geier sollte jemand das vernünftig testen in den paar Wochen bis zum nächsten Kernel-Release?

Ich behaupte mal, hätte ein Entwickler das Problem auf seinem System bemerkt, hätte es augenblicklich die Reißleine gezogen und im LKML eine riesen Diskussion losgetreten.
d.h. die Tatsache dass es schlicht keiner bemerkt hat muss bedeuten dass das Problem entweder nicht aufgetreten ist auf den Entwickler-Rechnern oder so gering war dass es nicht bemerkt wurde.
Das ist ja grade der Punkt, etwas zu testen bedeutet noch lange nicht dass man den Fehler auch direkt bemerkt.
Und ich glaube wirklich nicht dass das kopieren mehrerer GB-Großer Dateien auf ein USB-Laufwerk zum standard-Testcase des Linuxkernels gehört...
Zumal da dinge mit reinspielen wie güte des USB-Controllers, Treiber des selben, FS auf das geschrieben wird, Zielgerät und dessen übertragungsrate usw. da ist der Scheduler wahrscheinlich erstmal der aller letzte Punkt wo man einen Fehler sucht....
 
Zuletzt bearbeitet:
Ge0rgy schrieb:
Ist ja nicht so als würden die Kernel jährlich released... also wie zum Geier sollte jemand das vernünftig testen in den paar Wochen bis zum nächsten Kernel-Release?
Zum Vergrößern anklicken....
Das lässt sich gar nicht testen, es sei denn, man reduziert die Anzahl der Änderungen auf ein Minimum während man die Release-Zyklen nach oben schraubt.

Ich behaupte mal, hätte ein Entwickler das Problem auf seinem System bemerkt, hätte es augenblicklich die Reißleine gezogen und im LKML eine riesen Diskussion losgetreten.
d.h. die Tatsache dass es schlicht keiner bemerkt hat muss bedeuten dass das Problem entweder nicht aufgetreten ist auf den Entwickler-Rechnern oder so gering war dass es nicht bemerkt wurde.
Das ist ja grade der Punkt, etwas zu testen bedeutet noch lange nicht dass man den Fehler auch direkt bemerkt.
Und ich glaube wirklich nicht dass das kopieren mehrerer GB-Großer Dateien auf ein USB-Laufwerk zum standard-Testcase des Linuxkernels gehört...
Zum Vergrößern anklicken....
Wäre aber sinnvoll, wenn man entsprechende Test-Cases definieren könnte.

Zumal da dinge mit reinspielen wie güte des USB-Controllers, Treiber des selben, FS auf das geschrieben wird, Zielgerät und dessen übertragungsrate usw. da ist der Scheduler wahrscheinlich erstmal der aller letzte Punkt wo man einen Fehler sucht....
Zum Vergrößern anklicken....
Unsere Test-Matrix explodiert gerade. ;D
 
Naja man muss schon die Kirche im Dorf lassen.
Hier ging es schlicht um Dateikopieren während Desktoparbeit getan wird.
Also soooo unendlich schwierig ist das nicht und sollte eigentlich einer der absoluten Basistests sein.

lg
__tom
 
Das Problem ist ja nicht der Fehler an sich. Fehler passieren, das ist nicht weiter verwerflich. Das Problem liegt darin begraben, dass ein derartiger Fehler es trotz mehr oder weniger aufwendiger Tests in den Mainline-Kernel geschafft hat ohne entdeckt zu werden. Dabei war es in meinem speziellen Fall so deutlich zu spüren, dass jeder halbwegs Computeraffine Anwender den Braten gerochen hätte. Und hier handelt es sich wirklich um keinen schwachen oder alten PC, sondern um ein verhältnismäßig modernes Gerät. Wenn der Fehler wirklich so speziell ist und nur in bestimmten Fällen auftritt wird's natürlich entsprechend schwieriger, aber genau deshalb sprach ich auch von geballter Kompetenz im Kernel-Entwickler-Team - dort sitzen die fähigsten Programmierer, die diese Welt hervorgebracht hat.
 
mj schrieb:
Wenn der Fehler wirklich so speziell ist und nur in bestimmten Fällen auftritt wird's natürlich entsprechend schwieriger, aber genau deshalb sprach ich auch von geballter Kompetenz im Kernel-Entwickler-Team - dort sitzen die fähigsten Programmierer, die diese Welt hervorgebracht hat.
Zum Vergrößern anklicken....
Aber auch die können Latenz-Probleme nicht riechen. Das sind derart viele Wechselwirkungen, das ist einfach nicht mehr überschaubar. Deshalb lassen sich solche Fehler nur (zuverlässig) debuggen, wenn man eine recht konkrete Beschreibung des Fehlerbilds hat und Test-Cases, an Hand derer man den Fehler nachstellen kann.

Ein sehr prominentes Beispiel sind die Scheduler von Con Kolivas. Der hatte schon früher sehr viel auf dem Gebiet getan. Sein Staircase Scheduler war für Desktop-Systeme deutlich besser, als der damals verwendete O(1)-Scheduler, welcher im Kernel eingesetzt wurde. Auf Basis dessen wurde ja auch von Ingo Molnar der CFS (Complete Fair Scheduler) geschrieben. Das Problem mit Kolivas' Implementierung war, fast jeder Anwender sagte zwar, dass damit sein System deutlich "flüssiger" lief, aber das war nicht in Zahlen umgesetzt. Wenn du nichts zum messen hast, kannst du nicht optimieren. Das gleiche Problem traf dann auch den BFS (Brain Fuck Scheduler), welchen Kolivas jetzt am Start hat. Nur hier ist es dann den Kernel-Entwicklern gelungen, Metriken zu entwickeln, mit denen sich die Scheduler effektiv vergleichen ließen. Das Ganze ist noch sehr stark in der Entwicklung, betrifft aber auch die I/O-Scheduler.
Das größte Problem an der ganzen Thematik ist, dass man etwas haben muss, was man messen kann. Man muss entsprechende Größen finden, und die dann auch messen können. Und gerade letzteres ist auch noch sehr jung im Linux Kernel. Die ganze Infrastruktur, um so etwas zu messen (tracepoints, performance counter etc.) zieht gerade erst in den Kernel ein.

Summa sumarum, wenn man nichts hat, was man messen kann und nichts hat, womit man messen kann, sind solche Bugs schwer zu vermeiden.

PS: Und selbst du als Computer-Affiner hast den Braten doch an der falschen Stelle gerochen. ;)
 
Zuletzt bearbeitet:

Ähnliche Themen

tspoon
Langeweile am Nachmittag und die BASH
Antworten
0
Aufrufe
2K
tspoon
tspoon
Dr@
Download AMD Catalyst 13.4 Proprietary Linux Display Driver
Antworten
10
Aufrufe
9K
Liszca
L
Dr@
Neue "VISION technology" Notebookplattform
Antworten
0
Aufrufe
45K
Dr@
Dr@
mj
AMDs 45nm Quad-Core Opteron "Shanghai"
Antworten
0
Aufrufe
56K
mj
mj
Nero24
Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris
Antworten
0
Aufrufe
377K
Nero24
Nero24
Zurück
Oben Unten