Warum Caches in Linux löschen?

Auf unseren Servern haben wir die Angewohnheit, Caches um Mitternacht zu löschen.

sync; echo 3 > /proc/sys/vm/drop_caches

Wenn ich den Code ausführe, wird scheinbar viel RAM frei, aber muss ich das wirklich tun? Ist freies RAM keine Verschwendung?

Sie sind zu 100% korrekt. Es ist keine gute Praxis, RAM freizugeben. Dies ist wahrscheinlich ein Beispiel für die Verwaltung von Frachtkult-Systemen.

Ja, das Leeren des Caches gibt RAM frei, aber der Kernel sucht nach Dateien auf der Festplatte und nicht im Cache, was zu Leistungsproblemen führen kann.

Normalerweise löscht der Kernel den Cache, wenn der verfügbare RAM erschöpft ist. Es schreibt häufig verschmutzte Inhalte mit pdflush auf die Festplatte.

Der Grund, Caches wie diesen zu löschen, dient dem Benchmarking der Festplattenleistung und ist der einzige Grund, warum dies der Fall ist.

Wenn Sie einen E / A-intensiven Benchmark ausführen, möchten Sie sicher sein, dass die verschiedenen Einstellungen, die Sie versuchen, tatsächlich für die Datenträger-E / A verwendet werden. Linux ermöglicht Ihnen daher, Caches zu löschen, anstatt einen vollständigen Neustart durchzuführen.

So zitieren Sie aus der Dokumentation :

Diese Datei ist kein Mittel, um das Wachstum der verschiedenen Kernel-Caches (Inodes, Dentries, Pagecache usw.) zu steuern. Diese Objekte werden vom Kernel automatisch wiederhergestellt, wenn an anderer Stelle im System Speicher benötigt wird.

Die Verwendung dieser Datei kann zu Leistungsproblemen führen. Da zwischengespeicherte Objekte verworfen werden, kann die Neuerstellung der abgelegten Objekte eine erhebliche Menge an E / A und CPU kosten, insbesondere wenn sie stark ausgelastet waren. Aus diesem Grund wird die Verwendung außerhalb einer Test- oder Debugging-Umgebung nicht empfohlen.

Die Grundidee hier ist wahrscheinlich nicht so schlecht (nur sehr naiv und irreführend): Es werden möglicherweise Dateien zwischengespeichert, auf die in naher Zukunft kaum zugegriffen werden kann, z. B. Protokolldateien. Diese "fressen" RAMs, die später bei Bedarf vom Betriebssystem auf die eine oder andere Weise freigegeben werden müssen.

Abhängig von Ihren Einstellungen für Austauschbarkeit, Dateizugriffsmuster, Speicherzuweisungsmuster und viele weitere unvorhersehbare Dinge kann es vorkommen, dass diese Caches, wenn Sie sie nicht freigeben, später erneut verwendet werden müssen, was etwas mehr Zeit in Anspruch nimmt als Zuweisen von Speicher aus dem Pool nicht verwendeter Speicher. Im schlimmsten Fall werden die Swap-Einstellungen von Linux dazu führen, dass der Programmspeicher ausgelagert wird, da Linux davon ausgeht, dass diese Dateien in naher Zukunft mit größerer Wahrscheinlichkeit verwendet werden als der Programmspeicher.

In meiner Umgebung schätzt Linux ziemlich oft, und zu Beginn der meisten europäischen Börsen (um 09:00 Uhr Ortszeit) werden Server Dinge tun, die sie nur einmal pro Tag tun, und müssen den Speicher austauschen, der zuvor aufgrund des Schreibens ausgelagert wurde Logfiles, Komprimieren, Kopieren usw. füllten den Cache bis zu dem Punkt, an dem Dinge ausgelagert werden mussten.

Aber ist das Löschen von Caches die Lösung für dieses Problem? definitiv nicht. Die Lösung wäre, Linux mitzuteilen, was es nicht weiß: Diese Dateien werden wahrscheinlich nicht mehr verwendet. Dies kann von der Schreibanwendung mit Dingen wie posix_fadvise()oder mit einem cmd-Linientool wie vmtouch(das auch verwendet werden kann, um Dinge zu untersuchen und Dateien zu zwischenspeichern) durchgeführt werden.

