Was macht grep, wenn die CPU nicht läuft?

Bei der Suche nach Übereinstimmungen mit grepstelle ich häufig fest, dass die nachfolgende Suche erheblich weniger Zeit in Anspruch nimmt als die erste - z. B. 25s vs. 2s. Es liegt auf der Hand, dass die Datenstrukturen aus der letzten Ausführung nicht wiederverwendet wurden - diese sollten freigegeben werden. Als ich einen timeBefehl ausführte grep, bemerkte ich ein interessantes Phänomen:

real    24m36.561s
user    1m20.080s
sys     0m7.230s

Wohin geht der Rest der Zeit? Kann ich irgendetwas tun, damit es jedes Mal schnell läuft? (zB einen anderen Prozess die Dateien lesen lassen, bevor sie grepdurchsucht werden.)

grep performance

— Alex
quelle

Antworten:

Es hängt ziemlich oft mit dem Seiten-Cache zusammen .

Beim ersten Mal müssen die Daten (physisch) von der Festplatte gelesen werden.

Beim zweiten Mal (für nicht zu große Dateien) befindet es sich wahrscheinlich im Seiten-Cache.

Sie könnten also zuerst einen Befehl wie cat (1) ausgeben , um die (nicht zu große) Datei in den Seiten-Cache (dh in den RAM) zu bringen, dann würde ein zweites grep (1) (oder ein beliebiges Programm, das die Datei liest) im Allgemeinen schneller ausgeführt .

^{(Die Daten müssen jedoch zu einem bestimmten Zeitpunkt noch von der Festplatte gelesen werden.)}

Siehe auch (manchmal nützlich in Ihren Anwendungsprogrammen, aber praktisch selten) readahead (2) & posix_fadvise (2) und vielleicht madvise (2) & sync (2) & fsync (2) etc ....

Lesen Sie auch LinuxAteMyRAM .

Übrigens, aus diesem Grund wird empfohlen, ein Programm beim Benchmarking mehrmals auszuführen. Dies ist auch der Grund, warum es nützlich sein kann, mehr RAM zu kaufen (auch wenn Sie nicht alle Programme ausführen, um deren Daten zu erhalten).

Wenn Sie mehr verstehen möchten, lesen Sie ein Buch wie z. B. Betriebssysteme: Drei einfache Teile

— Basile Starynkevitch
quelle

Die TL;DRAntwort lautet also "[block waiting for] I / O".

— Margarciaisaia

@PaulDraper Nicht wirklich :) cat+ grepwird noch länger dauern als grepalleine.

— Chepner

@chepner Es sei denn, Sie können Multithreading und catPre-Fetch als billige Option verwenden, während Sie etwas anderes tun, um sich auf das grepvon Interesse vorzubereiten .

— hBy2Py

@ MarkKCowan: Schöne Katzen! :-) ⁠

— G-Man sagt 'Reinstate Monica'

@ G-Man: Sie können auch zwei der cats mit tacfür den gleichen Effekt und höhere RAM-Auslastung ersetzen : D Oder alle Katzen mit tac

— Mark K Cowan

-1

In einer Netzwerkspeicherumgebung kann es auch zu relativ erheblichen Verzögerungen kommen, wenn Sie zum ersten Mal auf eine Datei zugreifen, die sich auf einem vom Server getrennten "Filer" befindet. Sobald auf diese Datei auf dem Server zugegriffen wurde, wird sie lokal zwischengespeichert, und der nachfolgende Zugriff auf die Daten erfolgt viel schneller.

Hier ist ein Experiment, bei dem nur eine Prüfsumme der Dateidaten berechnet wird - nicht grep. Der erste Aufruf ist langsam und die folgenden sind schnell.

> du -Dh file_348m
348M    file_348m

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.60user 0.15system 0:03.02elapsed 25%CPU (0avgtext+0avgdata 1524maxresident)k
708144inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.67user 0.06system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.65user 0.07system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.66user 0.06system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

— Winston Smith
quelle

Ich würde mich über Kommentare zu Abstimmungen freuen, da ich nicht weiß, wie ich sie interpretieren soll. Ich glaube, meine Antwortbeschreibung ist korrekt. Vielleicht ist das Befehlsbeispiel nicht klar? Oder gefällt es Ihnen nicht, dass ich den grep-Befehl nicht bewertet habe? (Ich habe absichtlich einen einfacheren Befehl, md5sum, verwendet, um meinen Standpunkt zu veranschaulichen.)

— Winston Smith

Ich denke, der Grund dafür ist, dass in Ihrem Beitrag keine neuen Informationen hinzugefügt wurden, die für das, was ich gefragt habe, relevant sind. Ich wusste bereits, dass es eine Verzögerung gibt, und die erste Antwort gab bereits eine Erklärung dafür, warum es passiert. Aber ja, ich bekomme auch Abstimmungen ohne Erklärung. Auch bei Fragen mit guten Antworten.

— Alex

Vielen Dank an @Alex für die Begründung. Ich habe versucht, zwischen der in der ersten Antwort beschriebenen Overhead-Zeit für das Verschieben von Daten vom lokalen Speicher in den Speicher und der Overhead-Zeit für das Verschieben von Daten vom Netzwerkspeicher auf den lokalen Server zu unterscheiden. Ich werde überlegen, ob ich dies klarer beschreiben oder bessere Befehlsbeispiele liefern könnte.

— Winston Smith

Ich denke, nachdem ich Ihren Beitrag gelesen habe, ist mein Gedanke, dass es immer noch der Overhead ist, Daten von dort, wo sie gespeichert sind, in den Speicher zu verschieben. Ob aus dem Netzwerkspeicher oder aus dem lokalen Speicher, spielt keine Rolle - Unix sieht es immer noch als Verschiebung von einem Verzeichnis in den Speicher. ps-- es sieht so aus, als ob meine Erklärung richtig ist-- mein Kommentar mit dem Grund wurde positiv bewertet.

— Alex

Ich habe eine Unterscheidung hinzugefügt, die für das, wonach Sie gesucht haben, nicht wichtig ist. OKAY. Übrigens, ich habe Ihren Kommentar positiv bewertet, damit die Frage nach dem Grund für die Ablehnung nicht geklärt wird. :-)

— Winston Smith