Tipps zur Fehlerbehebung beim Workload-Management

Wenn die WLM-Komponente (Workload-Management, Lastausgleich) die Arbeitslast nicht ordnungsgemäß serverübergreifend (Konfiguration mit mehreren Knoten) verteilt, führen Sie die folgenden Schritte durch, um das Problem zu isolieren.

Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM® i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.

Umgebungs- oder Konfigurationsfehler beheben

Stellen Sie fest, ob die Server die Anwendungen, für die sie aktiviert wurden, bereitstellen können. Identifizieren Sie den Cluster, der das Problem hat.
  • Gibt es Netzprobleme mit den Cluster-Membern oder den Verwaltungsservern, z. B. dem Deployment Manager oder Node Agent?
    • Wenn ja, setzen Sie den Befehl ping an die Maschinen ab, um sicherzustellen, dass sie ordnungsgemäß mit dem Netz verbunden sind.
  • Stellen Sie fest, ob auf den Maschinen, auf denen die Server installiert sind, eine andere Aktivität stattfindet, die die Fähigkeit des Servers, eine Anforderung zu bearbeiten, beeinträchtigt. Prüfen Sie z. B. die Auslastung des Prozessors, wie von Task-Manager, Prozess-ID oder anderem externen Tool gemessen, um zu prüfen, ob eine der folgenden Bedingungen zutrifft:
    • Die Auslastung entspricht nicht den Erwartungen und ist unregelmäßig.
    • Die Auslastung zeigt an, dass ein neu hinzugefügtes, installiertes oder aktualisiertes Member des Cluster nicht verwendet wird.
  • Sind alle Anwendungsserver, die Sie auf den Knoten gestartet haben, aktiv, oder sind einige Anwendungsserver gestoppt?
  • Sind die Anwendungen installiert und betriebsbereit?
  • Wenn sich das Problem auf die Verteilung der Arbeitslast auf CMP- (Container-Managed Persistence, über Container realisierte Transaktionspersistenz) oder BMP-Enterprise-Beans (Bean-Managed Persistence, über JavaBeans realisierte Transaktionspersistenz) bezieht, haben Sie die unterstützenden JDBC-Provider und JDBC-Datenquellen auf jedem Server konfiguriert?

Wollten beim Lastausgleich Probleme mit HTTP-Anforderungen auftreten, beispielsweise dass HTTP-Anforderungen von keinem der Cluster-Member bedient werden, sollten Sie daran denken, dass das HTTP-Plug-in die Arbeitslast auf alle Server verteilt, die in der PrimaryServers-Liste definiert sind, falls keine Affinität konfiguriert ist. Wurde keine Liste der Primärserver definiert, verteilt das Plug-in die vorhandene Last auf alle im Cluster definierten Server, wenn keine Affinität festgelegt wurde. Falls eine Affinität konfiguriert ist, muss das Plug-in für alle Anforderungen sofort den angegebenen Server kontaktieren.

Treten beim Lastausgleich Probleme auf, die sich auf Enterprise-Bean-Anforderungen beziehen, wie z. B. Enterprise-Bean-Anforderungen, die nicht von allen Membern eines Cluster bearbeitet werden, prüfen Sie Folgendes:
  • Wurden für die Wertigkeit zulässige Werte angegeben?
    • Melden Sie sich über die Administrationskonsole am entsprechenden Cluster an, und gehen Sie wie folgt vor:
      1. Wählen Sie Server > Cluster > WebSphere-Anwendungsserver-Cluster aus.
      2. Wählen Sie den Cluster aus der Liste aus.
      3. Wählen Sie Cluster-Member aus.
      4. Klicken Sie für jeden Server im Cluster auf Servername und notieren Sie die Wertigkeit des Servers.
    • Vergewissern Sie sich, dass die Wertigkeiten im gültigen Bereich von 0 bis 20 liegen. Wenn ein Server die Wertigkeit 0 hat, werden keine Anforderungen an diesen Server weitergeleitet. Wertigkeiten größer als 20 werden wie Wertigkeit 0 behandelt.

Der restliche Abschnitt befasst sich ausschließlich mit dem Lastausgleich bei Enterprise-Beans. Weitere Hilfe zum Diagnostizieren von Problemen bei der Verteilung von Webanforderungen (HTTP) finden Sie in den Artikeln "Tipps zur Fehlerbehebung beim Web-Server-Plug-in" und "Webressource wird nicht angezeigt".

