Das Ausführen auf tmpfs wird nur dann schneller sein, wenn Sie viele Festplatten-E/A haben, die nicht vom Seitencache erfüllt werden.
Wenn die E/A gelesen wird und die Dateien bereits im Cache sind, macht tmpfs keinen Unterschied.
Wenn es sich bei der E/A um asynchrone Schreibvorgänge ohne Leerung handelt und die Arbeitslast eher stoßweise als kontinuierlich ist und genügend Cache vorhanden ist, um eine Schreibhäufigkeit aufzusaugen, und die Schreibvorgänge im Hintergrund zwischen den Bursts geleert werden können, macht tmpfs keinen Unterschied.
Wenn keine Festplatten-E/A durchgeführt werden muss, macht tmpfs keinen Unterschied.
Wenn Sie viele Festplatten-E/A haben und Ihr Prozess blockiert ist, weil er darauf wartet, dass der Speicher aufholt, wird die Ausführung auf tmpfs einen großen Unterschied machen. Je langsamer Ihre Festplatten sind, desto größer ist der Unterschied, bis zu dem Punkt, an dem Sie einen CPU-Engpass bekommen.
(4) Die ausführbare Datei wird innerhalb eines Docker-Containers ausgeführt, und die ausführbare Datei und alle beteiligten Dateien befinden sich in einem tmpfs-Ordner, der innerhalb des Containers erstellt wurde, unter einem „internen“ Laufwerk (das nicht bestehen bleibt, nachdem der Container angehalten wurde).
(5) Die ausführbare Datei wird in einem Docker-Container ausgeführt, und die ausführbare Datei und alle beteiligten Dateien befinden sich in „normalen“ Festplattenordnern.
Abgesehen von Tmpfs (das bereits angesprochen wurde) werden Sie keinen Unterschied zwischen dem Ausführen von ausführbaren Dateien auf dem Host und aus einem Docker-Container bemerken. Dasselbe gilt für die Datenträgerspeicherung. Docker läuft sowohl mit einem Overlay-Dateisystem als auch mit einem sehr kleiner Leistungseinbruch für das Overlay, aber der Host sieht die ausführbare Datei als laufenden Prozess, als ob sie auf dem Host gestartet worden wäre.
Realistischerweise sollte es einen Unterschied von nahezu null oder null geben. Es mag triftige Gründe geben, so etwas zu tun, aber ich wage zu behaupten, dass es in 99,9 % aller Fälle eine Anti-Optimierung ist.
Normale I/O gehen in den Buffer-Cache und Dirty Pages werden asynchron von einem Kernel-Thread geschrieben. Bandbreite =RAM-Geschwindigkeit, Verzögerung =RAM-Verzögerung (plus hier und da vielleicht ein paar µs für einen Seitenfehler).
Wenn dem System der physische RAM ausgeht, werden Sie (offensichtlich) blockieren, es gibt keinen anderen Weg. Wenn keine Seiten mehr vorhanden sind, auf die Sie schreiben könnten, müssen Sie warten, bis einige freigegeben werden. Es geht nicht anders.
In Ihrem speziellen Fall ist es jedoch per Definition nicht wahrscheinlich (oder möglich), dass der Arbeitsspeicher ausgeht. Andernfalls, wenn tatsächlich die Möglichkeit besteht, dass der Arbeitsspeicher knapp wird, wäre die Idee, ein tmpfs zu erstellen, von vornherein ziemlich dumm.
I/O an tmpfs geht an... den Buffer-Cache. Ja, jetzt läuft es unter einem anderen Namen, aber in Wirklichkeit ist es aufgrund des einheitlichen VM-Systems genau dasselbe. Bandbreite und Verzögerung sind daher genau gleich (geben oder nehmen vielleicht 1% Unterschied aufgrund von Feinheiten des Dateisystems, die leicht unterschiedlich sein können). Es findet kein Rückschreiben statt, ja. Aber wen interessiert es, wenn man sieht, wie es ohnehin asynchron ablaufen würde. Im Gegenteil, Sie haben jetzt nicht den Luxus, dass jemand schmutzige Seiten im Hintergrund befreit, sodass die Wahrscheinlichkeit, dass Sie an die Decke stoßen, wenn dies möglich ist, tatsächlich höher ist.
Wenn dem System der physische RAM ausgeht, schreiben Sie immer noch nur auf Seiten, die im Speicher abgebildet sind, also sollten Sie das theoretisch schneller tun können. In der Praxis gibt es jedoch immer noch nur so und so viel physikalisches RAM, und es ist Ihnen gerade ausgegangen! Sicher, in Ihrem tmpfs ist vielleicht noch Platz, aber aus irgendeinem Grund Sie auch müssen sonst eine Speicherseite schreiben, und es sind keine mehr übrig.
Also muss der Kernel irgendwas tun um das System am Laufen zu halten. Es muss irgendwie Ordnen Sie seine Ressourcen neu an, um das Problem zu mindern (möglicherweise den Docker-Prozess und den gesamten Container austauschen?!). Der Kernel wird sich Mühe geben, aber es ist nicht so, dass er zaubern kann, er muss etwas tun , und seine Auswahl ist begrenzt. Umso mehr, als Sie absichtlich eine große Anzahl von Seiten weggenommen haben, die es sonst nach Bedarf für jeden Zweck frei verwenden könnte (einschließlich der Anfrage, die jetzt bearbeitet werden muss).