Auf diese Weise können Sie die Daten, die nicht mehr benötigt werden, aus den Caches entfernen und das Material behalten, das zwischengespeichert werden soll. Wenn Sie alle Caches löschen, muss eine Menge Material erneut von der Festplatte gelesen werden. Und das im schlimmsten Moment: wenn es gebraucht wird; Verzögerungen in Ihrer Anwendung verursachen, die spürbar und oft nicht akzeptabel sind.

Was Sie haben sollten, ist ein System, das Ihre Speicherverwendungsmuster überwacht (z. B. wenn sich etwas ändert) und dann entsprechend analysiert und entsprechend handelt. Die Lösung könnte darin bestehen, am Ende des Tages einige große Dateien mit vtouch zu entfernen. Es könnte auch sein, mehr RAM hinzuzufügen, da die tägliche Spitzenauslastung des Servers genau das ist.

Ich habe festgestellt, dass Drop-Caches beim Starten einer Reihe von virtuellen Maschinen hilfreich sind. Oder irgendetwas anderes, das große Seiten verwendet, wie zum Beispiel einige Datenbankserver.

Große Seiten in Linux müssen häufig RAM defragmentieren, um 2 MB zusammenhängenden physischen RAM zu finden, der in eine Seite eingefügt werden soll. Wenn Sie den gesamten Dateicache freigeben, ist dieser Vorgang sehr einfach.

Aber ich stimme den meisten anderen Antworten darin zu, dass es im Allgemeinen keinen guten Grund gibt, den Dateicache jede Nacht zu löschen.

Es ist möglich, dass dies eingeführt wurde, um das System zu stabilisieren, wenn es niemanden gab, der über die Fähigkeiten oder Erfahrungen verfügte, um das Problem tatsächlich zu finden.

Ressourcen freisetzen

Durch das Löschen von Caches werden im Wesentlichen einige Ressourcen freigesetzt, aber dies hat den Nebeneffekt, dass das System tatsächlich härter arbeitet, um das zu tun, was es versucht zu tun. Wenn das System austauscht (versucht, von einer Platten-Swap-Partition schneller zu lesen und zu schreiben, als es tatsächlich möglich ist), kann das regelmäßige Löschen von Caches das Symptom lindern , die Ursache wird jedoch nicht behoben .

Was frisst die Erinnerung auf?

Sie sollten feststellen, was zu einem hohen Speicherverbrauch führt, bei dem das Löschen von Caches anscheinend funktioniert. Dies kann durch eine beliebige Anzahl schlecht konfigurierter oder einfach nur falsch genutzter Serverprozesse verursacht werden. Beispielsweise konnte ich auf einem Server feststellen, dass die Speichernutzung maximal war, wenn eine Magento-Website innerhalb von 15 Minuten eine bestimmte Anzahl von Besuchern erreichte. Dies wurde letztendlich dadurch verursacht, dass Apache so konfiguriert wurde, dass zu viele Prozesse gleichzeitig ausgeführt werden können. Zu viele Prozesse, die viel Speicher verbrauchen (Magento ist manchmal ein Biest) = tauschen.

Endeffekt

Gehen Sie nicht einfach davon aus, dass es etwas ist, was notwendig ist. Finden Sie proaktiv heraus, warum es da ist, haben Sie den Mut, es zu deaktivieren, wenn andere vermuten, dass es falsch ist, und beobachten Sie das System - lernen Sie, was das eigentliche Problem ist, und beheben Sie es.

Linux / m68k hat tatsächlich einen Kernel-Fehler, der dazu führt, dass kswapd verrückt wird und 100% der CPU auffrisst (50%, wenn es eine andere CPU-gebundene Aufgabe gibt, wie z nicht immer), indem Sie diesen Befehl alle paar Stunden ausführen.

Davon abgesehen… Ihr Server ist höchstwahrscheinlich kein m68k-System (Atari, Amiga, klassischer Macintosh, VME, Q40 / Q60, Sun3) ;-)

In diesem Fall befolgte die Person, die die Zeilen einfügte, entweder fragwürdige oder bestenfalls veraltete Ratschläge oder kam auf die Idee, wie RAM falsch verwendet werden sollte. , oder "entdeckte", dass dies ein anderes Problem an anderer Stelle "behebt" (und zu faul war, um nach einer geeigneten Lösung zu suchen).

