Facebook and memcached - Tech Talk

Summary

Das Video behandelt die Architektur und Optimierungen von Facebooks mCache-System. Es zeigt, wie durch kreative Lösungen wie das Verschieben des mcash-Proxys auf SQL-Server und die Anpassung der Speicher- und CPU-Strategien die Effizienz erheblich gesteigert wurde. Optimierungen im Cache, bei Systemaufrufen und in der Kerneltiefe halfen, die Leistung zu maximieren und Kosten zu sparen. Die Skalierung auf Millionen von Nutzern führte zu weiteren Verbesserungen, die zu erheblichen Einsparungen bei Maschinenressourcen und Betriebskosten führten.

Takeaways

• 😀 Die Lösung für Synchronisierungsprobleme wurde durch den Einsatz von mcash Proxy auf den SQL-Servern an der Ostküste gefunden, wodurch die Effizienz der Replikation verbessert wurde.
• 😀 Eine Verbesserung des Speichermanagements durch die Optimierung der Slab-Zuweisung führte zu einer signifikanten Einsparung von Speicherressourcen und Kosten bei großem Maßstab.
• 😀 Die Entscheidung, anstelle der Standard-Slab-Größen eine Optimierung mit einer Potenz von 1,3 zu verwenden, erhöhte die Speichernutzung auf 90%, was zu einer großen Effizienzsteigerung führte.
• 😀 Durch eine Umstrukturierung der Systemaufrufe wurde die CPU-Leistung um 50% verbessert, was zu einer erheblichen Reduzierung der Kosten führte.
• 😀 Eine einfache, aber wirkungsvolle Optimierung im Benutzerspeicherbereich reduzierte den CPU-Verbrauch bei der Zeichenkettenparsing um das Dreifache.
• 😀 Durch die Einführung eines mcash Proxys wurde es möglich, die Verbindungslast zu reduzieren und die Synchronisation von Daten zwischen mehreren Rechenzentren weltweit aufrechtzuerhalten.
• 😀 Der Wechsel von den traditionellen Power-of-Two-Blockgrößen zu einer 1.3-fachen Blockgröße führte zu einer erheblichen Steigerung der Speichereffizienz, was bei Tausenden von Servern Millionen von Dollar einsparte.
• 😀 Die kontinuierliche Skalierung des Systems, einschließlich der Erweiterung auf Hundert Millionen Nutzer, erfordert ständige Optimierungen, um die Effizienz und Kostenkontrolle aufrechtzuerhalten.
• 😀 Der Wechsel von Standard-String-Parsen zu einer einfacheren Strategie, bei der die Länge der Zeichenkette gespeichert wird, führte zu einer drastischen Reduzierung des CPU-Verbrauchs und einer Einsparung von Ressourcen.
• 😀 Modifikationen an Netzwerk-Treibern auf Kernel-Ebene wurden vorgenommen, um die Effizienz der Netzwerkkommunikation zu steigern und damit die Gesamtleistung des Systems weiter zu verbessern.

Q & A

Was war das ursprüngliche Problem bei der Synchronisation von mCache über verschiedene Datenzentren?

Das Hauptproblem war, dass die Delete-Befehle in mCache nicht synchronisiert wurden, was zu Inkonsistenzen führte. Dies lag an der Reihenfolge, in der Löschbefehle ausgeführt wurden, was dazu führte, dass Daten verloren gingen oder nicht richtig gelöscht wurden.

Wie wurde das Synchronisationsproblem bei mCache schließlich gelöst?

Das Problem wurde durch die Platzierung des mCache-Proxys auf dem SQL-Server gelöst, statt ihn auf den Webservern laufen zu lassen. Dadurch konnte mCache über den SQL-Server synchronisiert werden, was die Effizienz und Synchronisation verbesserte.

Was ist Slab Allocation und warum wurde es verwendet?

Slab Allocation ist eine Methode zur Speicherzuweisung, die Fragmentierung minimiert, indem sie den Speicher in feste, vorgegebene Größen unterteilt. Diese Methode wurde verwendet, um den Speicher in mCache effizienter zu nutzen.

Welches Problem trat bei der Slab Allocation auf und wie wurde es gelöst?

Das ursprüngliche Problem war, dass die Slab-Größen in Zweierpotenzen (wie 256k, 512k) festgelegt waren, was zu einer schlechten Speicherverwendung führte. Nach Tests wurde festgestellt, dass eine Optimierung auf die Potenz 1,3 die Speichernutzung auf 90% erhöhte und die Verschwendung von Speicherplatz verminderte.

Welche Auswirkungen hatte die Optimierung der Slab Allocation auf die Performance und Kosten?

Durch die Optimierung konnte der Speicher viel effizienter genutzt werden, was zu einer erheblichen Kostenersparnis von Millionen von Dollar führte, da der gesamte Speicherbedarf besser genutzt wurde und somit weniger Server benötigt wurden.

Welche Verbesserung wurde bei den Systemaufrufen in Bezug auf die CPU-Auslastung vorgenommen?

Anstatt viele einzelne Systemaufrufe zu tätigen, wurde die Architektur so geändert, dass weniger, aber effizientere Systemaufrufe verwendet wurden. Dies führte zu einer 50-prozentigen Reduktion der CPU-Auslastung und trug somit zur erheblichen Reduzierung der Betriebskosten bei.

Wie wurde die Optimierung des String-Parsing-Prozesses umgesetzt?

Anstatt jedes Mal die Länge eines Strings neu zu berechnen, wurde die Länge des Strings in einer Variablen gespeichert, was zu einer Reduktion des Rechenaufwands führte. Diese Änderung verringerte die CPU-Auslastung um den Faktor drei und trug zur Senkung der Kosten bei.

Warum waren diese Optimierungen, obwohl sie klein erscheinen, so bedeutend?

Obwohl diese Optimierungen klein erscheinen mögen, hatten sie durch die große Anzahl an Servern und die Skalierung auf Millionen von Benutzern einen enormen Einfluss auf die Gesamtleistung und die Betriebskosten. Diese Optimierungen führten zu Einsparungen in Millionenhöhe.

Was war der Grund, warum Facebook (oder die betreffende Firma) begann, Änderungen auf Kernel-Ebene vorzunehmen?

Da die Firma auf eine sehr große Anzahl an Servern und Prozessoren skalierte, wurde es notwendig, die Netzwerktreiber auf Kernel-Ebene zu optimieren, um die Netzwerkleistung zu verbessern. Dies war erforderlich, um die unterbrechungsfreie Verarbeitung von Netzwerkpaketen zu gewährleisten.

Was war die Herausforderung bei der Handhabung von Netzwerkunterbrechungen und wie wurde sie gelöst?

Das Problem war, dass viele Netzwerkadapter Unterbrechungen nur an einen einzigen CPU-Core sendeten, was bei der Skalierung ineffizient wurde. Durch Anpassungen in den Netzwerktreibern konnte dieses Problem gelöst werden, sodass die Unterbrechungen besser über mehrere Kerne verteilt wurden.