[IBM i][AIX Solaris HP-UX Linux Windows]

Protokolldateien auf WLM-Fehler und CORBA-Nebencodes überprüfen

Sollten bei dem Lastausgleich immer noch Probleme mit Enterprise-Beans auftreten, sollten Sie als nächstes das Aktivitätenprotokoll auf Einträge mit folgenden Informationen untersuchen:
  • Server, der mehrmals als nicht verwendbar markiert wurde und weiterhin nicht verwendbar ist.
  • Alle Server in einem Cluster, die als ungültig markiert wurden und weiterhin nicht verwendbar sind.
  • [z/OS]Einen LSD (Location Service Daemon), der mehrmals als nicht verwendbar markiert wurde und weiterhin nicht verwendbar ist.

[IBM i][AIX Solaris HP-UX Linux Windows]Öffnen Sie hierfür mit der Protokoll- und Traceanalysefunktion das Serviceprotokoll (activity.log) auf den betroffenen Servern und suchen Sie nach den folgenden Einträgen:

[z/OS]Öffnen Sie dazu das Serviceprotokoll der betroffenen Server und suchen Sie nach den folgenden Einträgen:

  • WWLM0061W: Beim Senden einer Anforderung an Cluster-Member Member ist ein Fehler aufgetreten, und das Member wurde für weitere Anforderungen an den Cluster Cluster als nicht verwendbar markiert.
    Anmerkung: Es ist nicht außergewöhnlich, dass ein Server als nicht verwendbar markiert wird. Die Markierung wird möglicherweise durchgeführt, weil dies im normalen Betrieb erforderlich ist, z. B., wenn ein Schnellstart ausgeführt wird, obwohl ein Client noch immer Anforderungen an den Server sendet. Außerdem ist es normal, dass viele Warnungen des Typs WWLM0061W für ein Member gleichzeitig abgesetzt werden. Normalerweise werden in vielen Threads Anforderungen bearbeitet. Wenn ein Member als nicht verfügbar markiert ist, ist es wahrscheinlich, dass die Threads, die sich auf dieses Member beziehen, diese Warnung erhalten.
  • WWLM0062W: Beim Senden einer Anforderung an Cluster-Member Member ist ein Fehler aufgetreten, und das Member wurde mindestens zwei Mal für weitere Anforderungen an den Cluster Cluster als nicht verwendbar markiert.
  • WWLM0063W: Beim Versuch, den Location Service Daemon LSD-Name für die Auflösung einer Objektreferenz für Cluster Cluster zu verwenden, ist ein Fehler aufgetreten, und der LSD wurde für weitere Anforderungen an den Cluster als nicht verwendbar markiert.
  • WWLM0064W: Beim Versuch, eine Anforderung an alle Member im Cluster Cluster zu senden, sind Fehler aufgetreten, und alle Member wurden für weitere Anforderungen an diesen Cluster als nicht verwendbar markiert.
  • WWLM0065W: Beim Versuch, das Cluster-Member Server in Cluster Cluster zu aktualisieren, ist ein Fehler aufgetreten. Das Member konnte vom Deployment Manager nicht erreicht werden.
  • WWLM0067W: Dem Client wurde eine Anforderungswiederholung angekündigt. Offensichtlich konnte WLM eine Serveranforderung nicht transparent wiederholen, weil die Ausnahme {0} eingetreten ist.

    Bei dem Versuch, eine Anforderung zu bearbeiten, hat WLM eine Bedingung festgestellt, die eine transparente erneute Übergabe der Anforderung nicht zulässt. Die ursprüngliche Ausnahme wird abgefangen, und eine neue Ausnahme des Typs CORBA.TRANSIENT mit dem Nebencode 0x49421042 (SERVER_SIGNAL_RETRY) wird für an den Client abgesetzt.

Wenn eine dieser Warnungen angezeigt wird, führen Sie die im Protokoll angegebene Benutzeraktion aus. Werden die Warnungen nach Ausführung der Benutzeraktion weiterhin angezeigt, prüfen Sie alle anderen Fehler und Warnungen, die in der Protokoll- und Traceanalysefunktion auf den betroffenen Servern angezeigt werden:
  • Eine mögliche Benutzeraktion, wie z. B. das Ändern einer Konfigurationseinstellung.
  • Ausnahmen für Basisklassen, die möglicherweise einen Fehler im Produkt anzeigen.

