Transparente Speicherauslagerung: mehr Speicher zu einem Bruchteil der Kosten und des Stromverbrauchs

Wir erleben einen massiven Anstieg des Speicherbedarfs neuer Anwendungen, wie etwa des maschinellen Lernens, gepaart mit einer Verlangsamung der DRAM-Geräteskalierung und großen Schwankungen der DRAM-Kosten. Dies hat dazu geführt, dass DRAM als alleinige Speicherkapazitätslösung in der Größenordnung von Meta unerschwinglich teuer geworden ist.

Aber alternative Technologien wie NVMe-verbundene Solid-State-Laufwerke (SSDs) bieten eine höhere Kapazität als DRAM zu einem Bruchteil der Kosten und des Stromverbrauchs. Die transparente Auslagerung von kälterem Speicher auf solche günstigeren Speichertechnologien über Kernel- oder Hypervisor-Techniken bietet einen vielversprechenden Ansatz, um den Appetit auf DRAM einzudämmen. Die größte Herausforderung besteht jedoch darin, eine robuste Lösung im Rechenzentrumsmaßstab zu entwickeln. Eine solche Lösung muss in der Lage sein, unterschiedliche Arbeitslasten und die großen Leistungsunterschiede verschiedener Offload-Geräte wie komprimiertem Speicher, SSD und NVM zu bewältigen.

Transparent Memory Offloading (TMO) ist Metas Lösung für heterogene Rechenzentrumsumgebungen. Es führt einen neuen Linux-Kernel-Mechanismus ein, der den Arbeitsverlust aufgrund von Ressourcenknappheit bei CPU, Speicher und E/A in Echtzeit misst. Anhand dieser Informationen und ohne vorherige Anwendungskenntnisse passt TMO automatisch die Speichermenge an, die auf ein heterogenes Gerät wie komprimierten Speicher oder eine SSD verlagert werden soll. Dies erfolgt entsprechend den Leistungsmerkmalen des Geräts und der Empfindlichkeit der Anwendung gegenüber langsameren Speicherzugriffen. TMO identifiziert ganzheitlich Offloading-Möglichkeiten nicht nur aus den Anwendungscontainern, sondern auch aus den Sidecar-Containern, die Funktionen auf Infrastrukturebene bereitstellen.

TMO läuft seit mehr als einem Jahr in der Produktion und hat auf Millionen von Servern in unserer umfangreichen Rechenzentrumsflotte 20 bis 32 Prozent des Gesamtspeichers eingespart. Wir haben die Betriebssystemkomponenten von TMO erfolgreich in den Linux-Kernel hochgeladen.

In den letzten Jahren wurden eine Vielzahl billigerer Nicht-DRAM-Speichertechnologien, wie etwa NVMe-SSDs, erfolgreich in unseren Rechenzentren eingesetzt oder sind auf dem Weg. Darüber hinaus bieten neue Nicht-DDR-Speicherbustechnologien wie Compute Express Link (CXL) eine speicherähnliche Zugriffssemantik und eine DDR-ähnliche Leistung. Die in Abbildung 1 dargestellte Speicher-Speicher-Hierarchie veranschaulicht, wie verschiedene Technologien gegeneinander antreten. Das Zusammentreffen dieser Trends bietet neue Möglichkeiten für das Speicher-Tiering, die in der Vergangenheit nicht möglich waren.

Beim Speicher-Tiering werden Daten, auf die seltener zugegriffen wird, in einen langsameren Speicher verlagert. Die Anwendung selbst, eine Userspace-Bibliothek, der Kernel oder der Hypervisor können den Migrationsprozess steuern. Unsere TMO-Arbeit konzentriert sich auf die Kernel-gesteuerte Migration oder den Austausch. Warum? Weil es transparent auf viele Anwendungen angewendet werden kann, ohne dass Anwendungsänderungen erforderlich sind. Trotz seiner konzeptionellen Einfachheit ist der Kernel-gesteuerte Austausch für latenzempfindliche Rechenzentrumsanwendungen bei Hyperscale eine Herausforderung. Wir haben TMO entwickelt, eine transparente Speicherauslagerungslösung für Containerumgebungen.