Ein Grund könnte sein, dass auf der Site eine Art Überwachung ausgeführt wird, die die Menge des freien Arbeitsspeichers überprüft und eine Warnung an Administratoren sendet, wenn der freie Arbeitsspeichers einen bestimmten Prozentsatz unterschreitet. Wenn dieses Überwachungstool dumm genug ist, um den Cache nicht in die Berechnung des freien Arbeitsspeichers einzubeziehen, werden möglicherweise falsche Warnungen gesendet. Wenn Sie den Cache regelmäßig leeren, können diese Warnungen unterdrückt werden, ohne dass das Tool merkt, dass der "echte" RAM fast leer ist.

In solchen Situationen besteht die eigentliche Lösung natürlich darin, das Überwachungstool so zu ändern, dass der Cache in die Berechnung des freien Arbeitsspeichers einbezogen wird. Das Bereinigen des Caches ist nur eine Umgehung und auch eine schlechte, da der Cache schnell wieder aufgefüllt wird, wenn Prozesse auf den Datenträger zugreifen.

Selbst wenn meine Vermutung zutrifft, ist die Cache-Bereinigung nicht sinnvoll, sondern eine Problemumgehung durch jemanden, der nicht kompetent genug ist, um das primäre Problem zu beheben.

Ich kann mir einen plausiblen Grund vorstellen, dies in einem nächtlichen Cronjob zu tun.

Auf einem großen System kann es nützlich sein, Caches regelmäßig zu löschen, damit Sie die Speicherfragmentierung entfernen können.

Die Unterstützung für transparente Riesen-Seiten im Kernel durchsucht den Speicher regelmäßig, um kleine Seiten in Riesen-Seiten zusammenzuführen. Unter entarteten Bedingungen kann dies zu Systempausen von ein oder zwei Minuten führen (meine Erfahrung mit RHEL6; hoffentlich hat sich das verbessert). Das Löschen von Caches kann dazu führen, dass der Riesen-Seiten-Sweeper etwas Platz zum Arbeiten hat.

Sie könnten argumentieren, dass dies ein guter Grund ist, transparente Riesen-Seiten zu deaktivieren. Sie können davon ausgehen, dass sich die allgemeine Leistungsverbesserung durch transparente Riesen-Seiten lohnt und Sie den Preis dafür zahlen müssen, dass Sie Ihre Caches einmal am Tag verlieren.

Ich habe mir einen anderen Grund überlegt, warum du es machen willst, obwohl du keinen Cron Job hast. Ein guter Zeitpunkt dafür wäre, bevor ein Virtualisierungssystem eine VM auf neue Hardware migriert. Weniger Speicherinhalt zum Kopieren auf den neuen Host. Sie müssen natürlich stattdessen irgendwann aus dem Speicher lesen, aber das würde ich wahrscheinlich in Kauf nehmen.

Ich weiß nicht, ob die virt-Software dies tatsächlich tut.

Nur um meine zwei Cent hinzuzufügen: Das System weiß sehr gut, dass diese Speicherseiten Caches sind, und sie werden so oft gelöscht, wie eine Anwendung nach Speicher fragt.

Eine relevante Einstellung ist /proc/sys/vm/swappiness, die dem Kernel während neuer Speicherzuweisungen anweist, lieber Speichercaches zu löschen oder "inaktive" zugewiesene Speicherseiten auszutauschen.

Die Frage stammt aus dem Jahr 2014, aber da das Problem auf einigen versteckten Centos 6.8-Backends bis heute besteht, kann es für jemanden dennoch nützlich sein.

https://github.com/zfsonlinux/zfs/issues/1548 beschreibt ein Problem mit zfs. Dort wird kein Speicherplatz für gelöschte Dateien freigegeben, da die Inodes der Datei nicht aus dem Inode-Cache des Kernels entfernt werden, wenn nfs über zfs verwendet wird.

Um aus dem Bug-Thread zu zitieren, schrieb Behlendorf am 6. Januar 2015:

Die aktuelle Vermutung ist, dass der NFS-Server aus irgendeinem Grund eine zwischengespeicherte Version des Datei-Handles verwaltet. Bis der NFS-Server diese Dateizugriffsnummer löscht, kann ZFS die Verknüpfung dieser Datei nicht aufheben. Einige Light-Tests haben gezeigt, dass das Löschen von Caches auf dem Server dazu führt, dass dieser Verweis gelöscht wird (wie das NFS-Dateihandle), und an diesem Punkt wird der Speicherplatz ordnungsgemäß freigegeben. Der Speicherdruck kann auch dazu führen, dass er abfällt.