Möglicherweise werden auch Ausnahmen angezeigt, in denen "CORBA" angegeben ist, da WLM für die Kommunikation zwischen den Prozessen CORBA (Common Object Request Broker Architecture) verwendet. Suchen Sie im Ausnahmebedingungsstack nach einer Anweisung, die einen Nebencode angibt. Diese Codes bezeichnen den spezifischen Grund, aus dem ein CORBA-Aufruf oder eine CORBA-Antwort nicht ausgeführt werden konnte. WLM-Nebencodes liegen im Bereich von 0x4921040 bis 0x492104F. Eine Erläuterung der Nebencodes, die sich auf WLM beziehen, finden Sie im Artikel "Referenz: Generierte API-Dokumentation" für das Paket und die Klasse "com.ibm.websphere.wlm.WsCorbaMinorCodes".

[IBM i][AIX Solaris HP-UX Linux Windows]

PMI-Daten analysieren

Die Analyse der PMI-Daten gibt Aufschluss über die Arbeitslast, die die einzelnen Cluster-Member bewältigen müssen. Die Daten eines Cluster-Member haben nur im Kontext der Daten aller Cluster-Member Aussagekraft.

Verwenden Sie Tivoli Performance Viewer, um, basierend auf den Wertigkeiten, die den Cluster-Membern zugeordnet sind (stabile Wertigkeiten), zu prüfen, ob jeder Server den richtigen Anteil der Anforderungen erhält.

Führen Sie in der Navigation des Produks Tivoli Performance Viewer die folgenden Aktionen aus, wenn Sie Tivoli Performance Viewer für die Erfassung von PMI-Metriken verwenden möchten:
  1. Wählen Sie in der Baumstrukturansicht den Eintrag Datenerfassung aus. Server, für die PMI nicht aktiviert ist, werden abgeblendet angezeigt.
  2. Klicken Sie für jeden Server, für den Sie Daten erfassen möchten, auf Angeben....
  3. Jetzt können Sie Request Metrics aktivieren. Setzen Sie in der Anzeige "Einstellungen für Performance Monitoring" die Überwachungsstufe auf Niedrig.
  4. Klicken Sie auf OK.
  5. Sie müssen auf Anwenden klicken, damit die vorgenommenen Änderungen gespeichert werden.

Die WLM PMI Metrics können auf Serverbasis angezeigt werden. Wählen Sie in Tivoli Performance Viewer Node > Server > WorkloadManagement > Server/Client aus. Standardmäßig werden die in einem Intervall von 10 Sekunden erfassten Daten unformatiert und summiert in einer Tabelle angezeigt. Sie können die Daten auch als Delta oder Prozentsatz anzeigen, Spalten hinzufügen und entfernen, den Puffer löschen, die Metrics auf null zurücksetzen und das Erfassungsintervall und die Puffergröße ändern.

Wenn Sie die PMI-Daten abgerufen haben, müssen Sie den Anteil des numIncomingRequests-Wertes der einzelnen Cluster-Member am numIncomingRequests-Wert aller Cluster-Member ermitteln. Ein Vergleich dieses Prozentsatzes mit dem Prozentsatz der Wertigkeiten, die direkt an jedes einzelne Cluster-Member geleitet werden, vermittelt einen ersten Eindruck der Arbeitslast, die auf die einzelnen Member eines Cluster entfällt.

Zusätzlich zu numIncomingRequests zeigen zwei weitere Metriken, wie die Last zwischen den Membern eines Cluster verteilt ist, numincomingStrongAffinityRequests und numIncomingNonWLMObjectRequests. Diese zwei Metriken geben die Anzahl der an ein spezifisches Member geleiteten Anforderungen an, die nur von diesem Member bearbeitet wurden.

Nehmen Sie an, Sie arbeiten mit einem aus drei Servern bestehenden Cluster. Den drei Servern sind die folgenden Wertigkeiten zugeordnet:
  • Server1 = 5
  • Server2 = 3
  • Server3 = 2
Erteilen Sie dem Server-Cluster die Berechtigung, Serviceanforderungen abzusetzen, und warten Sie, bis das System einen stabilen Status erreicht hat, d. h., bis die Anzahl der im Cluster eingehenden Anforderungen der Anzahl der Serverantworten entspricht. In diesem Fall ist zu erwarten, dass die prozentualen Anteile der an die einzelnen Server weitergeleiteten Anforderungen sich wie folgt darstellen:
  • in % weitergeleitet an Server1 = Wertigkeit1 / (Wertigkeit1+Wertigkeit2+Wertigkeit3) = 5/10 oder 50 %
  • in % weitergeleitet an Server2 = Wertigkeit2 / (Wertigkeit1+Wertigkeit2+Wertigkeit3) = 3/10 oder 30 %
  • in % weitergeleitet an Server3 = Wertigkeit3 / (Wertigkeit1+Wertigkeit2+Wertigkeit3) = 2/10 oder 20 %

