Fehlerbehebung im Proxy-Server

Dieser Artikel beschreibt die Lösung von Problemen mit dem Proxy-Server.

• Der Proxy-Server wurde erfolgreich erstellt, aber ich kann ihn nicht starten.
  Überprüfen Sie die Datei SYSOUT auf Portkonflikte. Verwenden Sie den Befehl netstat -a, um festzustellen, ob bereits einer der Endpunkten, die dem Proxy-Server zugeordnet sind, verwendet wird. Sie finden die Ports in der Verwaltungskonsole, indem Sie auf klicken > Server > Proxy-Server > <server_name> > Ports.

  Falls der Proxy-Server beim Startversuch als Benutzer ohne Administratorrechte auf UNIX-Systemen nicht startet, überprüfen Sie die Protokolle auf folgende Meldung:

  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 Steckdose 
  Die Verbindung zum Host * und Port 80 konnte nicht hergestellt werden.  Der Port ist möglicherweise schon im Gebrauch.
  

  Geben Sie für die Ports der Transportketten PROXY_HTTP_ADDRESS und PROXY_HTTPS_ADDRESS höhere Werte als 1024 an.
• Der Proxy-Server leitet Anfragen über einen Port an den Web-Container 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 wurde gestartet, aber ich kann über die Endpunkte des Proxy-Servers nicht auf die Anwendungsressourcen zugreifen.
  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 den Datenverkehr an eine andere Kerngruppe 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 kann Anfragen nicht an eine andere Zelle weiterleiten.
  Ü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.

• Bei einer Anfrage an den Proxy wird eine leere Seite angezeigt.
  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 keine anderen Prozesse (z. B. Apache, IBM HTTP Server usw.) ausgeführt werden, die die Ports des Proxy-Servers nutzen (Standard: 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:
    1. Stoppen Sie den Proxy-Server.
    2. 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.
    3. 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. Andernfalls finden Sie unter „Anpassung der Weiterleitung zu Anwendungen“ Anweisungen zum Ändern der Proxy-Eigenschaften.
  • 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 Vom Proxy-Server wurde der Fehler 404 (Datei nicht gefunden) zurückgegeben.
  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. Andernfalls finden Sie unter „Anpassung der Weiterleitung zu Anwendungen“ Anweisungen zum Ändern der Proxy-Eigenschaften.
  • 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-Anfragen ( SSL ) an die Anwendung oder die Routing-Regel gesendet 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).
