Facebook's nieuwe geheugenbeheermethode

Een van de leden van het ontwikkelingsteam voor sociale netwerken Facebook, Roman Gushchin, voorgesteld in de mailinglijst voor ontwikkelaars een set van Linux-kernelpatchesgericht op het verbeteren van het geheugenbeheer door de implementatie van een nieuwe geheugenbeheercontroller - slab (plaatgeheugencontroller).

verdeling van de platen is een geheugenbeheermechanisme dat is ontworpen om geheugen efficiënter toe te wijzen en aanzienlijke fragmentatie te elimineren. De basis van dit algoritme is het opslaan van toegewezen geheugen dat een object van een bepaald type bevat, en het hergebruiken van dat geheugen de volgende keer dat het wordt toegewezen voor een object van hetzelfde type. Deze techniek werd voor het eerst geïntroduceerd in SunOS door Jeff Bonwick en wordt nu veel gebruikt in de kernels van veel Unix-besturingssystemen, waaronder FreeBSD en Linux.

De nieuwe controller is gebaseerd op het verplaatsen van slab-accounting van het geheugenpaginaniveau naar het kernelobjectniveau, wat het mogelijk maakt om één slab-pagina in verschillende cgroups te delen, in plaats van een afzonderlijke cache voor elke cgroup toe te wijzen.

Op basis van de testresultaten volgt hieruit dat de voorgestelde geheugenbeheermethode toename mogelijk maakt effectiviteit plaat gebruiken tot 45%, en zal ook het algehele geheugengebruik van de OS-kernel verminderen. Door het aantal pagina's dat aan de plaat wordt toegewezen te verminderen, wordt ook de geheugenfragmentatie als geheel verminderd, wat alleen maar de prestaties van het systeem kan beïnvloeden.

De nieuwe controller is al enkele maanden getest op productie-Facebook-servers en tot nu toe kan deze test succesvol worden genoemd: zonder prestatieverlies en zonder toename van het aantal fouten is een duidelijke afname van het geheugengebruik opgemerkt - op sommige servers tot 1 GB. Dit aantal is behoorlijk subjectief, eerdere tests lieten bijvoorbeeld iets lagere resultaten zien:

  • 650-700 MB op de webfrontend
  • 750-800 MB op server met databasecache
  • 700 MB op DNS-server

>>> Auteurspagina op GitHub


>>> Eerste testresultaten

Bron: linux.org.ru

Voeg een reactie