Stellen Sie sich eine Situation vor, in der keine eingehenden Anforderungen mit starker Affinität bzw. mit von WLM verwalteten Objektanforderungen vorhanden sind.

Nehmen Sie für dieses Szenario an, dass die aufgezeichneten PMI-Daten die Anzahl der auf jedem Server eingehenden Anforderungen wie folgt anzeigen:
  • numIncomingRequestsServer1 = 390
  • numIncomingRequestsServer2 = 237
  • numIncomingRequestsServer3 = 157

Daher setzt sich die Gesamtanzahl der im Cluster eingehenden Anforderungen wie folgt zusammen: numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 784

numincomingStrongAffinityRequests = 0

numIncomingNonWLMObjectRequests = 0

Können auf der Grundlage dieser Daten Entscheidungen getroffen werden, wenn WLM die eingehenden Anforderungen richtig auf die Server im Cluster verteilt? Da keine Anforderungen mit starker Affinität vorhanden sind, muss die Frage beantwortet werden, ob die Anforderungen im erwarteten Verhältnis auf den zugeordneten Wertigkeiten basieren. Die Berechnung, die zur Beantwortung dieser Frage durchgeführt werden muss, lautet wie folgt:
  • in % (tatsächlich) weitergeleitet an Server1 = 390 / 784 = 49,8 %
  • in % (tatsächlich) weitergeleitet an Server2 = 237 / 784 = 30,2 %
  • in % (tatsächlich) weitergeleitet an Server3 = 157 / 784 = 20,0 %
WLM funktioniert wie vorgesehen, da die Daten, die auf den den Servern zugeordneten Wertigkeiten basieren, vollständig den Erwartungen entsprechen.
Nehmen Sie an, Sie arbeiten mit einem aus drei Servern bestehenden Cluster. Nehmen Sie weiter an, diesen drei Servern wurden folgende Wertigkeiten zugeordnet:
  • Server1 = 5
  • Server2 = 3
  • Server3 = 2
Erteilen Sie dem Server-Cluster die Berechtigung, Serviceanforderungen abzusetzen, und warten Sie, bis das System einen stabilen Status erreicht hat, d. h., bis die Anzahl der im Cluster eingehenden Anforderungen der Anzahl der Serverantworten entspricht. In diesem Fall ist zu erwarten, dass die prozentualen Anteile der an die einzelnen Server weitergeleiteten Anforderungen sich wie folgt darstellen:
  • in % weitergeleitet an Server1 = Wertigkeit1 / (Wertigkeit1+Wertigkeit2+Wertigkeit3) = 5/15 oder 1/3 der Anforderungen.
  • in % weitergeleitet an Server2 = Wertigkeitt2 / (Wertigkeit1+Wertigkeit2+Wertigkeit3) = 5/15 oder 1/3 der Anforderungen.
  • % weitergeleitet an Server3 = Wertigkeit3 / (Wertigkeit1+Wertigkeit2+Wertigkeit3) = 5/15 oder 1/3 der Anforderungen.
Nehmen Sie für dieses Szenario an, dass die aufgezeichneten PMI-Daten die Anzahl der auf jedem Server eingehenden Anforderungen wie folgt anzeigen:
  • numIncomingRequestsServer1 = 1236
  • numIncomingRequestsServer2 = 1225
  • numIncomingRequestsServer3 = 1230
Daher setzt sich die Gesamtanzahl der im Cluster eingehenden Anforderungen wie folgt zusammen:
  • numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 3691
  • numincomingStrongAffinityRequests = 445, und alle 445 Anforderungen werden an Server1 abgesetzt.
  • numIncomingNonWLMObjectRequests = 0.
In diesem Fall ist erkennbar, dass die Anzahl der Anforderungen, wie erwartet, nicht zu gleichen Teilen auf die drei Server aufgeteilt wurde. Die Aufteilung wurde wie folgt durchgeführt:
  • in % (tatsächlich) weitergeleitet an Server1 = 1236 / 3691= 33,49 %
  • in % (tatsächlich) weitergeleitet an Server2 = 1225 / 3691= 33,19 %
  • in % (tatsächlich) weitergeleitet an Server3 = 1230 / 3691= 33,32 %

