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.
- Stellen Sie sicher, dass die Arbeitslast auf die Cluster-Server verteilt wird.
- Beheben Sie alle Probleme in der Konfiguration der Deployment-Manager-Mehrserverumgebung.
- Umgebungs- oder Konfigurationsfehler beheben
Protokolldateien auf WLM-Fehler und CORBA-Nebencodes überprüfen
PMI-Daten analysieren
- Fehler beheben bzw. Kontakt zum IBM Support aufnehmen
Umgebungs- oder Konfigurationsfehler beheben
- 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.
- 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:
- Wählen Sie aus.
- Wählen Sie den Cluster aus der Liste aus.
- Wählen Sie Cluster-Member aus.
- 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.
- Melden Sie sich über die Administrationskonsole am entsprechenden Cluster an, und gehen Sie wie folgt vor:
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]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Protokolldateien auf WLM-Fehler und CORBA-Nebencodes überprüfen
- 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.
Einen LSD (Location Service Daemon), der mehrmals als nicht verwendbar markiert wurde und weiterhin nicht verwendbar ist.
Ö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:
Ö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.
- 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]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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.
- Wählen Sie in der Baumstrukturansicht den Eintrag Datenerfassung aus. Server, für die PMI nicht aktiviert ist, werden abgeblendet angezeigt.
- Klicken Sie für jeden Server, für den Sie Daten erfassen möchten, auf Angeben....
- Jetzt können Sie Request Metrics aktivieren. Setzen Sie in der Anzeige "Einstellungen für Performance Monitoring" die Überwachungsstufe auf Niedrig.
- Klicken Sie auf OK.
- 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
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.
- Server1 = 5
- Server2 = 3
- Server3 = 2
- 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.
- 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
- 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 %
- Server1 = 5
- Server2 = 3
- Server3 = 2
- 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.
- numIncomingRequestsServer1 = 1236
- numIncomingRequestsServer2 = 1225
- numIncomingRequestsServer3 = 1230
- numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 3691
- numincomingStrongAffinityRequests = 445, und alle 445 Anforderungen werden an Server1 abgesetzt.
- numIncomingNonWLMObjectRequests = 0.
- 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
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.
Die Dateien SystemOut.logs und SystemErr.logs für alle Server im Cluster.
Die Serverprotokolldateien für alle Server im Cluster.
Die Datei activity.log.
Die FFDC-Protokolldateien.
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.
Falls Ihr Problem hier nicht aufgeführt ist, wenden Sie sich
an den IBM Support.
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.
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.