☰

Apache mit mod_jk mit Glassfish-Instanzen, große Anzahl hergestellter Verbindungen für geringe Anzahl von Benutzern

tag-icon • tag-icon apache-2.2 load-balancing cluster glassfish mod-jk
Apache mit mod_jk mit Glassfish-Instanzen, große Anzahl hergestellter Verbindungen für geringe Anzahl von Benutzern

Ich nehme eine Optimierung unserer Produktionsserver für ein Portal vor. Wir haben 4 Server, 2 für das Web und 2 für die App, und vor und nach den Webservern befindet sich eine Firewall (also ja, es gibt eine Firewall zwischen der App und den Webservern). Das Problem begann damit, dass inaktive Verbindungen zwischen den App- und den Webservern durch die Firewall unterbrochen wurden. Ich habe viele Lösungen ausprobiert und nun scheint sich das Problem von feststeckenden unterbrochenen Verbindungen in der App aufgrund der Unterbrechung durch die Firewall verlagert zu haben. Dieses Problem trat auf, wenn die Portalauslastung gering war, und um es zu lösen, musste ich alle App-Server neu starten. Jetzt habe ich stattdessen ein Problem mit Tagen mit hoher Auslastung, und die dringendste Lösung war einfach ein schneller Neustart der Apache-Webserver. So lösen Sie dieses Problem.

Ich habe mithilfe des JBoss-Loadbalancing-Konfigurationsgenerators Änderungen vorgenommen:http://lbconfig.appspot.com/?lb=mod_jk&mjv=1.2.28&nca=64&ncj=64&nai=2&nji=2&njips=6&f=true&c=false&lr=false&lrl=&mpm=Prefork

Und indem ich die Verbindungen auf beiden Servern mit dem Befehl netstat und mit der Echtzeitübersicht von Google Analytics überwacht habe, habe ich drei Tage nach dem letzten Neustart die folgenden Statistiken mit ca. 40 Besuchern erhalten:

Webseite(2 Server, aber Verbindungen „für jeden“, nicht insgesamt):

ESTABLISHED ~700 - 750
TIME_WAIT: 100-200 (big jumbs for one second 150 another 200 another 170 and then 120 and so)

App-Seite(hier habe ich alle Verbindungen gezählt, die meisten davon ESTABLISHED und einige CLOSE_WAIT 0 - 5 bei jeder Überprüfung):

S1 (4 instances running) : 900-950
S2 (5 instances running) : 1000-1100

Serverdetails:

  • Auf Web 2x-Servern: Apache 2.2.14 / mod_jk 1.2.37
  • auf App 2x Servern: Clustered Glassfish 2.1.1 mit ajp13 (6 Instanzen / jeder Server)
  • Alle Server Solaris SPARC 64 V-CPUs 32 GB RAM.

Meine Konfigurationen: Größtenteils so, wie es mir der Generator gegeben hat (Link ist zu sehen):

httpd.conf:

KeepAlive On
ServerLimit         12800
StartServers        5
MinSpareServers     5
MaxSpareServers     20
MaxClients          12800
MaxRequestsPerChild 5000

ExtendedStatus Off

Arbeiter.Eigenschaften:

worker.maintain=30
worker.template.type=ajp13
worker.template.session_cookie=JSESSIONID
worker.template.lbfactor=1
worker.template.ping_timeout=10000
worker.template.connection_pool_timeout=10
worker.template.socket_keepalive=True
worker.template.socket_timeout=600
worker.template.connect_timeout=10000
worker.template.prepost_timeout=10000
worker.template.connection_ping_interval=20
worker.template.ping_mode=A
worker.template.socket_connect_timeout=600000

Von GlassfishTimeouts von 10 Sekunden auf der Clusterkonfigurationsseite, ich habe:

HTTP-Diensteigenschaft:

  • VerbindungsTimeout = 10000

Anfragebearbeitung:

  • Anzahl der Threads: 2133
  • Anfängliche Thread-Anzahl: 20
  • Gewindesteigung: 10

Keep Alive (aktiviert):

  • Fadenzahl: 400
  • Max. Verbindungen 256
  • Zeitüberschreitung: 10 Sekunden

Verbindungspool:

  • Max. Anzahl ausstehender Verbindungen: 4096

Also:

  • Sind meine Konfigurationen also korrekt?
  • Wie kann ich das Problem einer hohen Anzahl hergestellter Verbindungen lösen oder ist es sicher? Ich möchte nicht, dass Apache erneut ausfällt, wenn die Last wieder hoch ist.

Antwort1

bezüglich mod_jk / mod_ajp: wir haben dies in einem etwas größeren Setup verwendet und sind immer wieder auf Bugs und Fehler gestoßen, Verbindungen wurden unterbrochen, aber wir haben nie eine wirkliche Lösung für eines unserer Probleme gefunden (aber wir haben einige Bugs gefunden, die immer noch existieren)

mein Rat: Machen Sie ein alternatives Setup und Leistungstests: mod_jk vs. proxy_http und wenn proxy_http innerhalb akzeptabler Bereiche liegt, überspringen Sie mod_jk. Ich habe das jetzt in zwei verschiedenen Setups gemacht (und kann zusätzlich Apache durch Nginx ersetzen -> GROSSER ERFOLG) und bereue es nicht.

Profis

  • einfacher zu debuggen
  • größere Vielfalt an möglichen lb/Frontend-Gateways (haproxy, nginx, varnish)
  • weniger Heisenbugs

Nachteile

  • habe keine gefunden

verwandte Informationen