Die richtige Interpretation dieser Daten ist, dass die Weiterleitung der Anforderungen nicht optimal verteilt ist, da auf Server1 mehrere Hundert Anforderungen mit starker Affinität eingegangen sind. WLM versucht, Anforderungen mit starker Affinität, die an einen oder mehrere Server weitergeleitet werden, dadurch auszugleichen, dass sie neue eingehende Anforderungen vorzugsweise auf Server verteilt, die nicht an der Transaktionsaffinität beteiligt sind. Im Falle der eingehenden Anforderungen mit starker Affinität bzw. nicht von WLM verwalteten Objektanforderungen wird die Analyse analog zu diesem Fall durchgeführt.

Wenn Sie die PMI-Daten analysiert und für die Transaktionsaffinität und die nicht von WLM verwalteten Objektanforderungen berücksichtigt haben und der Prozentsatz der tatsächlich auf Servern eingehenden Anforderungen nicht die zugeordneten Wertigkeiten wiedergibt, ist das ein Hinweis darauf, dass die Anforderungen nicht gleichmäßig verteilt werden. Ist dies der Fall, wird empfohlen, die Schritte zur Behebung der umgebungs- und konfigurationsbedingten Fehler und zur Prüfung der Protokolldateien zu wiederholen, bevor Sie mit der Verarbeitung fortfahren.

Fehler beheben bzw. Kontakt zum IBM Support aufnehmen

[IBM i][AIX Solaris HP-UX Linux Windows]Falls die PMI-Daten oder Clientprotokolle auf einen Fehler in WLM hinweisen, tragen Sie die folgenden Informationen zusammen, und wenden Sie sich dann an den IBM Support.

Falls die Clientprotokolle auf einen Fehler in WLM hinweisen, tragen Sie die folgenden Informationen zusammen, und wenden Sie sich dann an den IBM Support.

  • Eine ausführliche Beschreibung Ihrer Umgebung.
  • Eine Beschreibung der Symptome.
  • [IBM i][AIX Solaris HP-UX Linux Windows]Die Dateien SystemOut.logs und SystemErr.logs für alle Server im Cluster.
  • [z/OS]Die Serverprotokolldateien für alle Server im Cluster.
  • [IBM i][AIX Solaris HP-UX Linux Windows]Die Datei activity.log.
  • [IBM i][AIX Solaris HP-UX Linux Windows]Die FFDC-Protokolldateien.
  • [IBM i][AIX Solaris HP-UX Linux Windows]Die PMI-Metriken.
  • Eine Beschreibung des Clients und der Operationen, die er auszuführen versucht. Beispiel: 1 Thread, mehrere Threads, Servlet, J2EE-Client etc.

Wenn Sie den Fehler mit keinem dieser Schritte beheben können, prüfen Sie, ob der Fehler bekannt ist und dokumentiert wurde. Verwenden Sie dazu die Links im Artikel "Fehlerdiagnose und -behebung: Lernmaterial". Wenn der angezeigte Fehler nicht in ähnlicher Form dokumentiert ist oder wenn Sie den Fehler anhand der bereitgestellten Informationen nicht beheben können, wenden Sie sich an den IBM Support.

[AIX Solaris HP-UX Linux Windows][z/OS]Falls Ihr Problem hier nicht aufgeführt ist, wenden Sie sich an den IBM Support.

[AIX Solaris HP-UX Linux Windows]Aktuelle Informationen des IBM Support zu bekannten Problemen und deren Behebung finden Sie auf der IBM Unterstützungsseite. Sie sollten diese Seite auch besuchen, bevor Sie einen PMR öffnen, da sie Dokumente enthält, mit denen Sie Zeit beim Erfassen der für die Fehlerbehebung erforderlichen Informationen einsparen können.

[IBM i]Aktuelle Informationen des IBM Support zu bekannten Problemen und deren Behebung finden Sie auf der Webseite zur Software für IBM i. Besuchen Sie diese Seite auch, bevor Sie einen PMR öffnen. Diese Seite enthält Informationen zu den Dokumenten, die Sie zusammenstellen und an IBM senden müssen, um Hilfe zu einem Problem zu erhalten.


Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_wlmcomp
Dateiname:rtrb_wlmcomp.html