Home Technische Artikel Serveroptimierung im Maßstab: Vermeidung von Paketverlusten und Verbesserung der Kapazität
Applications

Serveroptimierung im Maßstab: Vermeidung von Paketverlusten und Verbesserung der Kapazität

About The Author

Outline

Die Verbesserung der Leistung unserer Technologie zum Nutzen unserer Kunden und ihrer Zielgruppen ist ein kontinuierliches Vorgehen bei Verizon Media, dem heutigen Edgio. In den letzten zwei Jahren haben unsere Performance- und Kernel-Ingenieure beispielsweise praktisch alle Paketverluste beseitigt (über 98 % entfernt), die Performance-Integritätsprüfungen auf unseren Edge-Servern um 50 % verbessert und die Serverkapazität um bis zu 40 % erhöht.

Darüber hinaus haben wir das oben genannte mit Netzwerkautomatisierung und organischer Netzwerkerweiterung – derzeit über 250 Tbit/s – gekoppelt, um die Benutzererfahrung zu verbessern. Die sorgfältige Abstimmung unserer Leistung hat eine wichtige Rolle dabei gespielt, schnell wechselnde und manchmal unvorhersehbare Netzwerkstöße zu unterstützen, da wir Software-Updates für Millionen von Spielkonsolen, Live-Video-Streams für große Sportereignisse bereitstellen und wenn Multi-CDN-Load Balancer die Last in unser Netzwerk verschieben.

Um die Qualität im Maßstab zu halten, müssen Sie die Leistung in allen Bereichen der Edgio Media Platform optimieren: Von den unteren Schichten über CPU und NIC bis hin zum Betriebssystem und den Anwendungen. Letztendlich ist unser Ziel immer dasselbe: Großartige Leistung. Um dies zu erreichen, führen wir datengestützte Analysen durch, wobei wir uns auf messbare Leistungsänderungen verlassen, um unsere Entscheidungsfindung zu validieren.

CPU-Cache-Optimierungen

Wir betreiben weltweit 20.000 Server, hauptsächlich Broadwell- und Haswell-Chipsätze, typischerweise mit 32 bis 40 Kernen. Allein in den letzten drei Jahren haben wir 12.000 Server hinzugefügt. Die meisten Server sind jedoch nicht für die vorkonfigurierte Skalierung für unsere Workloads optimiert. Das Hinzufügen weiterer Server führt nicht zu einem effizienteren Betrieb und kann zusätzliche Herausforderungen mit sich bringen. Eine effektive Skalierung erfordert eine sorgfältige Optimierung vorhandener Komponenten. Die Möglichkeit, einen Server so zu optimieren, dass er zwei- oder dreimal (oder mehr) Anforderungen verarbeiten kann als mit der Standardkonfiguration, kann einen entscheidenden Unterschied für die Gesamtleistung des Netzwerks ausmachen.

Der Wechsel von Early Snoop zu Home Snoop

Moderne CPUs verwenden ein Snoop-Protokoll, um sicherzustellen, dass der lokale CPU-Cache mit dem Speicher konsistent ist. Dadurch können Caches auf Änderungen an Variablen in jeder CPU abhören und ihre Versionen dieser Variablen entsprechend aktualisieren. Es überrascht nicht, dass die verwendete Technik die Speicherleistung erheblich beeinträchtigen kann.

Standardmäßig verwenden unsere Hardwarehersteller ein Protokoll namens Early Snoop. Es hat eine geringere Latenz, um die Cache-Kohärenz aufzulösen, da alle Kerne gleichzeitig Cache-Kohärenzanforderungen erstellen und Broadcasts senden können. Wir haben herausgefunden, dass unsere Systeme während Spitzenlastszenarien große Mengen an gleichzeitiger Festplatten- und NIC-Aktivität erzeugen. Diese Aktivitäten führen zu hohen Snoop-Übertragungen, was zu Kommunikationsengpässen führt. Dies führt dazu, dass das E/A-Gerät langsamer wird und letztendlich dazu führen kann, dass die Verarbeitung vollständig gestoppt wird.

