- Der Artikel von 2013 ist falsch
- Ein Fehler in LWN? Bist du sicher?
- Lange Warteschlangen in E / A-Geräten, die durch das Zurückschreiben im Hintergrund erstellt wurden
- Einschränkungen von "No-I / O Dirty Throttling"?
- Echte Berichte über Probleme mit dem "USB-Stick-Stall"
- Das Dirty Limit wurde falsch berechnet [2014]
- Riesige Seitenzuweisungen blockieren auf IO [2011]
- "Schmutzige Seiten erreichen das Ende der LRU"? [vor 2013]
1. Der Artikel von 2013 ist falsch
Der Artikel "USB-Stick Stall" vermittelt einen sehr irreführenden Eindruck. Es stellt sowohl den ursprünglichen Bericht als auch die Reihe der Antworten falsch dar.
Artem hat nicht gemeldet, dass das gesamte System hängen geblieben ist, als zwischengespeicherte Schreibvorgänge auf einen USB-Stick übertragen wurden. In seinem ursprünglichen Bericht wurde nur beanstandet, dass das Ausführen des Befehls "Synchronisieren" bis zu "Dutzende von Minuten" dauern könne. Diese Unterscheidung wird in einer Antwort von Linus Torvalds explizit gemacht :
Es ist tatsächlich sehr einfach zu reproduzieren, indem Sie einfach einen durchschnittlichen USB-Stick nehmen und versuchen, darauf zu schreiben. Ich habe es gerade mit einem zufälligen ISO-Image gemacht und es ist schmerzhaft. Und es ist nicht so, dass es schmerzhaft ist, die meisten anderen Dinge im Hintergrund zu tun, aber wenn Sie zufällig etwas ausführen, das "synchronisiert" (und es passiert in Skripten), kommt die Sache nur zum Stillstand. Für Minuten.
2. Ein Fehler in LWN? Bist du sicher?
Jon Corbet hatte fünfzehn Jahre Erfahrung und berichtete wöchentlich über die Entwicklung des Linux-Kernels. Es macht es sehr kompliziert, diese Antwort zu schreiben :-(. Ich möchte zeigen, ob Corbets Artikel falsch oder schlecht formuliert ist. Aber es war wahrscheinlich in gewisser Weise fast richtig. Ich muss die beiden verschiedenen Datensätze verarbeiten und schauen Ausschau nach detaillierten Punkten, an denen sie zustimmen oder nicht zustimmen.
Ich habe die gesamte ursprüngliche Diskussion in den Archiven unter lore.kernel.org gelesen. Ich denke, die Botschaften sind ziemlich klar.
Ich bin zu 100% sicher, dass der Artikel falsch ist. In Kommentaren unter dem Artikel wiederholten mindestens zwei Leser die falsche Behauptung in ihren eigenen Worten, und niemand korrigierte sie. Der Artikel setzt diese Verwirrung im dritten Absatz fort:
All diese Daten verstopfen die E / A-Warteschlangen und verzögern möglicherweise andere Vorgänge. Und sobald jemand sync () aufruft , hören die Dinge auf, bis die gesamte Warteschlange geschrieben ist.
Dies könnte eine Verwirrung von Linus sein, der sagt "das Ding kommt gerade zum Stillstand". "Das Ding" bezieht sich auf "alles, was tut sync(und es passiert in Skripten)". Aber Corbet schreibt, als ob "das Ding" "das gesamte System" bedeutet.
Laut Linus ist dies ein reales Problem. Die überwiegende Mehrheit der Dinge ruft jedoch nicht die systemweite sync () -Operation auf. [1]
Warum könnte Corbet dies mit "dem gesamten System" verwechseln? Ich denke, es gab eine Reihe von Problemen, und nach einer Weile wird es schwierig, sie alle in deinem Kopf getrennt zu halten :-). Und obwohl LWN die Entwicklung der schmutzigen Drosselung pro Gerät (und pro Prozess) beschrieben hat, wird über solche Details im Allgemeinen vermutlich nicht viel geschrieben. Viele Dokumente beschreiben nur die globalen Einstellungen für den Grenzwert für Verschmutzungen.
3. Lange Warteschlangen in E / A-Geräten, die durch "Hintergrund" -Schreiben erstellt wurden
Artem hat einen zweiten Bericht im Thread veröffentlicht, in dem "der Server fast zum Stillstand kommt und andere E / A-Anforderungen viel länger dauern".
Dieser zweite Bericht entspricht nicht den Behauptungen über einen USB-Stick-Hang. Dies geschah nach dem Erstellen einer 10-GB-Datei auf einer internen Festplatte. Dies ist ein anderes Problem.
Der Bericht bestätigte nicht, ob dies durch Ändern der Verschmutzungsgrenzwerte verbessert werden könnte. Und es gibt eine neuere Analyse solcher Fälle. Es liegt ein erhebliches Problem vor, wenn die E / A-Warteschlange Ihrer Hauptfestplatte verstopft ist. Es kann zu langen Verzögerungen auf einer Festplatte kommen, auf die Sie sich ständig verlassen, um Programmcode bei Bedarf zu laden, Dokumente und App-Daten mit write () + fsync () usw. zu speichern.
Wenn der Speicherverwaltungscode beschließt, einen Bereich schmutziger Daten zu schreiben, ist das Ergebnis eine E / A-Anforderung, die an das Block-Subsystem gesendet wird. Diese Anforderung kann einige Zeit im E / A-Planer verbringen, wird jedoch schließlich an den Treiber für das Zielgerät gesendet.
Das Problem ist, dass, wenn viele schmutzige Daten zu schreiben sind, möglicherweise eine große Anzahl (wie in Tausenden) von Anforderungen für das Gerät in die Warteschlange gestellt wird. Selbst eine relativ schnelle Fahrt kann einige Zeit in Anspruch nehmen, um so viele Anforderungen zu bearbeiten. Wenn eine andere Aktivität (z. B. Klicken auf einen Link in einem Webbrowser oder Starten einer Anwendung) E / A-Anforderungen auf demselben Blockgerät generiert, werden diese Anforderungen in den hinteren Bereich dieser langen Warteschlange gestellt und möglicherweise einige Zeit nicht bearbeitet. Wenn mehrere synchrone Anforderungen generiert werden - beispielsweise Seitenfehler von einer neu gestarteten Anwendung - muss möglicherweise jede dieser Anforderungen diese lange Warteschlange durchlaufen. Das ist der Punkt, an dem die Dinge einfach anzuhalten scheinen.
[...]
Die meisten Blocktreiber unterhalten auch intern eigene Warteschlangen. Diese Warteschlangen auf niedrigerer Ebene können besonders problematisch sein, da sie zum Zeitpunkt des Eingangs einer Anforderung nicht mehr der Kontrolle des E / A-Schedulers unterliegen (wenn überhaupt ein E / A-Scheduler vorhanden ist).
Die Patches wurden zusammengeführt, um dies Ende 2016 zu verbessern (Linux 4.10) . Dieser Code wird als "Rückschreibdrosselung" oder WBT bezeichnet. Wenn Sie im Internet nach etwas wbt_lat_usecmehr Geschichten darüber suchen. (Das erste Dokument schreibt darüber wb_lat_usec, ist aber veraltet). Beachten Sie, dass die Drosselung des Rückschreibens mit den CFQ- oder BFQ-E / A-Schedulern nicht funktioniert. CFQ war als Standard-E / A-Scheduler beliebt, einschließlich der Standard-Kernel-Builds bis Linux v4.20. CFQ wird in Kernel v5.0 entfernt .
Es gab Tests, um das Problem (und die Prototyplösung) sowohl auf einer SSD (die wie NVMe aussah) als auch auf einer " normalen Festplatte " zu veranschaulichen . Die Festplatte war "nicht ganz so schlecht wie Geräte mit tieferer Warteschlangentiefe, bei denen wir über ein enormes E / A verfügen".
Ich bin mir nicht sicher über die "Tausenden" von Anfragen in der Warteschlange, aber es gibt mindestens NVMe-Geräte, die Hunderte von Anfragen in die Warteschlange stellen können. Bei den meisten SATA-Festplatten können 32 Anforderungen in die Warteschlange gestellt werden ("NCQ"). Natürlich würde die Festplatte länger brauchen, um jede Anfrage abzuschließen.
4. Einschränkungen der "No-I / O Dirty Throttling"?
"No-I / O Dirty Throttling" ist ein recht komplexes System. Es wurde auch im Laufe der Zeit optimiert. Ich bin sicher, dass es in diesem Code einige Einschränkungen gab und gibt .
Die LWN-Beschreibung, Code- / Patch-Kommentare und die Folien aus der detaillierten Präsentation zeigen, dass eine große Anzahl von Szenarien berücksichtigt wurde. Dies schließt den berüchtigten langsamen USB-Stick gegen das schnelle Hauptlaufwerk ein. Die Testfälle enthalten den Ausdruck "1000 gleichzeitige dd's" (dh sequentielle Writer).
Bisher weiß ich nicht, wie ich Einschränkungen innerhalb des schmutzigen Drosselungscodes demonstrieren und reproduzieren kann.
Ich habe mehrere Beschreibungen von Problemkorrekturen gesehen, die außerhalb des schmutzigen Drosselungscodes lagen. Der letzte Fix, den ich gefunden habe, war 2014 - siehe nachfolgende Abschnitte. In dem Thread, über den LWN berichtet, erfahren wir:
In den letzten Veröffentlichungen wurden Probleme wie diese durch Probleme bei der Rückforderung verursacht, die es satt hatten, viele schmutzige / unter Rückschreibeseiten zu sehen, und darauf warteten, dass die E / A beendet wurde.
[...] Das Systemtap-Skript hat diese Art von Bereichen erfasst, und ich glaube, sie sind repariert.
Mel Gorman sagte auch , dass es einige "offene Fragen" gab.
Es gibt jedoch immer noch Probleme. Wenn alle verschmutzten Seiten von einem langsamen Gerät gesichert wurden, führt die Begrenzung der Verschmutzung möglicherweise immer noch zu Verzögerungen beim Ausgleich der verschmutzten Seiten [...]
Diese Passage war das einzige, was ich in dem berichteten Diskussionsthread finden konnte, das die LWN-Interpretation annähernd unterstützt. Ich wünschte, ich hätte verstanden, worauf es sich bezog :-(. Oder wie man es demonstriert und warum es in den von Artem und Linus durchgeführten Tests nicht als bedeutendes Problem auftauchte.
5. Echte Berichte über Probleme mit dem "USB-Stick-Stall"
Obwohl weder Artem noch Linux einen "USB-Stick-Stall" gemeldet haben, der das gesamte System betraf, können wir an anderer Stelle mehrere Berichte darüber finden. Dies schließt Berichte in den letzten Jahren ein - weit nach dem letzten bekannten Fix.
Ich weiß nicht, was der Unterschied ist. Vielleicht waren ihre Testbedingungen in irgendeiner Weise anders, oder vielleicht gibt es seit 2013 einige neue Probleme im Kernel ...
6. Das Dirty Limit wurde falsch berechnet [2014]
Im Januar 2014 gab es eine interessante Korrektur (angewendet in Kernel v3.14). In der Frage haben wir gesagt, dass das Standardlimit auf 20% des Speichers festgelegt wurde. Tatsächlich ist es auf 20% des Speichers eingestellt, der für den Cache für schmutzige Seiten verfügbar ist. Beispielsweise haben die Kernelpuffer Daten für TCP / IP-Netzwerksockets gesendet. Die Socket-Puffer können nicht gelöscht und durch einen schmutzigen Seiten-Cache ersetzt werden :-).
Das Problem war, dass der Kernel den austauschbaren Speicher zählte, als könnte er Daten zugunsten eines schmutzigen Seitencaches austauschen. Obwohl dies theoretisch möglich ist, ist der Kernel stark voreingenommen, um ein Austauschen zu vermeiden, und zieht es vor, stattdessen den Seitencache zu löschen. Dieses Problem wurde durch einen Test veranschaulicht, bei dem auf einen langsamen USB-Stick geschrieben wurde und festgestellt wurde, dass er im gesamten System zu Verzögerungen führte :-).
Siehe Re: [Patch 0/2] mm: Reduzieren Sie Reclaim-Stalls mit starkem Anon und verschmutztem Cache
Das Update wurde dirty_ratiojetzt nur noch als Teil des Datei-Cache behandelt.
Laut dem Kernel-Entwickler, der unter dem Problem litt, "scheinen die Triggerbedingungen ziemlich plausibel zu sein - hohe anon-Speichernutzung mit stark gepufferten E / A- und Swap-Konfigurationen - und es ist sehr wahrscheinlich, dass dies in freier Wildbahn geschieht." Dies könnte also für einige Benutzerberichte um 2013 oder früher verantwortlich sein.
7. Riesige Seitenzuweisungen blockieren IO [2011]
Dies war ein weiteres Problem: Riesige Seiten, langsame Laufwerke und lange Verzögerungen (LWN.net, November 2011). Dieses Problem mit großen Seiten sollte jetzt behoben sein .
Trotz der Aussagen in diesem Artikel denke ich, dass die meisten aktuellen Linux-PCs nicht wirklich große Seiten verwenden . Dies kann sich ab Debian 10 ändern. Selbst wenn Debian 10 nach Möglichkeit große Seiten zuweist, scheint mir klar zu sein, dass es keine Verzögerungen gibt , es sei denn, Sie ändern eine andere Einstellung, die defragauf "immer" aufgerufen wird .
8. "Schmutzige Seiten erreichen das Ende der LRU" [vor 2013]
Ich habe das nicht untersucht, aber ich fand es interessant:
mgorman 2011 : Dies ist eine neue Art von USB-bezogenem Stall, da dies auf synchrones Komprimierungsschreiben zurückzuführen ist, bei dem wie in der Vergangenheit das große Problem darin bestand, dass schmutzige Seiten das Ende der LRU erreichten und durch Rückforderung geschrieben wurden .
mgorman 2013 : Die Arbeit in diesem allgemeinen Bereich befasste sich mit Problemen wie schmutzigen Seiten, die das Ende der LRU erreichen (übermäßige CPU-Auslastung).
Wenn es sich um zwei verschiedene Probleme handelt, bei denen das Ende der LRU erreicht wird, klingt das erste Problem möglicherweise sehr schlimm. Es hört sich so an, als würde jeder Versuch, Speicher zuzuweisen, verzögert, wenn eine schmutzige Seite zur zuletzt verwendeten Seite wird, bis das Schreiben dieser schmutzigen Seite abgeschlossen ist.
Was auch immer es bedeutet, er sagt, das Problem sei jetzt behoben.
[1] Eine Ausnahme: Für eine Weile verwendete der Debian-Paketmanager dpkgsync (), um die Leistung zu verbessern. Dies wurde aufgrund des genauen Problems entfernt, dass sync () extrem lange dauern kann. Sie wechselten zu einem Ansatz unter sync_file_range()Linux. Siehe Ubuntu-Fehler # 624877, Kommentar 62 .
Teil eines früheren Versuchs, diese Frage zu beantworten - dies sollte größtenteils überflüssig sein:
Ich denke, wir können beide Artem-Berichte als mit dem Code "No-I / O Dirty Throttling" konsistent erklären.
Der Dirty-Throttling-Code soll jedem Backing-Gerät einen angemessenen Anteil am "Total Write-Back-Cache" ermöglichen, "der sich auf seine aktuelle durchschnittliche Ausschreibgeschwindigkeit im Verhältnis zu den anderen Geräten bezieht". Diese Formulierung stammt aus der Dokumentation von / sys / class / bdi / . [2]
Im einfachsten Fall wird nur ein Sicherungsgerät beschrieben. In diesem Fall beträgt der faire Anteil des Geräts 100%. write () -Aufrufe werden gedrosselt, um den gesamten Rückschreibcache zu steuern und ihn auf einem "Sollwert" zu halten.
Schreibvorgänge werden auf halbem Weg zwischen dirty_background_ratiodem Punkt, an dem das Ausschreiben im Hintergrund eingeleitet wird, und dirty_ratiodem harten Limit für den Rückschreibcache gedrosselt. Standardmäßig sind dies 10% und 20% des verfügbaren Speichers.
Beispielsweise könnten Sie immer noch bis zu 15% nur auf Ihre Hauptfestplatte schreiben. Je nachdem, wie viel RAM Sie haben, können Gigabyte an zwischengespeicherten Schreibvorgängen vorhanden sein. Ab diesem Zeitpunkt werden write () -Aufrufe entsprechend der Rückschreibgeschwindigkeit gedrosselt - dies ist jedoch kein Problem. Ich gehe davon aus, dass die Hang-Probleme bei read () - und fsync () -Aufrufen auftreten, die hinter großen Mengen nicht verwandter E / A stecken bleiben. Dies ist das spezifische Problem, das durch den Code "Rückschreibdrosselung" behoben wird. Einige der WBT-Patch-Einreichungen enthalten Problembeschreibungen, die die schrecklichen Verzögerungen zeigen, die dies verursacht.
Ebenso könnten Sie die 15% vollständig mit Schreibvorgängen auf einen USB-Stick füllen. Weitere Schreibvorgänge () auf den USB werden gedrosselt. Die Hauptfestplatte würde jedoch keinen ihrer fairen Anteile verwenden. Wenn Sie auf Ihrem Hauptdateisystem write () aufrufen, wird es nicht gedrosselt oder zumindest viel weniger verzögert. Und ich denke, die USB-Schreibvorgänge würden noch stärker gedrosselt, um die beiden Autoren ins Gleichgewicht zu bringen.
Ich gehe davon aus, dass der gesamte Writeback-Cache vorübergehend über den Sollwert steigen könnte. In einigen anspruchsvolleren Fällen können Sie die harte Grenze für den gesamten Rückschreibcache erreichen. Die feste Grenze beträgt standardmäßig 20% des verfügbaren Speichers. Die Konfigurationsoption ist dirty_ratio/ dirty_bytes. Möglicherweise können Sie dies treffen, weil ein Gerät langsamer werden kann (möglicherweise aufgrund eines zufälligeren E / A-Musters) und eine schmutzige Drosselung die Geschwindigkeitsänderung nicht sofort erkennt.
[2] Möglicherweise wird in diesem Dokument vorgeschlagen, den Anteil des Rückschreibcaches, der für eine bestimmte Partition / ein bestimmtes Dateisystem verwendet werden kann, manuell zu begrenzen. Die Einstellung wird aufgerufen /sys/class/bdi/*/max_ratio. Beachten Sie: " Wenn das Gerät, das Sie einschränken möchten, das einzige ist, auf das derzeit geschrieben wird, hat die Begrenzung keine großen Auswirkungen ."
drop_cacheshat keine Auswirkung auf den schmutzigen Cache: Sie können das nicht einfach löschen, da es zuerst auf das Gerät zurückgeschrieben werden muss :-). Der saubere Cache, der einfach gelöscht werden kann, wird von der "No-I / O Dirty Throttling" nicht gezählt./proc/$PID/stackden Prozess im D-Zustand zu testen . (Ich vermute, dass es zehn Minuten lang nicht an einem einzigen Ort hängen bleibt - ich denke, dies würde nach 120 Sekunden zu einer Warnung für blockierte Aufgaben führen -, aber es könnte in einer Schleife stecken bleiben, die eine sehr lange Verzögerung enthält.)