Untersuchen von Engpässen

In diesem Thema wird ein empfohlenes Verfahren zum Untersuchen von Engpässen beschrieben.

Was ist die Ursache des Problems?

Die Ursache des Problems können Hardware- oder Softwarefehler sein. Wenn Ressourcen ungenügend ausgelastet sind, ist dies in der Regel ein Hinweis auf einen Engpass im System. Engpässe können entweder durch Hardwarebeschränkungen oder durch ineffiziente Softwarekonfigurationen bzw. beides verursacht werden.

Das Ermitteln von Engpässen ist ein inkrementeller Prozess, bei dem die Behebung eines Engpasses zur Entdeckung des nächsten führen kann. Ziel dieses Themas ist die Erläuterung geeigneter Verfahren zum Ermitteln und Verringern dieser Engpässe. Ein System kann für kurze Zeit Spitzenleistungen liefern. Bei einem dauerhaften Durchsatz kann ein System jedoch nur so schnell arbeiten wie seine langsamste Komponente.

Verwenden einer schrittweisen Methode

Engpässe können an den Endpunkten (Einstiegs-/Ausstiegsspunkt) des Systems oder in der Mitte (Orchestrierung/Datenbank) auftreten. Nachdem die Position des Engpasses ermittelt wurde, kann die Ursache mittels einer strukturierten Methode bestimmt werden. Nach dem Beheben der Engpässe muss die Leistung unbedingt erneut gemessen werden, um sicherzustellen, dass an einer nachgelagerten Position im System kein neuer Engpass eingeführt wurde.

Die Ermittlung und Behebung von Engpässen sollte schrittweise erfolgen, es sollte demnach immer nur ein Parameter geändert werden. Anschließend muss die Leistung gemessen werden, um die Wirkung dieser einzelnen Änderung zu überprüfen. Werden mehrere Parameter gleichzeitig geändert, kann die Wirkung der Änderung möglicherweise nicht mehr eindeutig festgestellt werden.

Bei einer Änderung von Parameter 1 wird z. B. möglicherweise die Leistung optimiert. Wird jedoch Parameter 2 zusammen mit Parameter 1 geändert, wirkt sich dies eventuell nachteilig aus, sodass die Vorteile der Änderung von Parameter 1 aufgehoben werden. Damit wird jedoch die Wirkung einer Änderung von Parameter 1 fäschlicherweise negativ und die Wirkung einer Änderung von Parameter 2 fälschlicherweise positiv beurteilt.

Testen der Konsistenz

Nach einer Änderung der Einstellungen müssen unbedingt die Leistungsmerkmale gemessen werden, um die Wirkung der Änderung zu überprüfen.

• Hardware: Es ist wichtig, konsistente Hardware zu verwenden, da die Unterschiedliche Hardware inkonsistentes Verhalten anzeigen kann und irreführende Ergebnisse erzeugt, z. B. keinen Laptop verwenden.

• Dauer des Testlaufs: Es ist auch wichtig, die Leistung für einen festen Mindestzeitraum zu messen, um sicherzustellen, dass die Ergebnisse tatsächlich nachhaltig sind und nicht nur Spitzen. Ein weiterer Grund für längere Testläufe besteht darin, sicherzustellen, dass die anfängliche Startphase des Systems abgeschlossen ist, in der alle Zwischenspeicher gefüllt werden, dass die Datenbanktabellen den erwarteten Umfang erreicht haben und die Einschränkung genügend Zeit erhält, bei Erreichen der vorab definierten Schwellenwerte aktiv zu werden und den Durchsatz zu regulieren. Diese Methode trägt dazu bei, den optimalen dauerhaften Durchsatz zu ermitteln.

• Testparameter: Es ist auch zwingend erforderlich, testparameter nicht von Testlauf zu Testlauf zu variieren. Die Änderung von Zuordnungskomplexität und/oder Dokumentgrößen kann z. B. zu unterschiedlichen Ergebnissen bei Durchsatz und Wartezeit führen.

• Sauberer Zustand: Nach Abschluss eines Tests ist es wichtig, den gesamten Zustand zu bereinigen, bevor der nächste Testlauf ausgeführt wird. In der Datenbank können sich z. B. Verlaufsdaten ansammeln, die den Durchsatz während der Laufzeit beeinträchtigen. Durch das Wiederverwenden der Dienstinstanzen werden zwischengespeicherte Ressourcen wie Arbeitsspeicher, Datenbankverbindungen und Threads freigegeben.

