Befehlesind beispielsweise sedProgramme und Programme sind kodierte Logik in einer Datei und diese Dateien befinden sich irgendwo auf der Festplatte. Wenn jedoch Befehle ausgeführt werden, wird eine Kopie ihrer Dateien von derFestplattewird in dieRAM, wo sie zum Leben erwachen und Dinge tun können und heißenProzesse.
Prozesse können andere Dateien verwenden, sie lesen oder in sie schreiben. Wenn sie das tun, werden diese Dateien als offene Dateien bezeichnet. Es gibt einen Befehl, um alle offenen Dateien aller laufenden Prozesse aufzulisten: lsof.
OK, ich frage mich also, ob die Doppellebensdauer eines Befehls, einer auf der Festplatte, der andere im RAM, auch für andere Dateitypen gilt, beispielsweise für solche, in denen keine Logik programmiert ist, sondern die lediglich Container für Daten sind.
Ich gehe davon aus, dass von Prozessen geöffnete Dateien auch in den RAM geladen werden. Ich weiß nicht, ob das stimmt, es ist nur eine Intuition.
Kann das bitte jemand erklären?
Antwort1
Nein, eine Datei wird nicht automatisch in den Speicher gelesen, wenn sie geöffnet wird. Das wäre schrecklich ineffizient. sedliest beispielsweise seine Eingabe zeilenweise, wie viele andere Unix-Tools auch. Es muss selten mehr als die aktuelle Zeile im Speicher behalten.
Mit awkihm ist es dasselbe. Es liest sich wieaufzeichnenauf einmal, was standardmäßig eine Zeile ist. Wenn Sie Teile der Eingabedaten in Variablen speichern, kostet das natürlich zusätzlich 1 .
Manche Leute haben die Angewohnheit, Dinge zu tun wie
for line in $(cat file); do ...; done
$(cat file)Da die Shell die Befehlssubstitution vollständig erweitern muss, bevor sie auch nur die erste Iteration der forSchleife ausführen kann,Willealles filein den Speicher lesen (in den Speicher, der von der Shell verwendet wird, die die forSchleife ausführt). Das ist ein bisschen albern und auch unelegant. Stattdessen sollte man
while IFS= read -r line; do ...; done <file
Dies wird fileZeile für Zeile abgearbeitet (lesen Sie jedoch„IFS= read -r line“ verstehen).
Die zeilenweise Verarbeitung von Dateien in der Shell ist allerdings nur selten erforderlich, da die meisten Dienstprogramme ohnehin zeilenorientiert sind (sieheWarum gilt die Verwendung einer Shell-Schleife zur Textverarbeitung als schlechte Praxis?).
Ich arbeite in der Bioinformatik und bei der Verarbeitung riesiger Mengen genomischer Daten könnte ich nicht viel tun, wenn ich nicht nur die Datenbits im Speicher behalten würde, die unbedingt erforderlich sind. Wenn ich beispielsweise die Datenbits entfernen muss, die zur Identifizierung von Personen aus einem 1 Terabyte großen Datensatz mit DNA-Varianten in einer VCF-Datei verwendet werden könnten (weil diese Art von Daten nicht öffentlich gemacht werden kann), verarbeite ich sie Zeile für Zeile mit einem einfachen awkProgramm (das ist möglich, da das VCF-Format zeilenorientiert ist). Ichnichtdie Datei in den Speicher lesen, dort verarbeiten und wieder ausgeben! Wenn die Datei komprimiert wäre, würde ich sie durch zcatoder laufen lassen gzip -d -c, was, da gzipes eine Stream-Verarbeitung der Daten durchführt, auch nicht die ganze Datei in den Speicher lesen würde.
Auch bei Dateiformaten, dienichtZeilenorientiert, wie JSON oder XML, gibt es Stream-Parser, die es ermöglichen, große Dateien zu verarbeiten, ohne sie alle im RAM zu speichern.
Bei ausführbaren Dateien ist es etwas komplizierter, da gemeinsam genutzte Bibliotheken bei Bedarf geladen und/oder von mehreren Prozessen gemeinsam genutzt werden können (sieheLaden gemeinsam genutzter Bibliotheken und RAM-Nutzung, Zum Beispiel).
Caching habe ich hier noch nicht erwähnt. Dabei wird RAM verwendet, um häufig aufgerufene Daten zu speichern. Kleinere Dateien (z. B. ausführbare Dateien) können vom Betriebssystem in der Hoffnung zwischengespeichert werden, dass der Benutzer häufig auf sie verweist. Abgesehen vom ersten Lesen der Datei werden nachfolgende Zugriffe auf RAM und nicht auf die Festplatte vorgenommen. Caching ist, wie das Puffern von Eingabe und Ausgabe, für den Benutzer normalerweise weitgehend transparent, und die zum Zwischenspeichern verwendete Speichermenge kann sich dynamisch ändern, je nachdem, wie viel RAM von Anwendungen usw. zugewiesen wird.
1 Technisch gesehen lesen die meisten Programme wahrscheinlich einen Block der Eingabedaten auf einmal, entweder durch explizite Pufferung oder implizit durch die Pufferung, die die Standard-E/A-Bibliotheken verwenden, und präsentieren diesen Block dann Zeile für Zeile dem Code des Benutzers. Es ist viel effizienter, ein Vielfaches der Blockgröße der Festplatte zu lesen, als beispielsweise ein Zeichen auf einmal. Diese Blockgröße wird jedoch selten größer als eine Handvoll Kilobyte sein.
Antwort2
Wenn jedoch Befehle ausgeführt werden, wird eine Kopie ihrer Dateien von der Festplatte in den RAM übertragen.
Das ist (im Allgemeinen) falsch. Wenn ein Programm ausgeführt wird (durchexecve(2)...) der Prozess (der das Programm ausführt) ändert seinevirtueller Adressraumund der Kernel konfiguriert denMMUzu diesem Zweck. Lesen Sie auch übervirtueller SpeicherBeachten Sie, dass Anwendungsprogramme ihren virtuellen Adressraum ändern können mitmmap(2)& munmap&mprotect(2), auch verwendet vondynamischer Linker(sehenld-linux(8)). Siehe auchmadvise(2)undposix_fadvise(2)undmlock(2).
ZukunftSeitenfehlerwird vom Kernel verarbeitet, um Seiten aus der ausführbaren Datei (verzögert) zu laden. Lesen Sie auch überPrügel.
Der Kernel verwaltet eine großeSeitencacheLesen Sie auch überKopieren beim Schreiben. Siehe auchvorauslesen(2).
OK, ich frage mich also, ob die Doppellebensdauer eines Befehls, einer auf der Festplatte, der andere im RAM, auch für andere Dateitypen gilt, beispielsweise für solche, in denen keine Logik programmiert ist, sondern die lediglich Container für Daten sind.
FürSystemaufrufewielesen(2)undschreiben(2)der Seitencache wird ebenfalls verwendet. Wenn die zu lesenden Daten darin liegen, wird kein Festplatten-E/A ausgeführt. Wenn Festplatten-E/A erforderlich ist, werden die gelesenen Daten sehr wahrscheinlich in den Seitencache gestellt. Wenn Sie also in der Praxis denselben Befehl zweimal ausführen, kann es passieren, dass beim zweiten Mal kein physischer E/A auf der Festplatte ausgeführt wird (wenn Sie eine alte rotierende Festplatte haben – keine SSD –, hören Sie das möglicherweise; oder beobachten Sie die LED Ihrer Festplatte sorgfältig).
Ich empfehle, ein Buch zu lesen wieBetriebssysteme: Drei einfache Teile(kostenlos herunterladbar, eine PDF-Datei pro Kapitel), in der all dies erklärt wird.
Siehe auchLinux hat meinen RAM aufgefressenund führen Sie Befehle wie xosview, top, htopoder cat /proc/self/mapsoder aus cat /proc/$$/maps(sieheproc(5)).
PS. Ich konzentriere mich auf Linux, aber auch andere Betriebssysteme haben virtuellen Speicher und Seitencache.
Antwort3
Nein. Obwohl es heutzutage fantastisch ist, Gigabyte an RAM zu haben, gab es eine Zeit, in der RAM eine sehr begrenzte Ressource war (ich habe das Programmieren auf einem VAX 11/750 mit 2 MB RAM gelernt) und das einzige, was sich im RAM befand, waren aktive ausführbare Dateien und Datenseiten aktiver Prozesse sowie Dateidaten, die sich im Puffercache befanden.
Der Puffercache wurde geleert und Datenseiten wurden ausgelagert. Und das oft. Die schreibgeschützten ausführbaren Seiten wurden überschrieben und Seitentabellen markiert, sodass diese Seiten aus dem Dateisystem ausgelagert wurden, wenn das Programm sie erneut berührte. Daten wurden aus dem Swap-Speicher ausgelagert. Wie oben erwähnt, hat die STDIO-Bibliothek Daten in Blöcken abgerufen und sie wurden vom Programm nach Bedarf abgerufen: fgetc, fgets, fread usw. Mit mmap konnte eine Datei in den Adressraum eines Prozesses abgebildet werden, wie dies mit gemeinsam genutzten Bibliotheksobjekten oder sogar normalen Dateien geschieht. Ja, Sie haben möglicherweise ein gewisses Maß an Kontrolle darüber, ob sich etwas im RAM befindet oder nicht (mlock), aber das reicht nicht aus (siehe den Abschnitt mit den Fehlercodes von mlock).