TMO besteht aus folgenden Komponenten:

Der steigende DRAM-Kostenanteil im Verhältnis zu den Serverkosten motivierte unsere Arbeit an TMO. Abbildung 2 zeigt die relativen Kosten von DRAM, komprimiertem Speicher und SSD-Speicher. Wir schätzen die Kosten für komprimiertes DRAM auf der Grundlage eines dreifachen Komprimierungsverhältnisses, das für den Durchschnitt unserer Produktions-Workloads repräsentativ ist. Wir gehen davon aus, dass die Kosten für DRAM steigen und 33 Prozent unserer Infrastrukturausgaben erreichen werden. Auch wenn dies im Folgenden nicht dargestellt ist, folgt der DRAM-Stromverbrauch einem ähnlichen Trend, der voraussichtlich 38 Prozent der Leistung unserer Serverinfrastruktur erreichen wird. Dies macht komprimiertes DRAM zu einer guten Wahl für die Speicherauslagerung.

Zusätzlich zum komprimierten DRAM statten wir alle unsere Produktionsserver auch mit sehr leistungsfähigen NVMe-SSDs aus. Auf Systemebene tragen NVMe-SSDs zu weniger als 3 Prozent der Serverkosten bei (etwa dreimal weniger als komprimierter Speicher in unserer aktuellen Servergeneration). Darüber hinaus zeigt Abbildung 2, dass SSD bei Isokapazität zu DRAM über Generationen hinweg unter 1 Prozent der Serverkosten bleibt – etwa zehnmal niedriger als komprimierter Speicher in Bezug auf die Kosten pro Byte! Diese Trends machen NVMe-SSDs im Vergleich zu komprimiertem Speicher deutlich kostengünstiger.

Komprimierter Speicher und NVMe-SSDs sind zwar günstiger als DRAM, weisen jedoch schlechtere Leistungsmerkmale auf. Glücklicherweise wirken sich typische Speicherzugriffsmuster zu unseren Gunsten aus und bieten erhebliche Möglichkeiten zur Auslagerung auf langsamere Medien. Abbildung 3 zeigt den „kalten“ Anwendungsspeicher – den Prozentsatz der Seiten, auf die in den letzten fünf Minuten nicht zugegriffen wurde. Dieser Speicher kann auf komprimierten Speicher oder SSDs verlagert werden, ohne dass die Anwendungsleistung beeinträchtigt wird. Insgesamt macht der kalte Speicher durchschnittlich etwa 35 Prozent des gesamten Speichers in unserer Flotte aus. Allerdings schwankt er je nach Anwendung stark und liegt zwischen 19 und 62 Prozent. Dies unterstreicht die Bedeutung einer Offloading-Methode, die gegenüber unterschiedlichem Anwendungsverhalten robust ist.

Zusätzlich zur Zugriffshäufigkeit muss eine Offloading-Lösung berücksichtigen, welcher Speichertyp ausgelagert werden soll. Der Speicher, auf den Anwendungen zugreifen, besteht aus zwei Hauptkategorien: anonym und dateigestützt. Anonymer Speicher wird direkt von Anwendungen in Form von Heap- oder Stack-Seiten zugewiesen. Dateigestützter Speicher wird vom Seitencache des Kernels zugewiesen, um im Namen der Anwendung häufig verwendete Dateisystemdaten zu speichern. Unsere Workloads weisen eine Vielzahl von Datei- und anonymen Mischungen auf. Einige Workloads nutzen fast ausschließlich anonymen Speicher. Der Footprint anderer wird vom Seitencache dominiert. Dies erfordert, dass unsere Offloading-Lösung für anonyme Seiten und Dateiseiten gleichermaßen gut funktioniert.

TMO besteht aus mehreren Teilen im Userspace und im Kernel. Ein Userspace-Agent namens Senpai ist das Herzstück des Offloading-Vorgangs. In einer Regelschleife rund um den beobachteten Speicherdruck wird der Wiederherstellungsalgorithmus des Kernels aktiviert, um die am wenigsten genutzten Speicherseiten zu identifizieren und sie in das Offloading-Backend zu verschieben. Eine Kernelkomponente namens PSI (Pressure Stall Information) quantifiziert und meldet den Speicherdruck. Der Rückforderungsalgorithmus wird über den cgroup2-Speichercontroller des Kernels an bestimmte Anwendungen weitergeleitet.

