Roman Gushchin () von Facebook über die Mailingliste der Linux-Kernel-Entwickler ein Patchset mit der Implementierung eines neuen Speichermanager-Controllers (slab Speichercontroller). Der neue Controller zeichnet sich durch die Übertragung der slab-Berechnung von der Seitenebene auf die Objekt-Ebene des Kernels aus, was die gemeinsame Nutzung von slab-Seiten in verschiedenen cgroups ermöglicht, anstatt separate slab-Caches für jede cgroup zuzuweisen.
Der vorgeschlagene Ansatz ermöglicht eine effizientere Nutzung des slabs, reduziert den für slab benötigten Speicher um 30-45 % und verringert den Gesamtverbrauch des Speichers durch den Kernel erheblich. Durch die Reduzierung der nicht verschiebbaren slabs zeigt sich auch ein positiver Effekt hinsichtlich der Verringerung der Speicherkollokationsfragmentierung. Der neue Speichermanager vereinfacht den Code für die slab-Berechnungen erheblich und erfordert keine komplizierten Algorithmen zur dynamischen Erstellung und Löschung von slab-Caches für jede cgroup. Alle cgroups für den Speicher in der neuen Implementierung verwenden einen gemeinsamen Satz von slab-Caches, und die Lebensdauer der slab-Caches ist nicht mehr an die Lebensdauer der durch die cgroup festgelegten Objekte gebunden um Speicher zu verwenden.
Der in der neuen Slab-Controller implementierte genauere Ressourcenverbrauch sollte theoretisch die CPU stärker belasten, jedoch haben sich die Unterschiede in der Praxis als unbedeutend herausgestellt. Insbesondere wird der neue Slab-Controller seit mehreren Monaten auf den Produktionsservern von Facebook verwendet, die unterschiedliche Arten von Lasten verarbeiten, und es wurden bisher keine nennenswerten Regressionen festgestellt. Gleichzeitig ist ein erhebliches Einsparen von Arbeitsspeicher zu beobachten — auf einigen Hosts konnten bis zu 1 GB RAM eingespart werden, jedoch hängt dieser Wert stark von der Art der Last, der Gesamtspeichergröße, der Anzahl der CPUs und den Besonderheiten der Speicherverwaltung ab. Frühere durchgeführte Tests zeigen eine Einsparung des Arbeitsspeichers von 650-700 MB (42% des Slab-Speichers) auf der Web-Frontend-Seite, 750-800 MB (35%) auf dem Server mit der DB-Cache und 700 MB (36%) auf dem DNS-Server.
Quelle: opennet.ru
