Obwohl dies in der Regel nicht erforderlich und nicht empfehlenswert ist, kann der Autonomic Request Flow Manager (ARFM) durch Ändern der Standardeinstellungen in der Konsole optimiert werden.
Der Autonomic Request Flow Manager enthält drei Komponenten: einen Work Profiler, einen Controller und ein Gateway. Für jede Knotengruppe wird die ARFM-Funktion mit einem Work Profiler und einem Controller, die jeweils in einem Node Agent ausgeführt werden, implementiert. Zusätzlich wird eine Reihe von Gateways in den On Demand Routern (ODRs) für HTTP-Datenverkehr und in den Backend-Servern für IIOP- und JMS-Datenverkehr ausgeführt. Die Gateways fangen die eingehenden HTTP- und IIOP-Anforderungen ab und reihen sie in eine Warteschlange ein, während der Controller Steuersignale oder Anweisungen an die Gateways und den Verteilungscontroller übermittelt. Basierend auf der Beobachtung des Systembetriebs schätzt der Work Profiler fortlaufend die Anforderungen bezüglich der Rechenleistung für die verschiedenen Arten von Anforderungen. In Zusammenarbeit sorgen diese Komponenten dafür, dass die Prioritäten für die eingehenden Anforderungen ordnungsgemäß vergeben werden.
Feld | Verwendung für | Tipps für die Einstellung |
Aggregationszeitraum | Jedes ARFM-Gateway verteilt in gewissen Zeitabständen aggregierte Statistiken. Mit diesem
Parameter wird das Verteilungsintervall definiert.
Die von den Gateways gelieferten Statistiken unterstützen Folgendes:
|
Der Aggregationszeitraum muss so eingestellt werden, dass eine ausreichende Anzahl von Leistungsproben erfasst werden kann. Die Gateways erfassen Proben für jede Anforderung. Es sind mehrere Hundert Proben erforderlich, um eine zuverlässige Bemessungsgrundlage für die Statistiken zu schaffen. Beispiel: Die Ausführungsdauer von Anforderungen, die einer Serviceklasse zugeordnet sind, beträgt 250 Millisekunden, und es werden durchschnittlich 10 Anforderungen parallel ausgeführt. (Der Wert für die parallele Ausführung wird von WebSphere Extended Deployment automatisch, basierend auf der Cluster-Größe und den Ressourcen in der Umgebung berechnet. Der Wert für die parallele Ausführung erscheint in der Konsole in den Visualisierungsanzeigen in der Kategorie "Laufzeitoperationen".) Demzufolge verarbeitet die Serviceklasse ungefähr 40 Anforderungen pro Sekunde. Wenn Sie im Feld "Aggregationszeitraum" den Wert 15 Sekunden festlegen, werden in jedem Aggregationszeitraum 600 Proben erfasst. Die Messwerte, die auf einer Grundlage von 600 Proben basieren, sind hilfreich und zuverlässig. Die Wahl eines zu kurzen Aggregationszeitraums führt zu unzuverlässigen Leistungsmesswerten. Die Leistungsmesswerte, die auf einer geringeren Anzahl von Proben basieren, sind ungenauer und weniger zuverlässig. Da der ARFM-Controller beim Erzeugen neuer Statistiken aktiviert wird, werden die Steuereinstellungen bei der Wahl eines zu kurzen Aggregationszeitraums seltener neu berechnet. Deshalb reagiert WebSphere Extended träger auf plötzliche Änderungen bei Intensität und Muster des Datenverkehrs. |
Mindestlänge des Steuerzyklus | Dieser Parameter definiert, wie oft der ARFM-Controller aktiviert wird. Die Controlleraktivierung ist der Prozess, bei dem die Eingaben ausgewertet und diesbezügliche neue Steuereinstellungen erzeugt werden. Der Aktivierungsprozess für den ARFM-Controller wird eingeleitet, wenn neue Statistiken von einem der Gateways empfangen werden und der Zeitraum seit der letzten Aktivierung größer-gleich der Mindestlänge des Steuerzyklus ist oder der Controller noch nie zuvor aktiviert worden ist. | Diese Einstellung bestimmt die Mindestdauer des Steuerzyklus. Wenn Sie beispielsweise nur einen ODR haben und den Aggregationszeitraum auf 30 Sekunden und die Mindestlänge des Steuerzyklus auf 60 Sekunden festlegen, stellen Sie möglicherweise fest, dass eine Aktivierung um 12:00:00.0 und die nächste 90,1 Sekunden später um 12:01:30.1 stattfindet, weil die vorherigen Statistiken um 12:00:59.9 empfangen wurden. Um einen zuverlässigen Steuerzyklus von ungefähr 60 Sekunden zu gewährleisten, müssen Sie eine Mindestdauer von 58 oder 59 Sekunden für den Steuerzyklus festlegen. |
Gleitende Bereichsgrenze | Diese Einstellung definiert durch Verkettung von Gateway-Statistiken, wie sensibel der ARFM-Controller auf die eingehenden Gateway-Statistiken reagiert. Der ARFM-Controller jedes Gateway verwendet einen gleitenden Durchschnittwert, den er aus den jeweils letzten für das Gateway gelieferten Statistiken ermittelt. Die gleitende Bereichsgrenze steuert, wie viele Statistiken kombiniert werden. | Wenn die gleitende Bereichsgrenze sehr klein ist, ist der Controller sensibler und ermöglicht somit eine schnellere Reaktion. Eine kleinere gleitende Bereichsgrenze ist jedoch auch anfälliger für Rauschen und Anomalien. Es wird Folgendes empfohlen: Das Produkt aus gleitender Bereichsgrenze und Aggregationszeitraum sollte in etwa der Länge des Steuerungszyklus entsprechen, der manchmal geringfügig größer ist als die konfigurierte Mindestlänge. |
Maximale Warteschlangenlänge | Mit diesem Parameter wird die maximale Anzahl von Anforderungen für die ARFM-Warteschlangen festgelegt.
ARFM teilt den gesamten eingehenden Datenverkehr in Anforderungsflüsse ein und verwendet für jeden Anforderungsfluss eine
eigene Warteschlange.
Beispiele:
|
Wenn Sie in diesem Feld einen niedrigen Wert angeben, erhöht sich die Wahrscheinlichkeit, dass eine Anforderung bei einem kurzfristig erhöhten Datenverkehrsaufkommen zurückgewiesen wird, wohingegen ein höherer Wert zu einer längeren Verweildauer von Anforderungen in den Warteschlangen führen kann. Anforderungen, die in Warteschlangen verweilen, verbrauchen Speicherressourcen. Die Standardeinstellung ist 1000. Sie können jedoch verschiedene Werte ausprobieren, um die für Ihre Umgebung am besten geeignete Einstellung zu finden. |
Maximale CPU-Auslastung | Der ARFM bietet neben seinen Priorisierungsfunktionen einen Überlastungsschutz. Ein ARFM stellt Anforderungen in seine Gateway-Warteschlangen, um eine Überlastung der Anwendungsserver zu verhindern. In diesem Release wird die Last anhand der CPU-Auslastung in der ersten Schicht von Anwendungsservern ermittelt. Der Parameter "Maximale CPU-Auslastung" teilt dem ARFM mit, wie stark die Server belastet werden können. Bei extremen Auslastungsspitzen kann dieser Grenzwert kurzfristig überschritten werden. |
Mit höheren Werten wird eine bessere Ressourcennutzung, mit niedrigeren Werten einen stabileren Betrieb erreicht. In Produktionsumgebungen ist die Workload Schwankungen unterlegen und variabel. Die Leistungsverwaltungstechniken in WebSphere Extended Deployment reagieren, wenn auch mit Verzögerung, auf Workload-Schwankungen. In dieser Reaktionszeit kann das System außerhalb der konfigurierten Grenzen arbeiten. Dies kann beispielsweise bedeuten, dass eine höhere als die konfigurierte CPU-Auslastung erreicht wird. Beim Betrieb mit einem Anwendungsserver bei 100 % CPU-Auslastung über mehrere Minuten hinweg wurde beobachtet, dass einige interne Kommunikationsmechanismen zum Nachteil vieler Features ausfallen. Diese Einstellung muss der geschätzten Ziel-CPU-Auslastung für die Gesamtausführungszeit in CPU-Zyklen entsprechen, die im Folgenden beschrieben ist. Wenn Sie die eine Einstellung ändern, müssen Sie auch die andere ändern. Der Standardwert für die beiden Einstellungen ist 90 (Prozent). Die Leistungsverwaltung in diesem Release von WebSphere Extended Deployment funktioniert nicht gut, wenn die erste Schicht von Anwendungsservermaschinen zusätzlich zu den WebSphere-Anforderungen, die per HTTP über die ODRs ankommen, noch andere Anforderungen abwickeln. Diese Einstellung wirkt sich auf die Verteilung der Anwendungen aus. Wenn der geschätzte Gesamtbedarf über dem Grenzwert für die maximale CPU-Auslastung liegt, reduziert der Verteilungscontroller den Bedarf aller dynamischer Cluster einheitlich, bevor er die beste Verteilung berechnet. |