PSI

In der Vergangenheit haben Systemadministratoren Metriken wie Seitenfehlerraten verwendet, um den Speicherzustand einer Arbeitslast zu bestimmen. Dies bringt jedoch Einschränkungen mit sich. Zum einen können Fehlerraten erhöht sein, wenn Workloads in einem Cold-Cache beginnen oder wenn Arbeitssätze übergehen. Zweitens hängt die Auswirkung einer bestimmten Fehlerrate auf die Arbeitslast stark von der Geschwindigkeit des Speicher-Backends ab. Was bei einer rotierenden Festplatte eine deutliche Verlangsamung bedeuten könnte, könnte bei einem anständigen Flash-Laufwerk ein Nicht-Ereignis sein.

PSI definiert den Speicherdruck so, dass er die tatsächlichen Auswirkungen eines Speichermangels auf die Arbeitslast erfasst. Um dies zu erreichen, verfolgt es Aufgabenzustände, die speziell aufgrund von Speichermangel auftreten – zum Beispiel ein Thread, der aufgrund einer kürzlich zurückgeforderten Seite ins Stocken gerät, oder ein Thread, der in die Zurückforderung gehen muss, um eine Zuweisungsanforderung zu erfüllen. PSI fasst dann den Status aller Threads im Container und auf Systemebene in zwei Druckindikatoren zusammen: einige und voll. Einige stellen den Zustand dar, in dem ein oder mehrere Threads ins Stocken geraten. Voll stellt den Zustand dar, in dem alle nicht inaktiven Threads gleichzeitig angehalten werden und kein Thread aktiv auf das hinarbeiten kann, was die Anwendung tatsächlich erreichen möchte. Schließlich misst PSI die Zeit, die Container und das System in diesen Aggregatzuständen verbringen, und gibt sie als Prozentsatz der Wanduhrzeit an.

Wenn beispielsweise berichtet wird, dass die Gesamtmetrik für einen Container über ein 10-Sekunden-Fenster 1 Prozent beträgt, bedeutet dies, dass für insgesamt 100 ms in diesem Zeitraum ein Speichermangel im Container zu einer gleichzeitigen unproduktiven Phase für alle Nicht-Container geführt hat. Leerlauf-Threads. Wir halten die Häufigkeit der zugrunde liegenden Ereignisse für irrelevant. Dies kann auf 10 Seitenfehler auf einer rotierenden Festplatte oder 10.000 Fehler auf einer SSD zurückzuführen sein.

Senpai liegt an der Spitze der PSI-Kennzahlen. Es verwendet Druck als Rückmeldung, um zu bestimmen, wie aggressiv die Speicherrückgewinnung des Kernels vorangetrieben werden soll. Wenn der Behälterdruck unter einem bestimmten Druckschwellenwert liegt, erhöht Senpai die Rückgewinnungsrate. Wenn der Druck darunter fällt, wird Senpai nachlassen. Der Druckschwellenwert wird so kalibriert, dass der Paging-Overhead keinen funktionalen Einfluss auf die Leistung der Arbeitslast hat.

Senpai aktiviert den Reclaim-Algorithmus des Kernels mithilfe der cgroup2-Speichercontrollerschnittstelle. Basierend auf der Abweichung vom Druckziel bestimmt Senpai die Anzahl der zurückzufordernden Seiten und weist dann den Kernel dazu an:

reclaim = current_mem * reclaim_ratio * max(0,1 – psi_some/psi_threshold)

Dies geschieht alle sechs Sekunden, sodass die Wiederherstellungsaktivität Zeit hat, sich in Arbeitslastdruck in Form von Ausfällen auf der ganzen Linie niederzuschlagen.