Erwartungen: Durchsatz im Vergleich zu Latenz

Es ist sinnvoll, bei Durchsatz und/oder Latenz des bereitgestellten Systems mit einem bestimmten Wert zu rechnen. Die zwei Ziele hoher Durchsatz & niedrige Wartezeit können jedoch nicht gleichzeitig optimal umgesetzt werden. Es ist jedoch realistisch, bei einer angemessenen Wartezeit einen optimalen Durchsatz zu erwarten. Mit höherem Durchsatz steigt die Belastung des Systems (höherer Bedarf an CPU-Leistung, mehr Datenträger-E/A-Konflikte, hohe Belegung des Systemspeichers, größere Anzahl von Sperrkonflikten), was sich negativ auf die Wartezeit auswirken kann. Zur Ermittlung der optimalen Kapazität eines Systems ist es zwingend erforderlich, jeden Engpass zu ermitteln und zu entschärfen.

Engpässe können durch legacy-Daten (abgeschlossene Instanzen) verursacht werden, die sich in der Datenbank befinden, die nicht bereinigt wurden. In diesem Fall kann die Leistung beeinträchtigt werden. Wenn das System genügend Zeit erhält, solche Daten zu entsorgen, kann das Problem verringert werden. Es ist jedoch wichtig, den Grund für den Aufbau eines Rückstands festzustellen und das Problem zu entschärfen.

Zur Ermittlung des Grunds für den Rückstand müssen Verlaufsdaten analysiert und Leistungsindikatoren überwacht werden (um Verwendungsmuster zu ermitteln und die Quelle des Rückstands zu diagnostizieren). Häufig müssen dafür große Datenmengen in Batches vorzugsweise nachts verarbeitet werden. Die Ermittlung der Kapazität des Systems und seiner Fähigkeit, einen Rückstand abzuarbeiten, kann dazu beitragen, die Hardwareanforderungen für Überlastungsszenarios und die Größe des auf einem System einzurichtenden Pufferraums für unvorhergesehene Durchsatzspitzen einzuschätzen.

Die Optimierung des Systems im Hinblick auf optimalen dauerhaften Durchsatz erfordert eine gründliche Kenntnis der bereitgestellten Anwendung, der Stärken und Schwächen des Systems sowie der Verwendungsmuster im jeweiligen Szenario. Nur bei gründlichen Tests einer Topologie, die weitgehend der in der Produktion eingesetzten entspricht, ist es möglich, Engpässe zu ermitteln und den optimalen dauerhaften Durchsatz mit Sicherheit vorherzusagen.

Die weiteren Themen dieses Abschnitts enthalten Anleitungen zur Definition dieser Topologie sowie Hinweise darauf, wie Engpässe entschärft und generell vermieden werden können.

Skalierung

Engpässe können auf verschiedenen Stufen der bereitgestellten Topologie auftreten. Einige Engpässe können durch Erweiterung der Hardware behoben werden. Die Hardware kann entweder durch zentrales Skalieren (mehr CPUs, mehr Arbeitsspeicher oder Cache) oder dezentrales Skalieren (zusätzliche Server) aufgerüstet werden. Die Entscheidung, zentral/dezentral zu skalieren, hängt von der Art des aufgetretenen Engpasses und der konfigurierten Anwendung ab. Im Folgenden soll eine Anleitung gegeben werden, wie Topologien der Hardwarebereitstellung auf Grundlage der ermittelten Engpässe geändert werden können. Eine Anwendung muss von Grund auf erstellt werden, um das Hoch-/Ausskalieren nutzen zu können. Zum Beispiel:

• Wenn die Anwendung serialisiert ist und von einem einzelnen Ausführungsthread abhängt, trägt das zentrale Skalieren eines Servers mit zusätzlichen CPUs und/oder mehr Arbeitsspeicher eventuell nicht zu einer Behebung des Problems bei.

• Das dezentrale Skalieren eines Systems mit zusätzlichen Servern ist unter Umständen dann nicht hilfreich, wenn durch die zusätzlichen Server die Konkurrenz um eine gemeinsame Ressource verschärft wird, die nicht skaliert werden kann. Das dezentrale Skalieren bietet jedoch weitere Vorteile. Werden anstelle eines Servers mit vier Prozessoren zwei Server mit zwei Prozessoren bereitgestellt, steht ein redundanter Server zur Verfügung, der dem doppelten Zweck der Skalierung dient, nämlich der Verarbeitung von zusätzlichem Durchsatz und der Bereitstellung einer hoch verfügbaren Topologie.