it-swarm.com.de

Warum müssen wir auf E / A warten?

Es ist immer bekannt, dass Festplattenvorgänge langsam sind, und wir kennen die Gründe, warum sie langsam sind. Die Frage hier ist also, warum wir auf E/A warten müssen oder warum es so etwas wie IOWait usw. gibt.

Ich meine, ich habe bemerkt, dass wenn Sie einige E/A-Aufgaben im Hintergrund ausführen, Ihr Computer im Grunde genommen viel langsamer wird. Ich habe besonders bemerkt, dass Sie unter Linux einige längere E/A-Aufgaben ausführen wird das Betriebssystem fast unbrauchbar, bis sie fertig sind.

In der Tat habe ich dieses Thema auch in einem Artikel gefunden, es gibt einen Ausschnitt:

Die E/A-Wartezeit beträgt 12,1%. Dieser Server verfügt über 8 Kerne (über cat/proc/cpuinfo). Dies ist sehr nahe an (1/8 Kerne = 0,125)

Im Grunde bedeutet es, dass es den Computer VIEL verlangsamt. Warum ist das so? Ich meine OK, jetzt hat der normale Computer mindestens 2 Kerne, manchmal 4 oder manchmal mehr wegen Hyperthreading oder ähnlichem. Aber jetzt ist die Frage, warum die CPU tatsächlich dort bleiben muss und praktisch nichts anderes tut, als nur auf E/A zu warten? Ich meine die Grundidee oder Architektur des Prozessmanagements, jetzt weiß ich nicht, ob es das Betriebssystem ist, das dafür verantwortlich ist, oder liegt es am Hardware-Teil, aber es sollte der CPU ermöglicht werden, zu warten oder zu warten Überprüfen Sie regelmäßig, während Sie tatsächlich viele andere Aufgaben ausführen und erst dann zum IO -Prozess zurückkehren, wenn er fertig ist. Wenn dies eine so schwierige Aufgabe ist und die CPU warten müsste, warum nicht?) Ist dies beispielsweise eine Art Mini-CPU, die nur darauf wartet und den kleinen Teil der Daten an die reale CPU liefert, sobald sie wieder in den Prozess und damit in den Prozess eingeht? würde wiederholt werden und wir müssten praktisch keinen ganzen CPU-Kern für den Datenkopierprozess verwenden ... Oder wäre ich derjenige, der solche Sachen erfinden und dafür einen Nobelpreis bekommen sollte ?: S.

Okay, ich sage es jetzt wirklich aus der Perspektive eines Beobachters und ich bin wirklich nicht so tief in das Thema eingegangen, aber ich verstehe wirklich nicht, warum die CPU mit der Geschwindigkeit der Festplatte arbeiten muss, obwohl es einfach sein könnte Machen Sie etwas anderes und kehren Sie zur Festplatte zurück, sobald sie fertig ist. Die Idee ist nicht, die Anwendung zu beschleunigen, die diese IO-Operation oder den Kopiervorgang oder was auch immer benötigt), sondern die Idee, den CPU-Verbrauch während der Ausführung dieser Operation nur minimal zu beeinflussen, damit das Betriebssystem könnte es für andere Prozesse verwenden und der Benutzer müsste beim Kopieren keine allgemeine Computerverzögerung spüren ...

27
Arturas M

Die von Ihnen beschriebenen E/A-Schemata werden derzeit in Computern verwendet.

warum muss die CPU tatsächlich dort bleiben und praktisch nichts anderes tun, als nur auf E/A zu warten?

Dies ist die einfachste E/A-Methode: programmierte E/A . Viele eingebettete Systeme und Low/End-Mikroprozessoren haben nur einen einzigen Eingangsbefehl und einen einzigen Ausgangsbefehl. Der Prozessor muss für jedes gelesene oder geschriebene Zeichen eine explizite Folge von Anweisungen ausführen.

es sollte jedoch möglich sein, dass die CPU wartet oder regelmäßig überprüft, während sie tatsächlich viele andere Aufgaben ausführt und erst dann zum Prozess IO zurückkehrt, wenn sie fertig ist)

Viele PCs verfügen über andere E/A-Schemata. Anstatt in einer engen Schleife darauf zu warten, dass das Gerät bereit ist ( beschäftigt zu warten ), startet die CPU das E/A-Gerät und fordert es auf, einen Interrupt zu generieren wenn es fertig ist ( Interrupt-gesteuerte E/A ).

Interrupt-gesteuerte E/A ist zwar ein Fortschritt (im Vergleich zu programmierten E/A), erfordert jedoch einen Interrupt für jedes übertragene Zeichen und ist teuer ...