Ursprünglich nutzte Senpai die cgroup2-Speicherlimit-Kontrolldatei, um die Rückgewinnung voranzutreiben. Es würde den Rückforderungsschritt berechnen und dann den geltenden Grenzwert um diesen Betrag senken. Dies führte jedoch in der Praxis zu mehreren Problemen. Einerseits würde ein Absturz des Senpai-Agenten eine möglicherweise verheerende Einschränkung der Arbeitslast hinterlassen, was zu extremem Druck und sogar OOM-Kills führen würde. Selbst ohne einen Absturz war Senpai oft nicht in der Lage, das Limit bei einer schnell wachsenden Arbeitsbelastung schnell genug anzuheben. Dies führte zu Druckspitzen, die deutlich über den Belastungstoleranzen lagen. Um diese Probleme zu beheben, haben wir dem Kernel eine zustandslose cgroup-Steuerdatei „memory.reclaim“ hinzugefügt. Mit diesem Knopf kann Senpai den Kernel auffordern, genau die berechnete Speichermenge zurückzugewinnen, ohne eine Begrenzung anzuwenden, wodurch das Risiko einer Blockierung wachsender Arbeitslasten vermieden wird.

TMO zielt darauf ab, den Speicher bei einem so niedrigen Druckniveau zu entlasten, dass die Arbeitslast dadurch nicht beeinträchtigt wird. Während Linux den Dateisystem-Cache unter Druck gerne löscht, empfanden wir es als ungern, anonymen Speicher auf ein Swap-Gerät zu verschieben. Selbst wenn bekannte Cold-Heap-Seiten vorhanden sind und der Dateicache aktiv die TMO-Druckschwellen überschreitet, bleibt der konfigurierte Swap-Speicher frustrierend ungenutzt.

Der Grund für dieses Verhalten? Der Kernel entwickelte sich in einer Zeit, in der der Speicher aus Festplatten mit rotierenden Spindeln bestand. Der Suchaufwand dieser Geräte führt zu einer eher schlechten Leistung, wenn es um die durch Swapping (und Paging im Allgemeinen) erzeugten halbzufälligen E/A-Muster geht. Im Laufe der Jahre wuchs die Speichergröße immer weiter. Gleichzeitig stagnierten die Festplatten-IOP/s-Raten. Versuche, einen erheblichen Teil der Arbeitslast auszulagern, schienen zunehmend erfolglos. Ein System, das aktiv austauscht, wird häufig mit unerträglichen Latenzen und Störungen in Verbindung gebracht. Im Laufe der Zeit griff Linux größtenteils nur dann auf die Aktivierung des Swaps zurück, wenn sich der Druck dem Zustand „Out-of-Memory“ (OOM) näherte.

Allerdings ist die IOP-Kapazität moderner Flash-Laufwerke – selbst billiger – um eine Größenordnung besser als die von Festplatten. Wo selbst High-End-Festplatten im Bereich von mageren hundert IOP/s arbeiten, können handelsübliche Flash-Laufwerke problemlos Hunderttausende IOP/s bewältigen. Auf diesen Laufwerken ist das Hin- und Herschieben einiger Gigabyte keine große Sache.

TMO führt einen neuen Swap-Algorithmus ein, der diese Laufwerke nutzt, ohne alte Setups mit rotierenden Medien zu beeinträchtigen. Wir erreichen dies, indem wir die Rate der Dateisystem-Cache-Fehler im System verfolgen und den Swap direkt proportional aktivieren. Das bedeutet, dass der Kernel versucht, für jede Dateiseite, die wiederholt aus dem Dateisystem gelesen werden muss, eine anonyme Seite auszulagern. Dadurch schafft es Platz für die Prügelseite. Sollte es zu Auslagerungen kommen, schiebt Reclaim den Dateicache erneut zurück.

Diese Rückkopplungsschleife findet ein Gleichgewicht, das den insgesamt kältesten Speicher aus den beiden Pools vertreibt. Dies bedient die Arbeitslast mit der minimalen Menge an aggregiertem Paging-E/A. Da immer nur eine Art von Paging-Aktivität gegen eine andere ausgetauscht wird, ist die Leistung nie schlechter als der vorherige Algorithmus. In der Praxis beginnt der Swap bei den ersten Anzeichen einer Datei-Cache-Belastung und nutzt so den verfügbaren Swap-Speicherplatz auf dem unterschwelligen Druckniveau von TMO effektiv aus.

