Arbeitslast wird nicht verteilt

Diese Informationen können Ihnen bei der Behebung eines Lastverteilungsproblems helfen.

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.
Sollten Sie den Fehler anhand der Fehlerbehebungsbeschreibungen nicht beheben können, gehen Sie wie folgt vor:
  1. [AIX Solaris HP-UX Linux Windows][IBM i]Durchsuchen Sie die JVM-Protokolle der betroffenen Deployment Manager und Anwendungsserver.
    1. Suchen Sie alle Fehlernachrichten. Wählen Sie hierfür im Information Center die Ansicht Referenz aus und erweitern Sie in der Navigationsstruktur den Eintrag Nachrichten.
    2. [AIX Solaris HP-UX Linux Windows][IBM i]Verwenden Sie das Tool "Protokoll- und Traceanalyse", um das Serviceprotokoll (activity.log) des Deployment Manager und aller Knoten, bei denen Probleme auftreten, anzuzeigen und zu analysieren. Zeigen Sie die Dateien activity.log aus den Verzeichnissen Stammverzeichnis_des_Anwendungsservers/logs und Stammverzeichnis_des_Anwendungsservers/logs an.
    3. [IBM i]Analysieren Sie das Serviceprotokoll (activity.log) des Deployment Manager und aller Knoten, auf denen Probleme auftreten. Zeigen Sie die Datei activity.log aus dem Verzeichnis Profilstammverzeichnis/logs an.
    4. Wenn Java™-Ausnahmen in den Protokolldateien erscheinen, versuchen Sie, die tatsächliche, direkt vom Problem betroffene Subkomponente zu ermitteln. Überprüfen Sie den Trace-Stack auf eine Klasse, die sich auf das Produkt bezieht (Namen, die mit "com.ibm.websphere" oder "com.ibm.ws" beginnen) und die Ausnahme ausgelöst hat. Prüfen Sie die Schritte zur Fehlerbehebung für die entsprechenden Unterkomponente im Abschnitt Fehlerbehebung bei WebSphere-Anwendungen des Information Center.

      Wenn die Ausnahme scheinbar von einer Klasse im Paket com.ibm.websphere.naming ausgelöst wurde, lesen Sie den Artikel "Tipps zur Fehlerbehebung bei Namensservices".

  2. [z/OS]Durchsuchen Sie die JVM-Protokolle der betroffenen Deployment Manager und Anwendungsserver.
    1. Suchen Sie alle Fehlernachrichten. Wählen Sie hierfür im Information Center die Ansicht Referenz aus und erweitern Sie in der Navigationsstruktur den Eintrag Nachrichten.
    2. Wenn Java-Ausnahmen in den Protokolldateien erscheinen, versuchen Sie, die tatsächliche, direkt vom Problem betroffene Unterkomponente zu ermitteln. Überprüfen Sie den Trace-Stack auf eine Klasse, die sich auf das Produkt bezieht (Namen, die mit com.ibm.websphere oder com.ibm.ws beginnen) und die Ausnahme ausgelöst hat. Prüfen Sie die Schritte zur Fehlerbehebung für die entsprechenden Unterkomponente im Abschnitt Fehlerbehebung bei WebSphere-Anwendungen des Information Centers.

      Wenn die Ausnahme scheinbar von einer Klasse im Paket com.ibm.websphere.naming ausgelöst wurde, lesen Sie den Artikel "Tipps zur Fehlerbehebung bei Namensservices".

  3. Setzen Sie den Befehl ping an alle Maschinen in Ihrer Konfiguration ab, dass die TCP/IP-Konnektivität gewährleistet ist:
    1. Von jedem physischen Server an den Deployment Manager
    2. Vom Deployment Manager an jeden physischen Server
  4. Obwohl das Problem in einer Clusterumgebung auftritt, hängt das eigentliche Problem möglicherweise nur indirekt mit dem Clustering zusammen. Prüfen Sie alle relevanten Möglichkeiten:
    1. Wenn eine Enterprise-Bean in einem odere mehreren Servern keine Anforderungen bearbeitet, lesen Sie die Artikel Zugriff auf eine Enterprise-Bean über ein Servlet, eine JSP, ein eigenständiges Programm oder einen anderen Client nicht möglich und Objekt im Produkt wurde vom Servlet, der JSP-Datei oder einem anderen Client nicht gefunden.
    2. Wenn nach dem Aktivieren der Sicherheit Probleme aufzutreten scheinen, lesen Sie den Artikel "Fehler oder Zugriffsprobleme nach dem Aktivieren der Sicherheit".
    3. Falls ein Anwendungsserver plötzlich nicht mehr auf Anforderungen reagiert oder abstürzt (der Anwendungsserverprozess wird geschlossen), lesen Sie den Abschnitt "Webmodul oder Anwendungsserver stürzt ab oder blockiert".
    4. Wenn von einigen oder allen Servern keine SOAP-Anforderungen bearbeitet werden, lesen Sie den Artikel "Rückgabe von Fehlern an Clients, die versuchen, eine SOAP-Anforderung zu senden".
    5. [AIX Solaris HP-UX Linux Windows][IBM i]Wenn beim Installieren oder Implementieren einer Anwendung in Servern auf einem oder mehreren Knoten Probleme auftreten, lesen Sie den Artikel "Probleme bei der Codeimplementierung und -installation beheben".
  5. [AIX Solaris HP-UX Linux Windows][IBM i]Wenn sich Ihre Topologie aus einem Windows-basierten Deployment Manager mit UNIX-basierten Servern zusammensetzt, können Sie die zuvor aktualisierten Dateien mit den Erweiterungen .xml und .policy auf der UNIX-basierten Plattform mit vi anzeigen, um sicherzustellen, dass keine Zeilenumbruchzeichen (Strg-M) in den Dateien enthalten sind. Um dieses Problem in Zukunft zu umgehen, editieren Sie diese Dateien auf der UNIX-Plattform mit vi, damit diese Zeichen nicht eingefügt werden.
  6. [AIX Solaris HP-UX Linux Windows][IBM i]Prüfen Sie, ob Tipps zur Fehlerbehebung beim Workload-Management gegeben werden.
  7. Prüfen Sie, ob der Fehler bekannt ist und dokumentiert wurde. Lesen Sie dazu die entsprechenden Informationen in der verfügbaren Onlineunterstützung (Hinweise und Tipps, technische Anmerkungen und Fixes).