Zum Beispiel könnte es eine Art Mini-CPU geben, die nur darauf wartet und den kleinen Teil der Daten an die reale CPU liefert, sobald sie wieder in den Prozess zurückkehrt, und der Prozess wiederholt wird und wir dies nicht hätten praktisch einen ganzen CPU-Kern für den Datenkopierprozess zu widmen ...

Die Lösung für viele Probleme besteht darin, dass jemand anderes die Arbeit erledigt! :-)

Der DMA Controller/Chip (Direkter Speicherzugriff)) ermöglicht programmierte E/A, lässt es jedoch von jemand anderem ausführen!

Mit DMA muss die CPU nur einige Register initialisieren und kann etwas anderes tun, bis die Übertragung abgeschlossen ist (und ein Interrupt ausgelöst wird).

Sogar DMA ist nicht völlig kostenlos: Hochgeschwindigkeitsgeräte können viele Buszyklen für Speicherreferenzen und Gerätereferenzen verwenden ( Zyklus stehlen -)) und die CPU muss warten (DMA-Chip hat immer eine höhere Buspriorität).

Die E/A-Wartezeit beträgt 12,1%. Dieser Server verfügt über 8 Kerne (über cat/proc/cpuinfo). Dies ist sehr nahe an (1/8 Kerne = 0,125)

Ich denke, das ist von: Grundlegendes zu Festplatten-E/A - wann sollten Sie sich Sorgen machen?

Nun, es ist nicht seltsam: Das System (mySQL) muss alle Zeilen abrufen, bevor Daten bearbeitet werden, und es gibt keine anderen Aktivitäten.

Hier gibt es kein Problem mit der Computerarchitektur/dem Betriebssystem. Es ist nur so, wie das Beispiel gesetzt wird.

Es kann sich höchstens um ein RDBMS-Optimierungsproblem oder ein SQL-Abfrageproblem handeln (fehlender Index, fehlerhafter Abfrageplan, fehlerhafte Abfrage ...).

19
manlio

Es ist möglich, asynchron zu schreiben IO, wobei Sie das Betriebssystem anweisen, eine Festplatte mit Lese-/Schreibzugriff zu versenden und dann etwas anderes zu tun und später zu überprüfen, ob dies erledigt ist. Es ist alles andere als neu. Eine ältere Methode ist Verwenden eines anderen Threads für die E/A.

Dies setzt jedoch voraus, dass Sie etwas zu tun haben, während der Lesevorgang ausgeführt wird, und dass Sie den Puffer, den Sie für das Ergebnis übergeben haben, nicht berühren dürfen.

Es ist auch viel einfacher zu programmieren, wenn Sie davon ausgehen, dass alles E/A blockiert.

Wenn Sie eine blockierende Lesefunktion aufrufen, von der Sie wissen , wird sie erst zurückgegeben, wenn etwas wurde gelesen und sofort nachdem Sie mit der Verarbeitung beginnen können.

Die typische Leseschleife ist ein gutes Beispiel

//variables that the loop uses
char[1024] buffer;
while((read = fread(buffer, 1024, 1, file))>0){
    //use buffer
}

Andernfalls müssen Sie den aktuellen Funktionsstatus (normalerweise in Form eines Rückrufs + userData-Zeigers) speichern und ihn + die Kennung der Leseoperation an eine Schleife vom Typ select() zurückgeben. Wenn eine Operation beendet ist, ordnet sie die Kennung der Leseoperation dem Rückruf + Datenzeiger zu und ruft den Rückruf mit Informationen über die abgeschlossene Operation auf.

void callback(void* buffer, int result, int fd, void* userData){
    if(result<=0){
    //done, free buffer and continue to normal processing
    }
    //use buffer

    int readID = async_read(fd, buffer, userData->buff_size);
    registerCallback(readId, callback, userData);
}

Dies bedeutet auch, dass jede Funktion, die diesen asynchronen Lesevorgang verwenden könnte, in der Lage sein muss, eine asynchrone Fortsetzung zu verarbeiten. Das ist eine nicht triviale Änderung in den meisten Programmen. Sie fragen Leute, die versuchen, in asynchrones C # einzusteigen.


Synchron IO vs. asynchronous IO ist nicht die Ursache für die allgemeine Verlangsamung. Das Einlagern von Seiten ist auch eine Operation, die auf IO warten muss Der Scheduler wechselt einfach zu einem anderen Programm, das nicht auf IO, wenn eines ( IO-Wartezeit ist, wenn der Prozessor inaktiv ist) und Es gibt eine IO Operation ausstehend ).

Das eigentliche Problem ist, dass sowohl die Festplatte als auch die CPU denselben Kanal für die Kommunikation mit dem RAM verwenden ; der Speicherbus. Und wenn Sie kein RAID verwenden, gibt es nur eine einzige Festplatte, von der die Daten abgerufen werden können. Dies wird noch schlimmer, wenn Sie auch eine grafikintensive Anwendung verwenden. Dann stört auch die Kommunikation mit der GPU.