• Verbindung zum Proxy-Server konnte nicht hergestellt werden... Zeitüberschreitung bei der Anfrage.
  Stoppen Sie den im Konflikt befindlichen Prozess. Überprüfen Sie Ihr System, um sicherzustellen, dass keine anderen Prozesse (z. B. Apache, IBM HTTP Server usw.) ausgeführt werden, die die Ports des Proxy-Servers nutzen (Standard: 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:

  1. Stoppen Sie den Proxy-Server.
  2. 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.
  3. Wird ein fehlerhafter Prozess ermittelt, stoppen Sie den Prozess, und konfigurieren Sie das System so, dass der Prozess wahrend des Systemstarts nicht gestartet wird.
• Es wurde keine Antwort von der Fehler-Anwendung empfangen, als der Fehler „ HTTP “ auftrat (z. B. 404).
  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 unter „Übersicht über die Richtlinie für benutzerdefinierte Fehlerseiten “ sowie im Abschnitt „Richtlinie für benutzerdefinierte Fehlerseiten“ der Proxy-Server-Einstellungen.
• Welche Pakete muss ich aktivieren, wenn ich den Proxy-Server verfolge?
  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 “ beim Ein- und Ausschalten?
  SSL wird in der Administrationskonsole als Transportprotokoll bezeichnet und das Transportprotokoll ist eine der Eigenschaften des Webmoduls. Informationen zur Konfiguration der Eigenschaften von Webmodulen finden Sie unter „Anwendungsweiterleitung anpassen“. 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, wenn er hinter einem Webserver-Plugin läuft IBM HTTP Server , damit ich keinen Port für ihn zum virtuellen Host 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 beispielsweise einen IBM HTTP Server oder ein Webserver-Plugin, das Anfragen an den Proxy-Server sendet, zur Liste der vertrauenswürdigen Sicherheitsproxys des Proxy-Servers 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. Unter „Weiterleitung von Anfragen von einem Plug-in an einen Proxy-Server“ finden Sie weitere Informationen zur Konfiguration eines Webserver-Plug-ins für die Verwendung mit dem Proxy-Server. Unter „Proxy-Server-Einstellungen“ finden Sie weitere Informationen zur Einrichtung vertrauenswürdiger Sicherheitsproxys.
• Der Proxy-Server scheint unter hoher Auslastung zu hängen, oder es werden in ffdc oder SystemErr.log Ausnahmen wegen zu vieler geöffneter Dateien 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:

  • Optimierung des Betriebssystems 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:

      1. Verwenden Sie den Befehl „regedit“ und rufen Sie den HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters Registrierungsunterschlüssel auf, um einen neuen REG_DWORD-Wert mit dem Namen „ TcpTimedWaitDelay “ zu erstellen.
      2. Definieren Sie den Dezimalwert "30", der dem Hexadezimalwert "0x0000001e" entspricht. Dieser Wert definiert eine Wartezeit von 30 Sekunden.
      3. Stoppen Sie das System und starten Sie es anschließend erneut.

      Informationen	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:
      1. Verwenden Sie den Befehl „regedit“, rufen Sie den HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters registry Unterschlüssel auf und erstellen Sie einen neuen REG_DWORD-Wert mit dem Namen „ MaxUserPort “.
      2. Definieren Sie für diesen Parameter einen Mindestwert von "32768".
      3. Stoppen Sie das System und starten Sie es anschließend erneut.

      Informationen	Wert
      Standardwert	Ohne
      Empfohlene Einstellung	Mindestwert "32768"

  • Optimierung des Betriebssystems 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) – Legt die Anzahl der unterstützten offenen Dateien fest. 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.

      Um diesen Wert anzuzeigen oder festzulegen, lesen Sie die UNIX-Referenzseiten zum Befehl „ulimit“, um die Syntax für die verschiedenen Shells zu erfahren. 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.

      Informationen	Wert
      Standardwert	1024
      Empfohlene Einstellung	65535

  • Optimierung des Betriebssystems 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) – Legt die zulässige Anzahl geöffneter Dateien fest. 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 „ WebSphere® Application Server “ an Ressourcen mangelt, heben Sie die Begrenzungen (ulimit) für Ressourcen auf dem Benutzerkonto auf, unter dem der Prozess „ WebSphere Application Server “ läuft.
      Ändern Sie die Einstellungen für ulimit wie folgt, um diesen Wert anzuzeigen bzw. zu setzen:

      1. Öffnen Sie das Befehlsfenster.
      2. Geben Sie „smitty“ ein, um das Konfigurationsprogramm für „ AIX “ zu öffnen.
      3. Wählen Sie Ändern oder Merkmale anzeigen für einen Benutzer aus.
      4. Geben Sie den Namen des Benutzerkontos ein, unter dem der Dienst „ WebSphere Application Server “ ausgeführt wird.
      5. Drücken Sie die Eingabetaste.
      6. Ändern Sie die folgenden Einstellungen wie gezeigt:

         Informationen	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

      7. Drücken Sie die Eingabetaste, um die Änderungen zu speichern.
      8. Melden Sie sich ab und melden Sie sich erneut an Ihrem Account an.
      9. Starten Sie das Produkt erneut.

      Informationen	Wert
      Standardwert	2000
      Empfohlene Einstellung	Uneingeschränkt

  • Optimierung des Betriebssystems 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.

  • Optimierung des Betriebssystems 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. Um diesen Wert anzuzeigen oder festzulegen, lesen Sie die UNIX-Referenzseiten zum Befehl „ulimit“, um die Syntax für die verschiedenen Shells zu erfahren.
      • 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:

      1. Änderung des Werts für die aktuelle Shell-Sitzung:

         prctl -n process.max-file-descriptor -r -v 65535 $$

      2. 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.

      3. Änderung des Werts für alle Projekte, deren Eigner "root" ist:

         projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)'
         user.root

      4. Ä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. Zum Beispiel:

      ndd -get /dev/tcp tcp_time_wait_interval     
      ndd -set /dev/tcp tcp_time_wait_interval 30000  

      Informationen	Wert
      Standardwert	240000 Millisekunden, was 4 Minuten entspricht.
      Empfohlene Einstellung	60000 Millisekunden

  • 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.

      Sie können diesen Wert in der Verwaltungskonsole von „ WebSphere Application Server “ anzeigen oder festlegen, indem Sie auf „Server“ > „Proxy-Server “> „server_name“ > „Proxy-Server-Transporte“ > „HTTP_PROXY_CHAIN/HTTPS_PROXY_CHAIN“ klicken.

      Informationen	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 Verwaltungskonsole von „ WebSphere Application Server “ anzeigen oder festlegen, indem Sie auf „Server “ > „Proxy-Server “> „server_name“ > „Proxy-Server-Transporte“ > „ HTTP -Proxy-Server-Einstellungen“ 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.

      Informationen	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 Verwaltungskonsole anzeigen oder festlegen, indem Sie auf „Server “> „Servertypen “ > „ WebSphere -Proxyserver“ > „proxy_server_name“ > „Einstellungen für den HTTP -Proxyserver“ 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.

      Informationen	Wert
      Standardwert	120
      Empfohlene Einstellung	Ein Wert, der aus der Sicht des Clients eine akzeptable Antwortzeit angibt.