HTTP-Anforderungen werden nicht an alle Server verteilt

Wenn HTTP-Anforderungen nicht an alle Server verteilt werden, gehen Sie wie folgt vor:
  • Prüfen Sie die Liste der primären Server. Das Plug-in verteilt die Last auf alle Server, die in der Liste der Primärserver definiert sind, wenn keine Affinität festgelegt wurde. 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. Im Falle, dass Affinität festgelegt wurde, muss das Plug-in bei allen Anforderungen innerhalb einer HTTP-Sitzung eine direkte Verbindung zu diesem Server herstellen.
  • Wenn einige Server Anforderungen bearbeiten, andere jedoch nicht, versuchen Sie, direkt auf einen fehlerhaften Server zuzugreifen, um sicherzustellen, dass er betriebsbereit ist. Lassen Sie dabei Fragen der Auslastungsverwaltung außer Acht. Wenn das nicht funktioniert, gehen Sie wie folgt vor:
    • Prüfen Sie in der Administrationskonsole, ob der entsprechende Server aktiv ist.
    • Weitere Informationen finden Sie im Artikel "Webressource wird nicht angezeigt".
  • Weitere Informationen finden Sie im Artikel "Tipps zur Fehlerbehebung bei HTTP-Plug-in-Komponenten".
  • [AIX Solaris HP-UX Linux Windows][IBM i]Überprüfen Sie die Schritte zum Diagnostizieren von Workload-Management-Problemen im Artikel "Fehlerbehebung bei der Workload-Management-Komponente".

EJB-Anforderungen werden nicht an alle Server verteilt

Wenn ein Client zu einem Server in einem Cluster keine Verbindung herstellen kann, obwohl dies der Fall sein sollte, wurde der Server möglicherweise als nicht verwendbar markiert oder heruntergefahren. Wenn Sie sich vergewissern möchten, dass dies die Ursache des Problems ist, gehen Sie wie folgt vor:
  • Prüfen Sie in der Administrationskonsole, ob der entsprechende Server gestartet wurde. Versuchen Sie, den Server zu starten, bzw. erneut zu starten.
  • Durchsuchen Sie die Administrationskonsole, und prüfen Sie, dass der Knoten, auf dem der Server ausgeführt wird, angezeigt wird. Ist das nicht der Fall, gehen Sie wie folgt vor:
    • Prüfen Sie, welche Schritte durchgeführt werden müssen, um einen Knoten einem Cluster hinzuzufügen.
    • Prüfen Sie anhand des Abschnitts Ein oder mehrere Knoten werden in der Administrationskonsole nicht angezeigt, welche Schritte auszuführen sind.
  • Versuchen Sie, wenn möglich, direkt auf die Enterprise-Beans auf dem fehlerhaften Server zuzugreifen, um zu prüfen, ob ein Problem mit der TCP/IP-Konnektivität, dem Status des Anwendungsservers bzw. ein anderes, nicht mit der Auslastungsverwaltung in Zusammenhang stehendes Problem vorliegt. Wenn dieser Versuch scheitert, lesen Sie den Artikel "Zugriff auf eine Enterprise-Bean über ein Servlet, eine JSP, ein eigenständiges Programm oder einen anderen Client nicht möglich".
  • [AIX Solaris HP-UX Linux Windows][IBM i]Überprüfen Sie die Schritte zum Diagnostizieren von Workload-Management-Problemen im Artikel "Fehlerbehebung bei der Workload-Management-Komponente".