Mit anderen Worten, der eigentliche Engpass liegt wahrscheinlich eher in der Hardware als in der Software.

24
ratchet freak

Vertrauen Sie darauf, dass die Verarbeitung anderer Dinge während des Wartens auf E/A ziemlich rationalisiert ist, nahezu so rational wie möglich. Wenn Sie sehen, dass Ihr Computer nur 12,1% der Zeit auf E/A wartet, bedeutet dies, dass er tatsächlich viele andere Dinge parallel ausführt. Wenn es wirklich auf E/A warten müsste, ohne etwas anderes zu tun, würde es 99,9% der Zeit warten, so langsam ist E/A.

Die einzige Möglichkeit, mehr Dinge parallel zu erledigen, besteht darin, vorherzusagen, was der Benutzer als Nächstes tun möchte, und wir sind noch nicht sehr gut in dieser Art von Vorhersage. Wenn der Benutzer also eine Operation ausführt, bei der ein bestimmter Sektor von der Festplatte gelesen werden muss und sich dieser Sektor nicht bereits im Cache befindet, startet das Betriebssystem den sehr langen Prozess des Lesens dieses Sektors Ich werde versuchen zu sehen, ob es in der Zwischenzeit noch etwas zu tun gibt. Wenn es einen anderen Benutzer gibt, der einen anderen Sektor möchte, wird auch diese Anforderung in die Warteschlange gestellt. Irgendwann wurden alle Anfragen in die Warteschlange gestellt, und wir können nur warten, bis die erste erfüllt ist, bevor wir fortfahren können. Es ist nur eine Tatsache des Lebens.

BEARBEITEN:

Es wäre eine bewundernswerte Leistung, eine Lösung für das Problem zu finden, wie man andere Dinge während der E/A erledigt, da es gleichzeitig eine Lösung für das Problem ist, wie man andere Dinge im Leerlauf macht. Das wäre eine erstaunliche Leistung, denn es würde bedeuten, dass Sie Arbeit für Ihren Computer finden würden, obwohl er keine hat.

Sie sehen, das passiert: Ihr Computer sitzt nur 99,99% der Zeit und tut nichts. Wenn Sie ihm etwas zu tun geben, geht es und tut es. Wenn es dabei auf E/A warten muss, sitzt es dort und wartet. Wenn es während der E/A etwas anderes zu tun hat, tut es das auch. Aber wenn es außer E/A nichts anderes zu tun hat, muss es dort sitzen und warten, bis die E/A abgeschlossen ist. Es gibt keine andere Möglichkeit, dies zu umgehen, als indem Sie sich bei SETI @ Home anmelden.

9
Mike Nakis

Das Betriebssystem (es sei denn, es handelt sich um ein eingebettetes System auf sehr niedriger Ebene oder etwas ähnlich Exotisches) kümmert sich bereits darum: Wenn Ihre Anwendung auf E/A warten muss, blockiert sie normalerweise diese E/A und ein anderer Thread oder eine andere Anwendung wird aktiv. Der Scheduler entscheidet, welcher.

Nur wenn kein anderer Thread oder keine andere Anwendung ausgeführt wird, können Sie tatsächlich Wartezeiten ansammeln. In dem Artikel, den Sie zitiert haben (danke an @manlio für den Link) ist dies der Fall: Sie haben 12,1% Wartezeit gegenüber 87,4% Leerlauf, was bedeutet, dass ein Kern auf den Abschluss der E/A wartet während der Rest überhaupt nichts tut. Geben Sie diesem System etwas zu tun, vorzugsweise mehrere Dinge, und der Warteprozentsatz sollte sinken.

Eines der Hauptziele des heutigen Anwendungsdesigns besteht darin, sicherzustellen, dass die Anwendung auch dann, wenn nur eine einzige Anwendung ausgeführt wird und irgendwann auf eine E/A wartet, die Anwendung auf einem anderen Arbeitsabschnitt fortgesetzt werden kann. Threads sind ein Ansatz, nicht blockierende E/A ein anderer, aber es hängt sehr stark von der Art der Arbeit ab, die Sie ausführen, ob Sie tatsächlich etwas ohne die Daten erledigen können, auf die Sie warten.

wenn Sie unter Linux längere E/A-Aufgaben ausführen, wird das Betriebssystem fast unbrauchbar, bis diese abgeschlossen sind.