Das heißt, ein nächtliches Echo 3> / proc / sys / vm / drop_caches ist die einfachste Lösung für diesen Fehler, wenn Sie keine Ausfallzeit für die Restrukturierung Ihres ZFS haben möchten.

Also vielleicht kein Cargo Cult Admining, aber ein ziemlich gutes Debugging war der Grund.

Dies kann bei NUMA-Systemen (Non Uniform Memory Access) sinnvoll sein, bei denen normalerweise jede CPU (Socket) transparent auf den gesamten Speicher zugreifen kann, der Zugriff auf den eigenen Speicher jedoch in Verbindung mit parallelen HPC-Anwendungen schneller als bei anderen Sockets.

Bei vielen einfachen parallelen Anwendungen werden Datei-E / A-Vorgänge in einem einzigen Prozess ausgeführt, sodass beim Verlassen ein großer Teil des Arbeitsspeichers auf einem einzelnen NUMA-Knoten verbleibt, der dem Festplatten-Cache zugewiesen ist, während auf dem anderen NUMA-Knoten der Arbeitsspeicher möglicherweise größtenteils frei ist. In diesen Situationen werden Prozesse, die auf dem NUMA-Knoten ausgeführt werden, dessen Speicher dem Cache zugewiesen ist, gezwungen, Speicher auf dem anderen NUMA-Knoten zuzuweisen, da der Cache-Rückforderungsprozess im Linux-Kernel meines Wissens immer noch nicht NUMA-fähig ist. Solange auf dem anderen Knoten freier Arbeitsspeicher vorhanden ist, werden die Leistungen beeinträchtigt.

In einem HPC-System ist es jedoch sinnvoller, den Cache zu bereinigen, bevor ein neuer Benutzerjob gestartet wird, und nicht zu einem bestimmten Zeitpunkt mit cron.

Für nicht parallele Anwendungen ist es unwahrscheinlich, dass dieses Problem auftritt.

Wenn Ihr Seiten-Cache ziemlich groß ist (viel größer als Ihre derzeitige Auslagerungsnutzung) und das Ein- und Auslagern abwechselnd erfolgt, müssen Sie die Caches löschen. Ich habe Fälle erlebt, in denen die Speichernutzung auf einem meiner MariaDB-Datenbankserver mit Ubuntu 16.04LTS zunimmt und Linux nur die Auslagerungsnutzung erhöht, anstatt nicht verwendete Seiten-Caches zu entfernen. Transparente riesige Seiten sind in meinem System bereits deaktiviert, da TokuDB die Deaktivierung erforderlich machte. Wie auch immer, vielleicht ist es kein Fehler, aber Linux, das dieses Verhalten immer noch ausführt, ist für mich ziemlich verwirrend. Verschiedene Quellen gaben an, dass Linux den Seiten-Cache entfernen würde, wenn die Anwendung dies anforderte:

• https://www.linuxatemyram.com/
• https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics

Aber die Realität ist nicht so einfach. Die Problemumgehung lautet entweder:

1. Führen Sie den Drop-Cache regelmäßig aus
2. Führen Sie den Drop-Cache bei Bedarf aus (überwachen Sie das Auslagern von Aktivitäten mithilfe von vmstat 1).
3. Raten Sie Linux, bestimmte Dateien mit einem Hilfsprogramm wie dd oder python-fadvise aus dem Cache zu entfernen (z. B. Apache-Protokolldateien). Siehe https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache

Beispiel dd run:

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

Beispiel Python-Fadvise:

pyadvise -d /var/log/apache2/access_log.1

Ich habe einen Desktop-Computer mit 16 GB RAM, der auf PAE-Kernel ausgeführt wird. Nach ein oder zwei Stunden verschlechtert sich die Festplattenleistung dramatisch, bis ich die Caches lösche und sie einfach in cron lege. Ich weiß nicht, ob dies ein Problem mit dem PAE-Kernel ist oder ob die Cache-Implementierung so langsam ist, wenn genügend Speicher vorhanden ist.