Facebooks neue Speicherverwaltungsmethode

Eines der Mitglieder des Entwicklungsteams für soziale Netzwerke Facebook, Roman Guschchin, schlug in der Entwickler-Mailingliste eine Reihe von vor Linux-Kernel-Patcheszielte darauf ab, die Speicherverwaltung durch die Implementierung eines neuen Speicherverwaltungscontrollers zu verbessern - Slab (Slab-Speichercontroller).

Plattenverteilung ist ein Speicherverwaltungsmechanismus, der darauf ausgelegt ist, Speicher effizienter zuzuweisen und erhebliche Fragmentierung zu vermeiden. Die Grundlage dieses Algorithmus besteht darin, zugewiesenen Speicher, der ein Objekt eines bestimmten Typs enthält, zu speichern und diesen Speicher wiederzuverwenden, wenn er das nächste Mal für ein Objekt desselben Typs zugewiesen wird. Diese Technik wurde erstmals in SunOS von Jeff Bonwick eingeführt und wird heute in den Kerneln vieler Unix-Betriebssysteme, einschließlich FreeBSD und Linux, häufig verwendet.

Der neue Controller basiert auf der Verlagerung der Slab-Abrechnung von der Speicherseitenebene auf die Kernelobjektebene, was es ermöglicht, eine Slab-Seite in verschiedenen Kontrollgruppen zu teilen, anstatt jeder Kontrollgruppe einen separaten Cache zuzuweisen.

Basierend auf den Testergebnissen folgt, dass die vorgeschlagene Speicherverwaltungsmethode eine Erhöhung ermöglicht Wirksamkeit mit Platte zu 45%, und wird auch den Gesamtspeicherverbrauch des Betriebssystemkernels reduzieren. Durch die Reduzierung der Anzahl der für Slab zugewiesenen Seiten wird außerdem die Speicherfragmentierung insgesamt verringert, was sich zwangsläufig auf die Leistung des Systems auswirken muss.

Der neue Controller wurde mehrere Monate lang auf Facebook-Produktionsservern getestet und bisher kann dieser Test als erfolgreich bezeichnet werden: Ohne Leistungseinbußen und ohne Anstieg der Fehleranzahl konnte ein deutlicher Rückgang des Speicherverbrauchs festgestellt werden – teilweise Server bis zu 1 GB. Diese Zahl ist recht subjektiv, frühere Tests zeigten beispielsweise etwas schlechtere Ergebnisse:

  • 650-700 MB im Web-Frontend
  • 750–800 MB auf Server mit Datenbank-Cache
  • 700 MB auf dem DNS-Server

>>> Autorenseite auf GitHub


>>> Erste Testergebnisse

Source: linux.org.ru

Kommentar hinzufügen