TMO läuft seit mehr als einem Jahr in der Produktion und hat der Meta-Flotte erhebliche Einsparungen bei der Speichernutzung beschert. Wir unterteilen die Speichereinsparungen von TMO in Einsparungen durch Anwendungen, Speichersteuer für Rechenzentren bzw. Anwendungsspeichersteuer.

Anwendungseinsparungen: Abbildung 6 zeigt die relativen Speichereinsparungen, die TMO für acht repräsentative Anwendungen mit unterschiedlichen Offload-Back-Ends, entweder komprimiertem Speicher oder SSDs, erzielt hat. Durch den Einsatz eines Back-Ends mit komprimiertem Speicher spart TMO 7 bis 12 Prozent des Speicherbedarfs

Speicher über fünf Anwendungen hinweg. Da die Daten mehrerer Anwendungen schlecht komprimierbar sind, erweist sich das Auslagern auf eine SSD als weitaus effektiver. Insbesondere verwenden maschinelle Lernmodelle, die für die Anzeigenvorhersage verwendet werden, üblicherweise quantisierte bytecodierte Werte, die ein Komprimierungsverhältnis von 1,3–1,4x aufweisen. Für diese Anwendungen zeigt Abbildung 8, dass durch die Auslagerung auf eine SSD Einsparungen von 10 bis 19 Prozent erzielt werden können. Insgesamt erzielt TMO bei komprimiertem Speicher und SSD-Backends erhebliche Einsparungen von 7 bis 19 Prozent des Gesamtspeichers, ohne dass die Anwendungsleistung spürbar beeinträchtigt wird.

Steuereinsparungen für Rechenzentrums- und Anwendungsspeicher: TMO zielt außerdem auf den Speicheraufwand ab, der durch Rechenzentrums- und Anwendungsverwaltungsdienste verursacht wird, die auf jedem Host neben der Hauptarbeitslast ausgeführt werden. Wir nennen dies die Gedächtnissteuer. Abbildung 7 zeigt die relativen Einsparungen durch die Auslagerung dieser Art von Speicher in der gesamten Meta-Flotte. Bei der Rechenzentrumssteuer spart TMO durchschnittlich 9 Prozent des Gesamtspeichers innerhalb eines Servers ein. Der Ersparnisanteil bei der Antragssteuer beträgt 4 Prozent. Insgesamt erzielt TMO durchschnittlich 13 Prozent Speichersteuereinsparungen. Dies kommt zusätzlich zu den Einsparungen bei der Arbeitslast hinzu und stellt eine beträchtliche Speichermenge im Umfang der Meta-Flotte dar.

Derzeit wählen wir das Offload-Backend manuell zwischen komprimiertem Speicher und SSD-gestütztem Swap, abhängig von der Speicherkomprimierbarkeit der Anwendung und ihrer Empfindlichkeit gegenüber einer Verlangsamung des Speicherzugriffs. Obwohl wir Tools zur Automatisierung des Prozesses entwickeln könnten, besteht eine grundlegendere Lösung darin, dass der Kernel eine Hierarchie von Offload-Backends verwaltet (z. B. automatisch zswap für wärmere Seiten und SSD für kältere oder weniger komprimierbare Seiten sowie faltbare NVM- und CXL-Geräte verwendet). in die Speicherhierarchie eingefügt werden). Der Kernel-Rückgewinnungsalgorithmus sollte sich dynamisch über diese Speicherpools verteilen. Wir arbeiten aktiv an dieser Architektur.

Bei kommenden Bustechnologien wie CXL, die eine speicherähnliche Zugriffssemantik bieten, kann die Speicherauslagerung dazu beitragen, nicht nur kalten, sondern auch warmen Speicher auszulagern. Wir konzentrieren uns aktiv auf diese Architektur, um CXL-Geräte als Back-End zur Speicherauslagerung zu nutzen.