[AIX Solaris HP-UX Linux Windows][IBM i]

EJB-Anforderungen werden nicht gleichmäßig verteilt

Es gibt eine Reihe von möglichen Ursachen für dieses Verhalten, die im Allgemeinen in eine der folgenden Kategorien fallen:
  • falsche Konfiguration
  • Umgebungsfehler, wie z. B. die Verfügbarkeit von Servern oder Anwendungen
  • eine große Anzahl von Anforderungen mit transaktionaler Affinität bzw.
  • eine kleine Anzahl von Clients

[AIX Solaris HP-UX Linux Windows][IBM i]Das Workload-Management im Produkt verwendet für die Verteilung von Anforderungen an die Server ein Schema mit proportionaler Gewichtung. Dieses Schema bewirkt, dass der Lastausgleich durch die Anzahl der Anforderungen und nicht durch andere Kriterien bestimmt wird. Ein echtes Problem mit dem Lastausgleich können Sie dadurch bestimmen, dass Sie die Anzahl der Anforderungen, die von jedem Member des Cluster verarbeitet werden, mit den Wertigkeiten, die für jedes dieser Member definiert werden, vergleichen. Führen Sie hierfür die im Artikel "Fehlerbehebung bei der Workload-Management-Komponente" beschriebenen Schritte aus.

[z/OS]Das Workload-Management im Produkt basiert auf einem Round-Robin-Schema der Anforderungsverteilung. Dieses Schema bewirkt, dass der Lastausgleich durch die Anzahl der Anforderungen und nicht durch andere Kriterien bestimmt wird. Ein echtes Problem mit dem Lastausgleich können Sie dadurch bestimmen, dass Sie die Anzahl der Anforderungen, die von jedem Member des Cluster verarbeitet werden, mit den Wertigkeiten, die für jedes dieser Member definiert werden, vergleichen.

[z/OS]
  • Wenn der Prozentsatz der Anforderungen, die für jedes Member des Cluster eingehen, mit den Wertigkeiten konsistent ist, muss eine weitere Analyse der Anwendung durchgeführt werden, um die Ursache für das Ungleichgewicht bei der Lastverteilung, das trotz ausgeglichener Anforderungsmenge besteht, zu ermitteln.
  • Wenn die Anzahl von numIncomingNonWLMObjectRequests nicht auf die Member des Cluster verteilt und im Verhältnis zu numIncomingRequests relativ groß ist, dann ist die Ursache für das Ungleichgewicht auf die nicht verteilbaren Komponenten zurückzuführen, die auf den Membern des Cluster installiert sind. Wenn Sie die Konfiguration entsprechend ändern, erhalten Sie eine ausgeglichenere Umgebung.
  • Wenn die Anzahl von umIncomingStrongAffinityRequests nicht gleichmäßig auf die Member des Cluster verteilt und im Verhältnis zu numIncomingRequests relativ groß ist, dann ist die Ursache für das Ungleichgewicht auf die Anforderungen zurückzuführen, die in einer Transaktion aufgerufen werden. Sie können die Menge der Anforderungen dadurch verringern, dass Sie die an einer Transaktion beteiligten Objekte in demselben Cluster installieren.

Ein fehlerhafter Server empfängt weiterhin Enterprise-Bean-Anforderungen (Failover wird nicht durchgeführt)

