
Die CPU-Last, die wir in den Griff bekommen haben, klingt wie der Beginn eines technischen Horrorfilms, in dem der Antagonist, anstatt Vorstadtfamilien als Opfer zu wählen, auf die Datenbank zielt. Es gab keinen Hinweis darauf, aber sofort lief die wichtigste Anwendung, die die Verkäufe unseres Kunden unterstützte, so langsam, dass es unmöglich wurde, sich einzuloggen. 28 TB an Datenbank waren nicht mehr verfügbar, und das gesamte Produktionslager erstarrte wie eine GTX 480, auf der gerade jemand versucht hatte, The Witcher 3 auszuführen.
Eine ähnliche Geschichte hätte in jedem Unternehmen passieren können. Gleichzeitig unterstreicht es, wie plötzlich und unerwartet Leistungsprobleme eine Datenbank treffen und wichtige Geschäftsabläufe lähmen können. Dieser Fall ist ein hervorragendes Beispiel dafür, wie wichtig es ist, nicht nur schnell auf Krisen zu reagieren, sondern sie vor allem zu antizipieren und zu verhindern.
*Als seriöser Anbieter von Datenbanklösungen gehen wir jeden Fall stets mit vollem Verantwortungsbewusstsein an. Der Schutz der Daten unserer Kunden hat für uns Priorität. Aus diesem Grund wurden alle sensiblen Informationen anonymisiert, um die Sicherheit unserer Kunden zu gewährleisten und es uns gleichzeitig zu ermöglichen, diesen interessanten Fall einem breiteren Spektrum von Fachleuten vorzustellen.
In dem Moment, in dem wir feststellten, dass die Datenbank unseres Kunden ein so ernstes Problem hatte, dass es ihn daran hinderte, weitere Geschäfte zu tätigen, wurde es für uns zur obersten Priorität, den Status Quo zu verbessern.

100% CPU-Last
Ganz am Anfang haben wir versucht, die Ursache der Ausfallzeiten zu identifizieren. Die vorläufige Diagnose des Problems wurde mit unserem durchgeführt Überwachungsanwendungen ermöglichte es uns zu verstehen, dass im kritischen Moment die CPU-Ressource zu 100% genutzt wurde. Dies ist in der oben abgebildeten Grafik zu sehen, in der der Fehlerbereich gelb markiert ist.
In dem IT-Team, das für die Lösung dieses Problems verantwortlich ist, könnten verschiedene Mitglieder die Situation unterschiedlich sehen:
Es lagen zwei Möglichkeiten auf dem Tisch. In der ersten wurde vorgeschlagen, das Problem durch eine Aufstockung der Ressourcen zu lösen. Bei satten 28 TB an Daten und 32 Hochleistungsprozessoren bedeutete dies einen erheblichen Aufwand. Die zweite, aufschlussreichere, setzte ein Verständnis der Wurzeln des Problems voraus.
Die Wahl fiel auf den zweiten Weg. Es war keine einfache Entscheidung, aber das Team war sich einig, dass nur durch das Verständnis des Kerns des Problems eine dauerhafte Lösung gefunden werden kann. Eine, die nicht nur die aktuelle Krise beheben, sondern das System auch in Zukunft vor ähnlichen Herausforderungen schützen wird. Wie sich später herausstellte, war dies die richtige Entscheidung - eine Erhöhung der CPU-Leistung, die nicht teuer genug war, würde das Problem nicht einmal teilweise lösen.
Wir waren bereits zu dem Schluss gekommen, dass die CPU-Sättigung die Ursache des Problems war, dies war jedoch erst der Anfang des Weges. Der nächste Schritt bestand darin, zu verstehen, was genau für einen so hohen CPU-Verbrauch verantwortlich ist. Die Analyse von CPU-Zeitdiagrammen ermöglichte es, den Kreis der Verdächtigen schnell einzugrenzen.
Die rote Linie steht für die gesamte CPU-Betriebszeit, und die gelbe Füllung gibt die CPU-Betriebszeit an, die von einer einzelnen Abfrage belegt wird:

CPU-Zeit und CPU-Zeitabfrage
Dann identifizierten wir eine bestimmte Abfrage, die plötzlich begann, die CPU extrem intensiv zu belasten.

Eine Abfrage, die die CPU überlastet
Also wurde die Frage gestellt: Ist die Abfrage, die die CPU-Last verursacht hat, eine Neuheit im System, oder war sie früher vorhanden, aber in viel kleinerem Maßstab? Die Antwort lieferte eine Grafik, die die Anzahl der Starts dieser Abfrage im Laufe des Januars 2024 zeigt. Die Daten waren schockierend — am 21. und 22. Januar stieg die Anzahl der Ausführungen dieser Abfrage von täglich 3,5 Millionen auf über 100 Millionen. Ein solch unerwarteter Anstieg war eine offensichtliche Ursache für Leistungseinbußen:

Diagramm, das zeigt, wie oft eine problematische Abfrage ausgeführt wurde
Als wir das Ausmaß des Problems verstanden, gingen unsere Maßnahmen schnell über die Grenzen dieser Datenbank hinaus. Es wurde klar, dass die Lösung nicht in der Optimierung von Abfragen oder in der Erhöhung der Rechenleistung der Server liegen würde. Stattdessen mussten wir uns an das Team wenden, das für die Entwicklung der Anwendung verantwortlich war. Wir mussten verstehen, welche Änderungen zu einem so drastischen Anstieg der Anzahl der Abfrageläufe geführt haben könnten. Die zu stellende Frage bezog sich nicht nur auf die technischen Aspekte der Änderung, sondern auch auf ihre geschäftlichen Gründe. Es war offensichtlich, dass ein solch plötzlicher Anstieg der Aktivitäten nicht auf einen natürlichen Anstieg der Marktnachfrage zurückzuführen sein konnte.
Diese und viele andere Erfahrungen unterstreichen die Bedeutung eines ganzheitlichen Ansatzes für technische Probleme. Vom technischen Aspekt über die Infrastruktur bis hin zu den geschäftlichen Auswirkungen können die unterschiedlichen Sichtweisen im IT-Team zu einem tieferen Verständnis der Situation beitragen.
Wir sind oft versucht, Probleme zu lösen, indem wir in Hardware investieren — Geld für solche Ausgaben wird fast immer gefunden. Es sollte jedoch nicht vergessen werden, dass dies oft eher der Behandlung der Symptome als der Krankheit selbst entspricht und eine Erhöhung der Hardwareressourcen selten die beste Lösung ist.