Dies ist normalerweise ein Hinweis auf eine E/A-gebundene Situation. Ich wage zu sagen, dass das System nicht langsam wird, weil es nicht genug CPU-Verarbeitung kann. Wahrscheinlicher ist es langsam, da einige Dinge von Daten von der Festplatte abhängen, die zu diesem Zeitpunkt ausgelastet ist. Dies können Anwendungen sein, die Sie ausführen möchten, deren ausführbare Dateien, Bibliotheksdateien, Symbole, Schriftarten und andere Ressourcen geladen werden müssen. Möglicherweise sind es Anwendungen, die Sie bereits ausgeführt haben, die jedoch einen Teil ihres Speichers ausgelagert haben und die jetzt erneut ausgetauscht werden müssen, um fortzufahren. Es könnte sich um einen Dämon handeln, der aus dem einen oder anderen Grund der Ansicht ist, dass er nicht nur eine Zeile in eine Protokolldatei schreiben muss, sondern diese Protokolldatei tatsächlich leeren muss, bevor eine Anfrage beantwortet wird.

Sie können Tools wie iotop verwenden, um zu sehen, wie die E/A-Kapazität Prozessen zugewiesen wird, und ionice , um E/A-Prioritäten festzulegen für Prozesse. Auf einem Desktop-Computer können Sie beispielsweise die gesamte Massendatenverarbeitung der Planungsklasse idle zuordnen, sodass die Massenverarbeitung angehalten wird, sobald eine interaktive Anwendung E/A-Bandbreite benötigt, bis die interaktive Anwendung abgeschlossen ist.

6
MvG

Dies hängt von Ihrem Anwendungscode ab. Ich gehe davon aus, dass Ihr Code unter Linux ausgeführt wird.

Sie können multi - Threading (z. B. POSIX pthreads ) verwenden, damit rechengebundene Threads einige Berechnungen durchführen, während andere E/A-gebundene Threads die IO (und darauf warten). Sie könnten sogar Ihre Anwendung ausführen lassen mehrere Prozesse Kommunikation mit Kommunikation zwischen Prozessen = (IPC), siehe Pipe (7) , Fifo (7) , Socket (7) , unix (7) , shm_overview (7) , sem_overview (7) , mmap (2) , eventfd (2) und read Advanced Linux Programming etc ....

Sie könnten nicht blockierende E/A verwenden, z. übergeben Sie O_NOBLOCK an open (2) etc etc etc ...; dann müssen Sie poll (2) und/oder SIGIOsignal (7) ... verwenden und das EWOULDBLOCK Fehler von read (2) etc ...

Sie können asynchrones POSIX-E/A verwenden, siehe aio (7)

Für den Dateizugriff können Sie Hinweise zum Seiten-Cache geben, z. mit madvise (2) nach mmap (2) und mit posix_fadvise (2) ; siehe auch das Linux-spezifische readahead (2)

Aber Sie würden irgendwann einen Hardware-Engpass erreichen (den Bus, den RAM usw.). Siehe auch ionice (1)

Ich füge einen anderen Standpunkt hinzu als andere, vielleicht umstritten:

Das typische Problem von Linux-Betriebssystemen. Speziell verzögern (Suche nach "Linux Mouse Lag"). Windows hat dieses Problem nicht. Ich habe Dual Boot Windows 7 und Linux Mint. Selbst wenn Sie unter Windows einen intensiven Festplattenbetrieb ausführen, fühlt sich Windows reibungslos an und die Maus bewegt sich normal. Unter Linux fühlt es sich nicht so glatt an und die Maus bleibt manchmal sogar beim normalen Surfen im Internet zurück.

Es liegt wahrscheinlich an der unterschiedlichen Philosophie und Geschichte dieser beiden Systeme. Windows wurde von Anfang an für normale Benutzer entwickelt, hauptsächlich für grafische Betriebssysteme. Und für Windows-Benutzer ist ein nicht reibungsloses Systemverhalten und das Anhalten der Maus ein Zeichen dafür, dass etwas nicht stimmt. Daher haben Microsoft-Programmierer hart daran gearbeitet, das gesamte System so zu gestalten, dass Fälle minimiert werden, in denen sich das System langsam anfühlt. Im Gegensatz dazu ist Linux anfangs kein grafisches System, Desktop ist hier nur eine Ergänzung von Drittanbietern. Und Linux wurde hauptsächlich für Hacker entwickelt, die die Befehlszeile verwenden. Dinge erledigen Philosophie. Linux ist einfach nicht für reibungsloses Verhalten ausgelegt, Gefühle spielen hier keine Rolle.

Hinweis: Ich sage nicht, dass Windows besser ist als Linux, ich sage, dass sie einfach eine andere Gesamtphilosophie haben, was in einer komplexen Umgebung zu einem unterschiedlichen Verhalten dieser Systeme auf hoher Ebene führen kann.

1
user3123061