Fehlerbehebung im Proxy-Server
Dieser Artikel beschreibt die Lösung von Problemen mit dem Proxy-Server.
Informationen zu diesem Vorgang
Fehler des Proxy-Servers werden im Jobprotokoll aufgezeichnet. Sehen Sie sich die folgende Liste an, wenn Sie Probleme mit Ihrem Proxy-Server haben.
Fehler des
Proxy-Servers werden in den Dateien "SystemOut.log", "proxy.log" und "local.log" protokolliert.
Sehen Sie sich die folgende Liste an, wenn Sie Probleme mit Ihrem Proxy-Server haben.
Vorgehensweise
- Der Proxy-Server wurde problemlos erstellt, kann jedoch nicht gestartet werden. Überprüfen Sie die Datei SYSOUT auf Portkonflikte. Prüfen Sie mit dem Befehl
netstat –a, ob Endpunkte, die dem Proxy-Server zugeordnet sind, bereits
verwendet werden.
Sie finden die Ports in der Administrationskonsole, indem Sie auf
Server > Proxy-Server > <Servername> > Ports
klicken.
Kann der Proxy-Server nicht gestartet werden, wenn Sie dies als nicht berechtigter Benutzer auf UNIX-Systemen versuchen, sollten Sie die Protokolle auf folgende Nachricht überprüfen:
Geben Sie für die Ports der Transportketten PROXY_HTTP_ADDRESS und PROXY_HTTPS_ADDRESS höhere Werte als 1024 an.ChannelFramew E CHFW0029E: Fehler beim Initialisieren der Kette HTTPS_PROXY_CHAIN wegen der Ausnahme com.ibm.wsspi.channel.framework.exception.RetryableChannelException: Berechtigung verweigert. TCPPort E TCPC0003E: Die Initialisierung von TCP-Kanal TCP_7 ist fehlgeschlagen. Die Socket-Bindung für Host * und Port 80 ist fehlgeschlagen. Der Port ist möglicherweise schon im Gebrauch.
- Der Proxy-Server leitet Anforderungen an den Web-Container über einen Verwaltungsport weiter. Der Proxy-Server ist mehreren Web-Containern vorgelagert.
Die Konfiguration erfordert, dass die Web-Container
an Ports wie 9061, 9081 usw., die keine Standardports sind, empfangsbereit sind.
Die ist das Standardszenario, wenn sich mehrere Anwendungsserver
auf derselben Maschine befinden. Eine solche Situation erfordert, dass in der Konfiguration neue und unterschiedliche Ports verwendet werden.
In diesem Szenario kann der Proxy-Server
eine Anwendungsanforderung über den Verwaltungsport
9061 anstelle des erwarteten Ports 9081 an den Web-Container weiterleiten.
Fügen Sie dem virtuellen Host, der der Zielanwendung zugeordnet ist, die Nummern der Listener-Ports des Web-Containers hinzu. Damit stellen Sie sicher, dass der Proxy-Server die Anforderung über den richtigen Port an den Web-Container weiterleitet.
- Der Proxy-Server ist gestartet, der Zugriff auf die Anwendungsressourcen über die Endpunkte für den Proxy-Server ist jedoch nicht möglich. Vergewissern Sie sich, dass die Endpunkte für den Proxy-Server unter den Hostaliassen im virtuellen Host aufgeführt sind, die der Anwendung zugeordnet sind.
- Der Proxy-Server leitet Anforderungen an eine andere Stammgruppe weiter. Vergewissern Sie sich, dass zwischen den Stammgruppen in der Zelle Stammgruppenbrücken vorhanden sind und die Prozesse, die als Brücken fungieren sollen, erneut gestartet werden. Wenn zwischen den Stammgruppen eine Firewall installiert ist, müssen Sie sicherstellen, dass für den Datenverkehr, der über die Stammgruppenbrücke läuft, die richtigen Ports geöffnet sind.
- Der Proxy-Server ist nicht in der Lage, Anforderungen an eine andere Zelle weiterzuleiten. Überprüfen Sie die Einstellungen für die Stammgruppenbrücke. Wenn die Fehlernachricht
HMGR0149E in einem Server protokolliert wird, gewöhnlich in einem Server, der als Stammgruppenbrücke dient,
müssen die Sicherheitseinstellungen für die Zelle geändert werden, um die Kommunikation zu ermöglichen.
Weitere Informationen zum Konfigurieren der Zellensicherheit zwischen mehreren Zellen finden Sie in dem Artikel LTPA-Schlüssel exportieren.
- Wenn eine Anforderung an den Proxy-Server abgesetzt wird, wird eine leere Seite empfangen. Ziehen Sie die Ausführung der folgenden Aktionen in Betracht:
- Virtuellen Host aktualisieren. Vergewissern Sie sich, dass die Zielanwendung und die Routing-Regel einem virtuellen Host zugeordnet sind, der die Empfangsports des Proxy-Servers beinhaltet (Standardwert: HTTP 80, HTTPS 443). Fügen Sie die Empfangsports des Proxy-Servers dem virtuellen Host der Anwendung oder der Routing-Regel hinzu oder verwenden Sie den virtuellen Host "proxy_host".
- Stoppen Sie den im Konflikt befindlichen Prozess. Überprüfen Sie Ihr System, um sicherzustellen, dass kein anderer Prozess
(z. B. Apache, IBM HTTP Server usw.) aktiv ist, der die Proxy-Server-Ports verwendet (Standardwert: HTTP 80, HTTPS 443).
Wenn dieses Problem auftritt, wird der Proxy-Server scheinbar normal gestartet, kann jedoch am betroffenen Empfangsport keine Anforderungen empfangen. Überprüfen Sie Ihr System wie folgt:
- Stoppen Sie den Proxy-Server.
- Fragen Sie Ihr System mit den Befehlen netstat und ps ab, um festzustellen, ob der Port, an dem der Proxy-Server empfangsbereit ist, von einem fehlerhaften Prozess verwendet wird.
- Wird ein fehlerhafter Prozess ermittelt, stoppen Sie den Prozess, und konfigurieren Sie das System so, dass der Prozess wahrend des Systemstarts nicht gestartet wird.
- Proxy-Routing aktivieren. Vergewissern Sie sich, dass das Proxy-Routing für das Webmodul der Anwendung aktiviert ist. Das Proxy-Routing ist standardmäßig aktiviert. Wenn also keine Proxy-Eigenschaften geändert werden, können Sie diese Lösung ignorieren. Ansonsten lesen Sie den Artikel Weiterleitung an Anwendungen anpassen, der Anweisungen zum Ändern der Proxy-Eigenschaften enthält.
- Direkte Anforderung testen. Vergewissern Sie sich, dass die Zielanwendung installiert ist, indem Sie eine Anforderung direkt an den Anwendungsserver absetzen. Wenn keine Antwort empfangen wird, liegt das Problem beim Anwendungsserver und nicht beim Proxy-Server. Sobald Sie eine Antwort direkt vom Anwendungsserver empfangen können, sollten Sie den Proxy-Server auf diese Möglichkeit hin überprüfen.
- HTTP-Fehler 404 (Datei nicht gefunden) vom Proxy-Server empfangen. Ziehen Sie die Ausführung der folgenden Aktionen in Betracht:
- Virtuellen Host aktualisieren. Vergewissern Sie sich, dass die Zielanwendung und die Routing-Regel einem virtuellen Host zugeordnet sind, der die Empfangsports des Proxy-Servers beinhaltet (Standardwert: HTTP 80, HTTPS 443). Fügen Sie die Empfangsports des Proxy-Servers dem virtuellen Host der Anwendung oder der Routing-Regel hinzu oder verwenden Sie den virtuellen Host "proxy_host".
- Proxy-Routing aktivieren. Vergewissern Sie sich, dass das Proxy-Routing für das Webmodul der Anwendung aktiviert ist. Das Proxy-Routing ist standardmäßig aktiviert. Wenn also keine Proxy-Eigenschaften geändert werden, können Sie diese Lösung ignorieren. Ansonsten lesen Sie den Artikel Weiterleitung an Anwendungen anpassen, der Anweisungen zum Ändern der Proxy-Eigenschaften enthält.
- Direkte Anforderung testen. Vergewissern Sie sich, dass die Zielanwendung installiert ist, indem Sie eine Anforderung direkt an den Anwendungsserver absetzen. Wenn keine Antwort empfangen wird, liegt das Problem beim Anwendungsserver und nicht beim Proxy-Server. Sobald Sie eine Antwort direkt vom Anwendungsserver empfangen können, sollten Sie den Proxy-Server auf diese Möglichkeit hin überprüfen.
- Es können keine SSL-Anforderungen (Secure Sockets Layer) an die Anwendung oder Routing-Regel abgesetzt werden. Vergewissern Sie sich, dass der virtuelle Host der Anwendung oder Routing-Regel einen Hostalias für den SSL-Port des Proxy-Servers einschließt (Standardwert: 443).
- Es kann keine Verbindung zum Proxy-Server hergestellt werden ... das Zeitlimit für die Anforderung wird überschritten. Stoppen Sie den im Konflikt befindlichen Prozess. Überprüfen Sie Ihr System, um sicherzustellen, dass kein anderer Prozess
(z. B. Apache, IBM HTTP Server usw.) aktiv ist, der die Proxy-Server-Ports verwendet (Standardwert: HTTP 80, HTTPS 443). Wenn dieses Problem auftritt, wird der Proxy-Server scheinbar normal gestartet, kann jedoch am betroffenen Empfangsport keine Anforderungen empfangen. Überprüfen Sie Ihr System wie folgt:
- Stoppen Sie den Proxy-Server.
- Fragen Sie Ihr System mit den Befehlen netstat und ps ab, um festzustellen, ob der Port, an dem der Proxy-Server empfangsbereit ist, von einem fehlerhaften Prozess verwendet wird.
- Wird ein fehlerhafter Prozess ermittelt, stoppen Sie den Prozess, und konfigurieren Sie das System so, dass der Prozess wahrend des Systemstarts nicht gestartet wird.
- Bei Auftreten des HTTP-Fehlers (z. B. 404) wurde keine Antwort von der Anwendung für fehlerhafte Seite empfangen. Vergewissern Sie sich, dass der URI für die Fehlerseite richtig eingegeben wurde. Vergewissern Sie sich außerdem, dass die Option "Ferne Fehler behandeln" ausgewählt ist, wenn Sie die HTTP-Fehlermeldungen von Back-End-Servern bearbeiten. Weitere Informationen finden Sie im Artikel Übersicht über die Richtlinie für angepasste Fehlerseiten und im Abschnitt zur Richtlinie für angepasste Fehlerseiten im Artikel Einstellungen für Proxy-Server.
- Welche Pakete sollen aktiviert werden, wenn ein Trace für den Proxy-Server erstellt wird? Die folgenden Pakete werden nicht alle für jeden Trace benötigt. Im Zweifelsfall
sollten Sie aber alle verwenden:
- *=info
- WebSphere Proxy=all
- GenericBNF=all
- HAManager=all
- HTTPChannel=all
- TCPChannel=all
- WLM*=all
- DCS=all
- ChannelFrameworkService=all
- com.ibm.ws.dwlm.*=all
- com.ibm.ws.odc.*=all
- Wie aktiviere ich SSL? SSL wird in der Administrationskonsole als Transportprotokoll bezeichnet und das Transportprotokoll ist eine der Eigenschaften des Webmoduls. Im Artikel Weiterleitung an Anwendungen anpassen wird beschrieben, wie Sie Webmoduleigenschaften konfigurieren. Für Routing-Regeln gibt es keine Eigenschaften für "SSL on/off Load" bzw. für das Transportprotokoll, da das Transportprotokoll zum generischen, in der Routing-Regel angegebenen Server-Cluster gehört.
- Wie konfiguriere ich den Proxy-Server bei einem vorgeschalteten IBM HTTP Server oder Web-Server-Plug-in so, dass Ich dem virtuellen Host keinen Port für den Proxy-Server hinzufügen muss? Damit der Proxy-Server die sicherheitsrelevanten Informationen anerkennt, die in einer Anforderung enthalten sind, wie z. B. private Header, die das Produkt hinzufügt, fügen Sie den Absender der Anforderung der Liste der Sicherheitsproxys für den Proxy-Server hinzu. Fügen Sie der Liste der vom Proxy-Server anerkannten Sicherheitsproxys beispielsweise einen IBM HTTP Server oder ein Web-Server-Plug-in hinzu. Anschließend kann das Web-Server-Plug-in vom Produkt hinzugefügte private Headerinformationen senden, die die Informationen zum virtuellen Host einer Anforderung enthalten. Wenn der Proxy diese privaten Header vom Web-Server-Plug-in oder von einem Client nicht anerkennt, fügt der Proxy-Server seine eigenen privaten Header hinzu. Dies erfordert, dass die HTTP- und HTTP-Ports des Proxy-Servers dem virtuellen Host hinzugefügt werden. Wenn ein Web-Server-Plug-in mit dem Proxy-Server verwendet wird, soll der Proxy-Server gewöhnlich als Back-End-Server dienen. Deshalb müssen Sie das Plug-in als anerkannten Sicherheitsproxy hinzufügen, um zu verhindern, dass die Ports des Proxy-Servers offengelegt werden. Der Artikel Anforderungen von einem Plug-in an einen Proxy-Server weiterleiten enthält weitere Informationen zum Konfigurieren eines Web-Server-Plug-ins für den Proxy-Server. Weitere Informationen zum Konfigurieren anerkannter Sicherheitsproxys finden Sie im Artikel Einstellungen für Proxy-Server.
- Der Proxy-Server scheint unter Belastung blockiert zu sein oder Ausnahmebedingungen
des Typs "Zu viele Dateien geöffnet" werden im Verzeichnis "ffdc" bzw. in der Datei "SystemErr.log" angezeigt. Bei
hoher Verbindungslast ist die Kapazität der Systemdeskriptoren möglicherweise erschöpft und der Proxy-Server scheint blockiert zu sein und setzt
Ausnahmebedingungen des Typs "Zu viele Dateien geöffnet" im Verzeichnis ffdc oder in der Datei "SystemError.log" ab,
weil er keinen Socket öffnen kann. Sie können
das Problem vermeiden, indem Sie einen oder mehrere der folgenden Parameter auf Betriebssystemebene und auf der Ebene des Proxy-Servers setzen, die die Verwendung von Verbindungen für den Proxy-Server optimieren:
Betriebssystemoptimierung für Windows 2003 und XP
- TcpTimedWaitDelay - Dieser Parameter gibt die Zeit an, die vergehen muss, bevor TCP/IP
eine geschlossene Verbindung freigeben und die Ressourcen erneut verwenden kann. Dieses Intervall zwischen Schließen und
Freigabe einer Verbindung wird als TIME_WAIT-Status oder 2MSL-Status (Twice the Maximum Segment
Lifetime) bezeichnet. Während dieser Zeit ist der Aufwand für das erneute Öffnen der Verbindung zu Client und Server geringer
als für das Herstellen einer neuen Verbindung. Wenn Sie den Wert dieses Eintrags verringern, kann TCP/IP geschlossene Verbindungen schneller freigeben und damit
mehr Ressourcen für neue Verbindungen zur Verfügung stellen. Passen Sie diesen Parameter an, wenn die aktive Anwendung eine schnelle Freigabe und das Einrichten neuer
Verbindungen erfordert und der Durchsatz aufgrund zu vieler vorhandener Verbindungen im TIME_WAIT-Status
gering ist. Gehen Sie wie folgt vor, um diesen Wert anzuzeigen bzw. zu setzen:
- Greifen Sie mit dem Befehl regedit auf den Unterschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters der Registry zu und erstellen Sie einen neuen REG_DWORD-Wert mit dem Namen "TcpTimedWaitDelay".
- Definieren Sie den Dezimalwert "30", der dem Hexadezimalwert "0x0000001e" entspricht. Dieser Wert definiert eine Wartezeit von 30 Sekunden.
- Stoppen Sie das System und starten Sie es anschließend erneut.
Information Wert Standardwert 0xF0. Dieser Wert definiert eine Wartezeit von 240 Sekunden (4 Minuten). Empfohlene Einstellung Mindestwert 0x1E. Dieser Wert definiert eine Wartezeit von 30 Sekunden. - MaxUserPort - Dieser Parameter bestimmt die höchste Portnummer, die TCP/IP
zuordnen kann, wenn eine Anwendung einen verfügbaren Benutzerport beim System anfordert. Gehen Sie wie folgt vor, um diesen Wert anzuzeigen bzw. zu setzen:
- Verwenden Sie den Befehl regedit, greifen Sie auf den Unterschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters registry zu und erstellen Sie einen neuen Wert für REG_DWORD mit dem Namen "MaxUserPort".
- Definieren Sie für diesen Parameter einen Mindestwert von "32768".
- Stoppen Sie das System und starten Sie es anschließend erneut.
Information Wert Standardwert Ohne Empfohlene Einstellung Mindestwert "32768"
- TcpTimedWaitDelay - Dieser Parameter gibt die Zeit an, die vergehen muss, bevor TCP/IP
eine geschlossene Verbindung freigeben und die Ressourcen erneut verwenden kann. Dieses Intervall zwischen Schließen und
Freigabe einer Verbindung wird als TIME_WAIT-Status oder 2MSL-Status (Twice the Maximum Segment
Lifetime) bezeichnet. Während dieser Zeit ist der Aufwand für das erneute Öffnen der Verbindung zu Client und Server geringer
als für das Herstellen einer neuen Verbindung. Wenn Sie den Wert dieses Eintrags verringern, kann TCP/IP geschlossene Verbindungen schneller freigeben und damit
mehr Ressourcen für neue Verbindungen zur Verfügung stellen. Passen Sie diesen Parameter an, wenn die aktive Anwendung eine schnelle Freigabe und das Einrichten neuer
Verbindungen erfordert und der Durchsatz aufgrund zu vieler vorhandener Verbindungen im TIME_WAIT-Status
gering ist.
Betriebssystemoptimierung für Linux
- Parameter timeout_timewait. Dieser Parameter gibt die Zeit an, die vergehen muss, bevor TCP/IP
eine geschlossene Verbindung freigeben und die Ressourcen erneut verwenden kann. Dieses Intervall zwischen Schließen und
Freigabe einer Verbindung wird als TIME_WAIT-Status oder 2MSL-Status (Twice the Maximum Segment
Lifetime) bezeichnet. Während dieser Zeit ist der Aufwand für das erneute Öffnen der Verbindung zu Client und Server geringer
als für das Herstellen einer neuen Verbindung. Wenn Sie den Wert dieses Eintrags verringern, kann TCP/IP geschlossene Verbindungen schneller freigeben und damit
mehr Ressourcen für neue Verbindungen zur Verfügung stellen. Passen Sie diesen Parameter an, wenn die aktive Anwendung eine schnelle Freigabe und das Einrichten neuer
Verbindungen erfordert und der Durchsatz aufgrund zu vieler vorhandener Verbindungen im TIME_WAIT-Status
gering ist. Verwenden Sie den folgenden Befehl, um den Parameter timeout_timewait anzuzeigen oder auf
30 Sekunden zu setzen:
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
- Linux-Dateideskriptoren (ulimit). Dieser Parameter gibt die zulässige Anzahl geöffneter Dateien an. Die Standardeinstellung
ist für die meisten Anwendungen in der Regel ausreichend. Wenn der Wert dieses Parameters zu klein gewählt ist,
kann ein Fehler vom Typ "Datei geöffnet", "Fehler bei der Speicherzuordnung" oder "Verbindung aufgebaut" angezeigt werden.
Sehen Sie sich die UNIX-Referenzseiten für den Befehl "ulimit" mit der Syntax verschiedener Shells an, um diesen Wert anzuzeigen oder festzulegen. Wenn Sie ulimit in der Korn-Shell (ksh) beispielsweise auf "65535" setzen möchten, setzen Sie den Befehl "ulimit -n 65535" ab. Verwenden Sie den Befehl "ulimit -a", um die derzeit festgelegten Grenzwerte für Systemressourcen anzuzeigen.
Information Wert Standardwert 1024 Empfohlene Einstellung 65535
- Parameter timeout_timewait. Dieser Parameter gibt die Zeit an, die vergehen muss, bevor TCP/IP
eine geschlossene Verbindung freigeben und die Ressourcen erneut verwenden kann. Dieses Intervall zwischen Schließen und
Freigabe einer Verbindung wird als TIME_WAIT-Status oder 2MSL-Status (Twice the Maximum Segment
Lifetime) bezeichnet. Während dieser Zeit ist der Aufwand für das erneute Öffnen der Verbindung zu Client und Server geringer
als für das Herstellen einer neuen Verbindung. Wenn Sie den Wert dieses Eintrags verringern, kann TCP/IP geschlossene Verbindungen schneller freigeben und damit
mehr Ressourcen für neue Verbindungen zur Verfügung stellen. Passen Sie diesen Parameter an, wenn die aktive Anwendung eine schnelle Freigabe und das Einrichten neuer
Verbindungen erfordert und der Durchsatz aufgrund zu vieler vorhandener Verbindungen im TIME_WAIT-Status
gering ist. Verwenden Sie den folgenden Befehl, um den Parameter timeout_timewait anzuzeigen oder auf
30 Sekunden zu setzen:
Betriebssystemoptimierung für AIX
- Parameter TCP_TIMEWAIT. Dieser Parameter gibt die Zeit an, die vergehen muss, bevor TCP/IP
eine geschlossene Verbindung freigeben und die Ressourcen erneut verwenden kann. Dieses Intervall zwischen Schließen und
Freigabe einer Verbindung wird als TIME_WAIT-Status oder 2MSL-Status (Twice the Maximum Segment
Lifetime) bezeichnet. Während dieser Zeit ist der Aufwand für das erneute Öffnen der Verbindung zu Client und Server geringer
als für das Herstellen einer neuen Verbindung. Wenn Sie den Wert dieses Eintrags verringern, kann TCP/IP geschlossene Verbindungen schneller freigeben und damit
mehr Ressourcen für neue Verbindungen zur Verfügung stellen. Passen Sie diesen Parameter an, wenn die aktive Anwendung eine schnelle Freigabe und das Einrichten neuer
Verbindungen erfordert oder der Durchsatz aufgrund zu vieler vorhandener Verbindungen im TIME_WAIT-Status
gering ist. Verwenden Sie den folgenden Befehl, um den Parameter TCP_TIMEWAIT anzuzeigen oder auf
15 Sekunden zu setzen:
/usr/sbin/no -o tcp_timewait =1
- AIX-Dateideskriptoren (ulimit). Dieser Parameter gibt die zulässige Anzahl geöffneter Dateien an. Die Standardeinstellung
ist für die meisten Anwendungen in der Regel ausreichend. Wenn der für diesen Parameter gewählte Wert zu niedrig ist,
können beim Öffnen von Dateien oder beim Aufbau von Verbindungen und bei der Speicherzuordnung Fehler auftreten.
Um zu verhindern, dass in WebSphere Application Server eine Ressourcenknappheit auftritt, entfernen Sie die
Grenzwerte (ulimit) für Ressourcen in dem Benutzeraccount, unter dem der WebSphere Application Server-Prozess ausgeführt wird. Ändern Sie die Einstellungen für ulimit wie folgt, um diesen Wert anzuzeigen bzw. zu setzen:
- Öffnen Sie das Befehlsfenster.
- Geben Sie smitty users ein, um das AIX-Konfigurationsprogramm zu öffnen.
- Wählen Sie Merkmale ändern/anzeigen aus.
- Geben Sie den Namen des Benutzeraccounts ein, unter dem WebSphere Application Server ausgeführt wird.
- Drücken Sie die Eingabetaste.
- Ändern Sie die folgenden Einstellungen wie gezeigt:
Information Wert Variable Dateigröße -1 Variable CPU-Zeit -1 Variable Stackgröße -1 Variable Kerndateigröße -1 Feste Dateigröße -1 Feste CPU-Zeit -1 Feste Stackgröße -1 Feste Kerndateigröße -1 - Drücken Sie die Eingabetaste, um die Änderungen zu speichern.
- Melden Sie sich ab und melden Sie sich erneut an Ihrem Account an.
- Starten Sie das Produkt erneut.
Information Wert Standardwert 2000 Empfohlene Einstellung Uneingeschränkt
- Parameter TCP_TIMEWAIT. Dieser Parameter gibt die Zeit an, die vergehen muss, bevor TCP/IP
eine geschlossene Verbindung freigeben und die Ressourcen erneut verwenden kann. Dieses Intervall zwischen Schließen und
Freigabe einer Verbindung wird als TIME_WAIT-Status oder 2MSL-Status (Twice the Maximum Segment
Lifetime) bezeichnet. Während dieser Zeit ist der Aufwand für das erneute Öffnen der Verbindung zu Client und Server geringer
als für das Herstellen einer neuen Verbindung. Wenn Sie den Wert dieses Eintrags verringern, kann TCP/IP geschlossene Verbindungen schneller freigeben und damit
mehr Ressourcen für neue Verbindungen zur Verfügung stellen. Passen Sie diesen Parameter an, wenn die aktive Anwendung eine schnelle Freigabe und das Einrichten neuer
Verbindungen erfordert oder der Durchsatz aufgrund zu vieler vorhandener Verbindungen im TIME_WAIT-Status
gering ist. Verwenden Sie den folgenden Befehl, um den Parameter TCP_TIMEWAIT anzuzeigen oder auf
15 Sekunden zu setzen:
Betriebssystemoptimierung für HP-UX
HP-UX-Kernelparameter "nfile" - Gibt die maximale Anzahl an Dateien an, die zu einem bestimmten Zeitpunkt auf dem System geöffnet sein können. Die Angabe eines zu niedrigen Werts kann die Verarbeitungskapazität des Systems einschränken.
HP-UX-Kernelparameter "ninode" - Gibt die maximale Anzahl offener I-Nodes im Hauptspeicher an. Jeder eindeutigen offenen Datei ist ein offener I-Node zugeordnet. Deshalb muss der Wert, den Sie für den Parameter "ninode" angeben, größer als die Anzahl eindeutiger Dateien sein, die gleichzeitig offen sein dürfen.
Betriebssystemoptimierung für Solaris
- Solaris-Dateideskriptoren (ulimit). Dieser Parameter gibt die zulässige Anzahl geöffneter Dateien an. Wenn der Wert dieses Parameters zu klein gewählt ist,
kann ein Fehler vom Typ "Datei geöffnet", "Fehler bei der Speicherzuordnung" oder "Verbindung aufgebaut" angezeigt werden.
Sehen Sie sich die UNIX-Referenzseiten für den Befehl "ulimit" mit der Syntax verschiedener Shells an,
um diesen Wert anzuzeigen oder festzulegen.
- Setzen Sie den Befehl ulimit -a ab, um die aktuellen Werte für alle Einschränkungen für Systemressourcen anzuzeigen.
- Setzen Sie den Befehl ulimit -n 65535 ab, um den ulimit-Wert für die Korn-Shell (ksh) auf 65535 zu setzen.
- Die maximale Anzahl an Dateien, die für einen Prozess geöffnet werden können, wird auch durch die Einstellungen rlim_fd_max und rlim_fd_cur für das globale Kernellimit beeinflusst. Möglicherweise müssen Sie die Werte dieser Einstellungen in der Datei "/etc/system" erhöhen.
Solaris 10 stellt einen neuen Mechanismus für die Definition von Kernelparametern bereit. Setzen Sie einen der folgenden Befehle ab, um einen neuen Grenzwert für den Kernel-Parameter für die maximale Anzahl geöffneter Dateideskriptoren unter Solaris 10 anzugeben:- Änderung des Werts für die aktuelle Shell-Sitzung:
prctl -n process.max-file-descriptor -r -v 65535 $$
- Systemweite Änderung:
projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)' system
Verwenden Sie diesen Befehl mit Vorsicht, weil dieser Befehl die Einstellung für alle Benutzer und alle Projekte ändert.
- Änderung des Werts für alle Projekte, deren Eigner "root" ist:
projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)' user.root
- Änderung des Werts für alle Projekte, deren Eigner ein Benutzer ohne Rootberechtigung ist:
projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)' user.username
- TCP_TIME_WAIT_INTERVAL. Dieser Parameter gibt TCP/IP vor, wie lange die Steuerblöcke für Verbindungen
geschlossen bleiben sollen. Nachdem die Anwendungen die TCP/IP-Verbindung beenden, bleiben die Steuerblöcke für die angegebene Zeit geschlossen.
Bei einem hohen Verbindungsaufkommen wächst das Backlog der TCP/IP-Verbindungen an, was sich nachteilig auf
die Serverleistung auswirken kann. In Perioden mit hoher Systemauslastung kann der Server sogar blockieren. Sollte der Server
blockieren, können Sie mit dem Befehl netstat anzeigen, dass sich viele der
für den HTTP-Server geöffneten Sockets im Status CLOSE_WAIT oder FIN_WAIT_2 befinden. Es können spürbare Verzögerungen bis zu vier Minuten
auftreten. In dieser Zeit sendet der Server keine Antworten, aber die CPU-Auslastung bleibt wegen der
Aktivitäten in den Systemprozessen weiterhin hoch. Mit dem Befehl get können Sie das aktuelle Intervall ermitteln und mit dem Befehl "set" ein Intervall von 30 Sekunden festlegen. Beispiel:
ndd -get /dev/tcp tcp_time_wait_interval ndd -set /dev/tcp tcp_time_wait_interval 30000
Information Wert Standardwert 240000 Millisekunden, was 4 Minuten entspricht. Empfohlene Einstellung 60000 Millisekunden
- Solaris-Dateideskriptoren (ulimit). Dieser Parameter gibt die zulässige Anzahl geöffneter Dateien an. Wenn der Wert dieses Parameters zu klein gewählt ist,
kann ein Fehler vom Typ "Datei geöffnet", "Fehler bei der Speicherzuordnung" oder "Verbindung aufgebaut" angezeigt werden.
Sehen Sie sich die UNIX-Referenzseiten für den Befehl "ulimit" mit der Syntax verschiedener Shells an,
um diesen Wert anzuzeigen oder festzulegen.
- Optimierung des Proxy-Servers
- Persistente Anforderungen - Eine persistente Anforderung ist eine Anforderung, die über eine vorhandene TCP-Verbindung gesendet wird. Sie können die Leistung erhöhen, indem Sie die Anzahl der Anforderungen, die über eine TCP-Verbindung von einem Client empfangen werden, erhöhen. Der Wert sollte die maximale Anzahl der in einer Webseite eingebetteten Objekte, z. B. GIF usw., plus 1 betragen.
Klicken Sie in der Administrationskonsole von WebSphere Application Server auf Server > Proxy-Server > Servername > Transport für Proxy-Server > HTTP_PROXY_CHAIN/HTTPS_PROXY_CHAIN, um diesen Wert anzuzeigen oder festzulegen.
Information Wert Standardwert 100 Empfohlene Einstellung Ein Wert, der die maximale Anzahl der in einer Webseite eingebetteten Objekte plus 1 angibt. - Poolgröße für abgehende Verbindungen - Der Proxy-Server stellt an Zielserver abgehende Verbindungen in Pools und die Anzahl der im Pool befindlichen Verbindungen ist konfigurierbar. Wenn der Verbindungspool gelöscht oder leer ist, erstellt der Proxy-Server eine neue Verbindung zum Zielserver. Unter hoher gleichzeitig auftretender Arbeitslast muss die Größe des Verbindungspools auf einen Wert erhöht werden, der der erwarteten Clientarbeitslast entspricht, damit eine optimale Leistung erzielt werden kann.
Sie können diesen Wert in der Administrationskonsole von WebSphere Application Server anzeigen und definieren, indem Sie auf Server > Proxy-Server > Servername > Transporte für Proxy-Server > Einstellungen des HTTP-Proxy-Servers klicken. Erhöhen Sie im Abschnitt "Content-Server-Verbindung" die maximale Anzahl der Verbindungen pro Server auf einen Wert, der größer-gleich der erwarteten Anzahl verbundener Clients ist. Speichern Sie Ihre Änderungen, synchronisieren Sie die Änderungen mit dem Proxy-Server-Knoten und starten Sie den Proxy-Server erneut.
Information Wert Empfohlene Einstellung Wert, der mit der erwarteten gleichzeitig auftretenden Clientarbeitslast konsistent ist. - Zeitlimit für abgehende Anforderungen - Oft haben die Back-End-Anwendungsserver, denen der Proxy-Server vorangestellt ist,
eine hohe Arbeitslast und antworten nicht innerhalb eines akzeptablen Zeitraums. Das kann dazu führen, dass die Verbindungen auf dem Proxy-Server
dadurch, dass sie auf die Antwort des Back-End-Anwendungsservers warten, gebunden werden. Sie können dieses Problem entschärfen, indem Sie die Zeit, die
der Proxy-Server auf eine Antwort des Zielservers wartet, konfigurieren. Dabei handelt es sich um das Zeitlimit für abgehende Anforderungen.
Wenn Sie die Zeit, die der Proxy-Server auf einen langsamen Back-End-Anwendungsserver wartet, steuern, werden Verbindungen schneller freigegeben und für andere Anforderungen eingesetzt. Sie können diesen Wert in der Administrationskonsole anzeigen oder setzen, indem Sie auf Server > Servertypen > WebSphere-Proxy-Server > Name_des_Proxy-Servers > Einstellungen des HTTP-Proxy-Servers klicken. Legen Sie im Abschnitt "Content-Server-Verbindung" für das Zeitlimit für abgehende Verbindungen einen Wert fest, der aus der Sicht des Clients eine akzeptable Antwortzeit angibt.
Information Wert Standardeinstellung 120 Empfohlene Einstellung Ein Wert, der aus der Sicht des Clients eine akzeptable Antwortzeit angibt.
- Persistente Anforderungen - Eine persistente Anforderung ist eine Anforderung, die über eine vorhandene TCP-Verbindung gesendet wird. Sie können die Leistung erhöhen, indem Sie die Anzahl der Anforderungen, die über eine TCP-Verbindung von einem Client empfangen werden, erhöhen. Der Wert sollte die maximale Anzahl der in einer Webseite eingebetteten Objekte, z. B. GIF usw., plus 1 betragen.
Unterartikel
Fehlerbehebung für das Anforderungsrouting und Workload-Management über den Proxy-Server
Dieser Artikel enthält Informationen zur Fehlerbehebung beim Anforderungsverkehr, der über den Proxy-Server fließt.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tjpx_troubproxy
Dateiname:tjpx_troubproxy.html