Durch den Wechsel in den Home Snoop-Modus, ein Ansatz, der Snoop-Anforderungen zusammenfasst, konnten wir eine erhebliche Verringerung des Broadcast-Datenverkehrs feststellen. Das Quick Path Interconnect (QPI) des Prozessors ist in Zeiten gleichzeitiger Operationen mit schweren Festplatten und Netzwerk-I/O nicht mehr ausgehungert. Außerdem haben sich die Paketverluste, die wir mit Early Snoop beobachtet haben, deutlich verringert.

Das Ändern des snoop-Protokolls hängt einfach von der Änderung einer BIOS-Einstellung ab. Der Neustart von 20.000 Servern ohne Unterbrechungen der Kunden erfordert jedoch Automatisierung. Wir können diese Art von umfangreichen Implementierungsänderungen in der Produktion zum Teil dank unserer StackStorm-basierten IT-Automatisierungsplattform Crayfish umsetzen.

Ein unerwartetes Failover-Ereignis

Beim Testen des Switches zu Home Snoop kam es zu einem Failover: Einer unserer größten Medienkunden, der über eine Multi-CDN-Bereitstellung verfügt, hatte ein Problem mit einem anderen Anbieter und verlagerte einen erheblichen Teil seines Datenverkehrs auf unser CDN. Dies bot die Gelegenheit, die umfangreichen Verbesserungen bei Home Snoop zu testen, die äußerst wirkungsvoll waren.

Die obige Abbildung zeigt die Auswirkungen der Änderung. Die Gruppe, die Early Snoop noch einsetzte, verzeichnete einen Anstieg der Abgänge um das 13,75-fache (55 Paketabfälle pro Server und Tag), während die Gruppe, die zu Home Snoop gewechselt hatte, nur einen Anstieg um das 4,23-fache verzeichnete (27.000 Paketabfälle pro Computer und Tag). Home Snoop hat seinen Wert sofort während des Failover-Ereignisses unter Beweis gestellt.

Optimierung der Netzwerkschnittstelle und Treiberoptimierung

Eine weitere wichtige Leistungsoptimierung betraf die Netzwerkschnittstelle und den Treiber. Hier konzentrierten wir uns auf die Reduzierung von Paketabfällen, die normalerweise bei Burst-Traffic auftreten. Bei großen Ereignissen war der eingehende Datenverkehr so hoch, dass die NIC nicht mithalten konnte, und wir konnten Paketabfälle früher als erwartet beobachten. Als wir uns die Gründe dafür genauer angesehen haben, stellten wir fest, dass mehrere Parameter auf der NIC selbst angepasst werden mussten, darunter die Anzahl der Warteschlangen, die Warteschlangengröße und die Interrupt-Planung. Um diese Spezifikationen für unsere spezielle Workload- und Hardwarekonfiguration zu optimieren, konzentrierten wir uns auf die Optimierung der RSS (Receive Side Scaling), indem wir die eingehenden Warteschlangen verlängern, ihre Gesamtzahl reduzieren und die Interrupts auf NUMA-Knoten verteilen.

Das Diagramm oben zeigt einen Test, den wir in Nordamerika durchgeführt haben, bei dem jeder Pop in eine Kontrollgruppe (d. h. nicht abgestimmt) und eine Testgruppe (d. h. abgestimmt) unterteilt ist. Hier stellen wir die Anzahl der Tropfen dar, die täglich über eine Woche summiert werden. Im Anschluss an die Tunings verzeichnete unsere Testgruppe ca. 95 % weniger Paketabfälle als die Kontrollgruppe, sodass deutlich mehr Anfragen verarbeitet werden konnten. Dies bedeutet auch, dass weniger Maßnahmen erforderlich sind, um den Zustand des Netzwerks bei Überspannungen manuell zu verwalten, sodass sich unsere Ingenieure auf andere Bereiche konzentrieren können.

Optimierung der CPU-Planung

Während sich die Optimierung auf NIC- und Treiberebene auf die Verbesserung der Gesamtkapazität konzentrierte, die wir bereitstellen können, konzentrierte sich die Optimierung der CPU-Planung darauf, die konsistente Bereitstellung von Inhalten zu verbessern.

