Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Thema wird ein empfohlener Prozess zur Untersuchung von Engpässen beschrieben.
Was ist die Quelle des Problems?
Die Ursache des Problems könnte hardware- oder softwarebezogen sein. Wenn Ressourcen nicht genutzt werden, ist dies in der Regel ein Hinweis auf einen Engpass irgendwo im System. Engpässe können entweder aufgrund von Hardwareeinschränkungen oder aufgrund ineffizienter Softwarekonfigurationen oder beides verursacht werden.
Die Identifizierung von Engpässen ist ein schrittweiser Prozess, bei dem die Beseitigung eines Engpasses zur Entdeckung des nächsten führen kann. Die Wissenschaft, diese Engpässe zu identifizieren und zu beheben, ist das Ziel dieses Themas. Es ist möglich, dass ein System für kurze Zeiträume Spitzenleistungen erbringen kann. Für einen nachhaltigen Durchsatz kann ein System jedoch nur so schnell wie seine langsamste Leistungskomponente verarbeiten.
Verwenden eines seriellen Ansatzes
Engpässe können an den Endpunkten (Eintritt/Beendigung) des Systems oder irgendwo in der Mitte (Orchestrierung/Datenbank) auftreten. Nachdem die Lage des Engpasses isoliert wurde, kann ein strukturierter Ansatz unternommen werden, um die Quelle zu identifizieren. Nachdem die Engpässe gemildert wurden, ist es wichtig, die Leistung wieder zu messen, um sicherzustellen, dass an anderer Stelle im System noch kein neuer Engpass eingeführt wurde.
Der Prozess der Ermittlung und Behebung von Engpässen sollte in einer seriellen Weise erfolgen, wobei jeweils nur ein Parameter unterschiedlich sein sollte und dann die Leistung gemessen wird, um die Auswirkungen dieser einzelnen Änderung zu überprüfen. Wenn mehrere Parameter gleichzeitig variieren, kann die Auswirkung der Änderung verborgen werden.
Beispielsweise könnte das Ändern von Parameter 1 die Leistung verbessern. Das Ändern von Parameter 2 in Verbindung mit dem Ändern von Parameter 1 könnte sich negativ auf die Vorteile der Änderung von Parameter 1 auswirken, was zu einem Netto-Null-Effekt führt. Dies führt jedoch zu einem falsch negativen Ergebnis für die Auswirkung unterschiedlicher Parameter 1 und eines falsch positiven Ergebnisses auf die Auswirkung unterschiedlicher Parameter 2.
Konsistenztest
Das Messen der Leistungsmerkmale nach dem Ändern von Einstellungen ist zwingend erforderlich, um die Auswirkung der Änderung zu überprüfen.
Hardware: Es ist wichtig, einheitliche Hardware zu verwenden, da unterschiedliche Hardware inkonistentes Verhalten zeigen kann, was irreführende Ergebnisse erzeugt, z. B. verwenden Sie keinen Laptop.
Testlaufdauer: Es ist auch wichtig, die Leistung für einen festen Mindestzeitraum zu messen, um sicherzustellen, dass die Ergebnisse tatsächlich nachhaltig und nicht einfach nur Spitzen sind. Ein weiterer Grund zum Ausführen von Tests für längere Zeiträume besteht darin, sicherzustellen, dass das System den anfänglichen Warm-/Ramp-Up-Zeitraum durchlaufen hat, in dem alle Caches aufgefüllt werden, Datenbanktabellen die erwartete Anzahl erreicht haben und die Drosselung ausreichend Zeit zum Starten und Regeln des Durchsatzes erhält, sobald vordefinierte Schwellenwerte erreicht wurden. Dieser Ansatz wird dazu beitragen, einen optimalen nachhaltigen Durchsatz zu ermitteln.
Testparameter: Es ist auch zwingend erforderlich, testparameter von Testausführung zu Testlauf nicht zu variieren. Beispielsweise können unterschiedliche Kartenkomplexität und/oder Dokumentgrößen unterschiedliche Durchsatz- und Latenzergebnisse erzeugen.
Sauberer Zustand: Sobald ein Test abgeschlossen ist, ist es wichtig, den gesamten Zustand zu bereinigen, bevor die nächste Testausführung ausgeführt wird. Beispielsweise können sich historische Daten in der Datenbank ansammeln, die sich auf den Laufzeitdurchsatz auswirken. Das Recycling der Dienstinstanzen trägt dazu bei, zwischengespeicherte Ressourcen wie Arbeitsspeicher, Datenbankverbindungen und Threads freizugeben.
Erwartungen: Durchsatz im Vergleich zur Latenz
Es ist sinnvoll, eine bestimmte Menge an Durchsatz und/oder Latenz vom bereitgestellten System zu erwarten. Der Versuch, sowohl hohen Durchsatz als auch niedrige Latenz zu haben, ist wie das Ziehen in zwei verschiedene Richtungen. Es ist jedoch realistisch, einen optimalen Durchsatz mit angemessener Latenz zu erwarten. Durchsatzverbesserungen führen zu erhöhten Belastungen durch erhöhte CPU-Auslastung, höheren Datenträger-I/O-Wettbewerb, Arbeitsspeicherdruck und größeren Sperrwettbewerb auf dem System, was negative Auswirkungen auf die Latenz haben kann. Um eine optimale Kapazität eines Systems zu ermitteln, ist es zwingend erforderlich, alle Engpässe zu identifizieren und zu lindern.
Engpässe können durch veraltete Daten (abgeschlossene Instanzen) verursacht werden, die sich unverändert in der Datenbank befinden. Wenn dies geschieht, kann die Performance beeinträchtigt werden. Das System ausreichend Zeit für den Abfluss zu geben, kann dazu beitragen, das Problem zu lindern. Es ist jedoch wichtig, die Ursache des Backlogaufbaus zu ermitteln und das Problem zu lindern.
Um die Ursache des Backlogs zu ermitteln, ist es wichtig, historische Daten zu analysieren, Leistungsüberwachungsindikatoren zu überwachen (um Nutzungsmuster zu ermitteln und die Quelle des Backlogs zu diagnostizieren). Dies ist eine häufige Situation, in der große Datenmengen in einer Batchverarbeitung auf nachtlicher Basis verarbeitet werden. Das Ermitteln der Kapazität des Systems und die Fähigkeit, sich von einem Backlog zu erholen, kann nützlich sein, um die Hardwareanforderungen für die Behandlung von Überlastungsszenarien und die Menge an Pufferraum zu schätzen, die geeignet ist, um in einem System unvorhergesehene Spitzen im Durchsatz zu bewältigen.
Die Optimierung des Systems für einen optimalen nachhaltigen Durchsatz erfordert ein fundiertes Verständnis der bereitgestellten Anwendung, der Stärken und Schwächen des Systems und der Nutzungsmuster des jeweiligen Szenarios. Die einzige Möglichkeit, Engpässe zu erkennen und einen optimalen nachhaltigen Durchsatz mit Sicherheit vorherzusagen, besteht darin, gründliche Tests auf einer Topologie durchzuführen, die genau mit dem übereinstimmt, was in der Produktion verwendet wird.
Andere Themen in diesem Abschnitt führen Sie durch den Prozess der Definition dieser Topologie und enthalten Anleitungen zur Verringerung von Engpässen und hoffentlich dazu, Engpässe zu vermeiden.
Skalierung
Engpässe können in verschiedenen Phasen der bereitgestellten Topologie auftreten. Einige Engpässe können durch ein Upgrade der Hardware behoben werden. Hardware kann entweder durch vertikale Skalierung (mehr CPUs, Arbeitsspeicher oder Cache) oder durch horizontale Skalierung (zusätzliche Server) aktualisiert werden. Die Entscheidung zum Hochskalieren/Verkleineren hängt von der Art des aufgetretenen Engpasses und der konfiguration der Anwendung ab. Im Folgenden finden Sie Anleitungen zum Ändern von Hardwarebereitstellungstopologien basierend auf aufgetretenen Engpässen. Eine Anwendung muss von Grund auf erstellt werden, um in der Lage zu sein, die Skalierung nach oben/außen zu nutzen. Zum Beispiel:
Die Skalierung eines Servers mit zusätzlichen CPU- und/oder Arbeitsspeicher kann das Problem möglicherweise nicht beheben, wenn die Anwendung serialisiert und von einem einzelnen Ausführungsthread abhängig ist.
Das Skalieren eines Systems mit zusätzlichen Servern kann möglicherweise nicht hilfreich sein, wenn die zusätzlichen Server einfach zusätzlichen Wettbewerb um eine gemeinsame Ressource erzeugen, die nicht skaliert werden kann. Das Skalieren bietet jedoch zusätzliche Vorteile. Die Bereitstellung von zwei Dual-Proc-Servern anstelle eines Quad-Proc-Servers hilft dabei, einen redundanten Server bereitzustellen, der den doppelten Zweck erfüllt, die Skalierung zur Verarbeitung von zusätzlichem Durchsatz zu ermöglichen und eine hochverfügbare Topologie bereitzustellen.