Facebook hat einen neuen Slab-Speicherverwaltungsmechanismus für den Linux-Kernel vorgeschlagen

Roman Gushchin (Roman Gushchin) von Facebook veröffentlichte im Newsletter für Entwickler des Linux-Kernels ein Patchset mit der Implementierung eines neuen Slab-Speichercontrollers slab (slab Speichercontroller). Der neue Controller zeichnet sich dadurch aus, dass die Buchhaltung des Slabs von der Seitenebene auf die Objektebene des Kernels verlagert wird, was die gemeinsame Nutzung von Slab-Seiten zwischen verschiedenen cgroups ermöglicht, anstatt separate Slab-Caches für jede cgroup bereitzustellen.

Der vorgeschlagene Ansatz ermöglicht eine effizientere Nutzung von Slab, reduziert den für Slab verwendeten Speicher um 30-45% und verringert den gesamten Speicherbedarf des Kernels erheblich. Durch die Reduzierung der Anzahl nicht verschiebbarer Slabs gibt es auch positive Effekte im Bereich der Verringerung von Speicherfragmentierung. Der neue Speichercontroller vereinfacht den Code zur Buchhaltung von Slabs erheblich und erfordert keine komplexen Algorithmen zur dynamischen Erstellung und Löschung von Slab-Caches für jede cgroup. Alle cgroups für den Speicher verwenden in der neuen Implementierung einen gemeinsamen Satz von Slab-Caches, und die Lebensdauer der Slab-Caches ist nicht mehr an die Lebensdauer der über cgroups festgelegten Ressourcen gebunden. Einschränkungen zur Speichernutzung.

Die in dem neuen Controller implementierte genauere Ressourcenzählung sollte theoretisch die CPU stärker belasten, aber in der Praxis haben sich die Unterschiede als unbedeutend erwiesen. Insbesondere wird der neue Slab-Controller bereits seit mehreren Monaten auf den Produktionsservern von Facebook eingesetzt, die verschiedene Lasten verarbeiten, und bisher sind keine nennenswerten Regressionen festgestellt worden. Dabei wurde eine erhebliche Reduzierung des Speicherverbrauchs beobachtet – auf einigen Hosts konnten bis zu 1 GB Speicher eingespart werden, allerdings hängt dieser Wert stark von der Art der Last, der Gesamtkapazität des RAM, der Anzahl der CPUs und den Speichernutzungsarten ab. Frühere Tests haben wir gezeigt, zeigten eine Einsparung beim Speicherverbrauch von 650-700 MB (42% des Slab-Speichers) auf dem Web-Frontend, 750-800 MB (35%) auf einem Server mit einem Cache der DBMS und 700 MB (36%) auf einem DNS-Server.

Quelle: opennet.ru