Ohne diese Optimierungen müssen eingehende und ausgehende Nachrichten um Ressourcen konkurrieren. Als wir mit der Untersuchung der Grundursache begannen, stellten wir fest, dass der Konflikt um Ressourcen darauf zurückzuführen war, wie der Kernel die Verarbeitung dieser Nachrichten plante. Dies bedeutete, dass die Last während der Spitzenlast erst nach der Sättigung der betreffenden CPUs migriert wurde. Um dies zu beheben, stellen wir die CPU-Affinität unserer Webserverprozesse so ein, dass CPUs ausgeschlossen werden, die für die Verarbeitung des eingehenden Netzwerkverkehrs vorgesehen sind.

Die obigen Diagramme zeigen die Auswirkungen der globalen Optimierung der CPU-Planung im CDN vom 21. Bis 22. März. Wir bewerten die Auswirkungen auf der Grundlage des 95. Perzentils und der Medianwerte einer Performance Health Check-Metrik, einer zusammengesetzten Metrik, die die relative Antwortzeit eines Servers darstellt. Erwartungsgemäß wurden die verkehrsarmen Täler nicht wesentlich reduziert, die Gipfel zeigen jedoch deutlich reduzierte Konflikte zwischen ein- und Ausgangsverkehr. Dies führt zu einer erheblichen Verbesserung sowohl der Ausreißer als auch der Mediane, insbesondere bei Spitzenlasten. Wir können jetzt besser mit Überflüssen im Datenverkehr umgehen und Probleme im Zusammenhang mit hohem Ausreißerverhalten beheben, wie z. B. Repuffern in Videostreams oder die Gesamtreaktionsgeschwindigkeit eines Servers für alle Benutzer.

Kernel-Performance-Updates

Die Optimierung der oberen Schichten unseres Technikpakets ist ebenso wichtig wie die Optimierung der unteren Layer-Elemente. Im Zuge der kürzlich erfolgten Aktualisierung unseres Betriebssystems haben wir auch unsere Linux-Kernel aktualisiert, um die vorgelagerten Entwicklungsarbeiten der Linux-Kernel-Community zu nutzen. Der neue Kernel wurde über die vorherige Version hinaus rund vier Jahre entwickelt, einschließlich Verbesserungen am Speicherverwaltungssystem, das blockierende Seitenzuweisungen reduziert und die Lastverteilung und -Leistung bei der Verwendung der epoll-API und Socket-Sharding verbessert.

In der Grafik oben sehen Sie die Auswirkungen des Upgradeprozesses von Ende November bis Anfang Januar als Rückgang der Integritätsprüfungen für die 99. Perzentile-Performance. Die zugrunde liegenden Kernel-Verbesserungen führten zu einer gleichmäßigeren Lastverteilung über alle unsere Webserver-Anforderungsprozessoren. Dies führte zu einem deutlichen Rückgang dieser Ausreißer, wodurch Anfragen an alle unsere Kunden zuverlässiger wurden.

Leistungsabstimmungen haben einen erheblichen Einfluss

In den letzten zwei Jahren haben die weitreichenden Systemtunings, die von Performance und Kernel Engineering implementiert wurden, praktisch alle Paketverluste (über 98 % entfernt) beseitigt und unsere Performance Health Checks auf unseren Edge-Servern halbiert. Unsere Serverkapazität hat sich um 10–40 % erhöht (die genaue Menge variiert je nach Kundenprofil und Ereignis), sodass wir mehr Datenverkehr schneller bereitstellen können. Das Verhalten bei Ausreißern hat sich deutlich verbessert, was zu einer konsistenteren Erfahrung geführt hat, und wir haben gute Verbesserungen bei den Medianen, insbesondere bei Spitzenbelastungen, festgestellt. Zusammenfassend lässt sich sagen, dass wir dank der Leistungsabstimmung für den gesamten technischen Stack unerwartete Datenverkehrsspitzen besser bewältigen konnten (sei es durch ein mit Spannung erwartetes Update der Spielekonsole oder ein beliebtes Live-Streaming-Video) und allen unseren Benutzern eine konsistentere Leistung bieten konnten.