Die möglichen Ursachen dieses Fehlers sind:
  • [AIX Solaris HP-UX Linux Windows][IBM i]Der Client wurde zusammen mit einer Enterprise-Bean auf dem Server, der abgestürzt ist, ausgeführt. Überprüfen Sie die JVM-Protokolle des Anwendungsservers mit der betroffenen Enterprise-Bean-Instanz. Wenn eine Anforderung mit der Ausnahme CORBA SystemException COMM_FAILURE org.omg.CORBA.completion_status.COMPLETED_MAYBE zurückgegeben wird, liegt möglicherweise kein Fehler vor. Laut Entwurf wird diese besondere Ausnahme an den Client zurückgegeben, da die Transaktion möglicherweise abgeschlossen ist. Wenn Sie diese Anforderung an einen anderen Server leiten, führt dies möglicherweise dazu, dass die Anforderung zweimal bearbeitet wird.
  • [z/OS]Der Client wurde zusammen mit einer Enterprise-Bean auf dem Server, der abgestürzt ist, ausgeführt. Überprüfen Sie die JVM-Protokolle des Anwendungsservers mit der betroffenen Enterprise-Bean-Instanz. Wenn eine Anforderung mit der Ausnahme CORBA SystemException COMM_FAILURE org.omg.CORBA.completion_status.COMPLETED_MAYBE zurückgegeben wird, liegt möglicherweise kein Fehler vor. Laut Entwurf wird diese besondere Ausnahme an den Client zurückgegeben, da die Transaktion möglicherweise abgeschlossen ist. Wenn Sie diese Anforderung an einen anderen Server leiten, führt dies möglicherweise dazu, dass die Anforderung zweimal bearbeitet wird.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Wenn die Anforderungen, die an die Server gesendet wurden, konsistent mit einer anderen Ausnahme an den Client zurückgegeben werden, sind möglicherweise keine Server verfügbar. In diesem Fall führen Sie die Problemlösungsschritte im Artikel "Fehlerbehebung bei der Workload-Management-Komponente" aus.
  • [z/OS]Wenn die Anforderungen, die an die Server gesendet wurden, konsistent mit einer anderen Ausnahme an den Client zurückgegeben werden, sind möglicherweise keine Server verfügbar.
[z/OS]

Gestoppte oder blockierte Server teilen den Workload nach der Wiederherstellung nicht.

Dieser Fehler tritt auf, wenn zuvor nicht verfügbare Server von der Workload-Management-Komponente nicht erkannt werden, wenn diese Server wiederhergestellt werden. Die Eigenschaft "com.ibm.websphere.wlm.unusable.interval" gibt das Intervall unusable an. In diesem Zeitraum wartet die WLM-Komponente mit dem Senden von Daten an den Server, der als nicht verwendbar markiert wurde. Die Standardeinstellung gibt einen Zeitraum von 5 Minuten an.

Um sicherzustellen, dass das Problem hierauf zurückzuführen ist, vergewissern Sie sich, dass die Server, die vorher nicht aktiv waren, jetzt aktiv sind und Anforderungen bearbeiten können. Warten Sie dann, bis das Intervall "unusable" abgelaufen ist, bevor Sie prüfen, ob das Failover durchgeführt wurde.

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

Die Arbeitslast eines Cluster wird nicht vom Ausweichcluster übernommen

Es tritt ein Fehler wie der folgende auf:
[10/11/04 13:11:10:233 CDT] 00000036 SelectionMana A    WWLM0061W: Beim Senden
einer Anforderung an Cluster-Member {MEMBERNAME=FlorenceEJBServer1,
NODENAME=fwwsaix1Node01} ist ein Fehler aufgetreten, und das Member wurde für weitere Anforderungen an den
Cluster "" als nicht verwendbar markiert. Ausnahme: org.omg.CORBA.COMM_FAILURE:
CONNECT_FAILURE_ON_SSL_CLIENT_SOCKET - JSSL0130E:  java.io.IOException: Zeigt
an, dass eine E/A-Ausnahme eingetreten ist.   Reason:  Connection refused  
vmcid: 0x49421000  minor code: 70  completed: No" 
Führen Sie die folgenden Schritte aus, um Ihre Konfiguration zu korrigieren:
  1. Überprüfen Sie im Deployment Manager den Hostnamen und Bootstrap-Port für jede Ausweichclustereinstellung.
  2. Überprüfen Sie die Peer-Ports für die Stammgruppenbrücke, um sicherzustellen, dass Hostnamen und DCS-Port (Distribution and Consistency Services) korrekt sind.
  3. Vergewissern Sie sich, dass die Namen des primären Cluster und des Ausweichcluster übereinstimmen.
  4. Wenn Ihre Anwendung für die Verbindung zum Ausweichcluster Sicherheitseinstellungen verwendet, überprüfen Sie Ihre Sicherheitskonfiguration. Möglicherweise müssen Sie Single Sign-On (SSO) verwenden und die LTPA-Schlüssel in die Backup-Zelle importieren.

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_wlmprobs
Dateiname:rtrb_wlmprobs.html