WEB- Proxy hängt mehrmals täglich

Hallo,
auch wir können dieses Problem hier leider bestätigen. WebAdmin ist nicht mehr erreichbar oder zickt mit extremen Wartezeiten und vermeintlich falschen Passwörtern rum, ATOP läuft und zeigt (sofern man überhaupt noch per SSH draufkommt, PING geht hoch bis in den Sekundenbereich oder steigt ganz aus) "postgres", "mdw.plx" und "httpproxy" mit hoher CPU-Last, snort bleibt immer gleichmäßig bei 15-25% (wobei dieser schon stark auf Performance mit wenigen Regeln optimiert ist), Swap geht hoch, RAM über 90%, und SDA ist komplett ausgelastet.

Angefangen hat der ganze "Spaß" vor ein paar Wochen, als der ha_sync plötzlich Ausfall meldete, dann Neustart, dann tagelang keine Erreichbarkeit für den DB-Abgleich. Erst ein Neustart von Master und später Slave brachte Abhilfe, die ha-DB war wieder erreichbar. Premium Support war schon drauf, erkannte einige Fehler, aber ansonsten leider Ratlosigkeit.

Interessant: obwohl wir das HTML5-Portal meines Wissens nicht aktiviert hatten, war es durch ha_sync irgendwann mal aktiviert worden. Ein missglückter DB-Abgleich zwischen Master und Slave? Jedenfalls wurde verschiedentlich schon darauf hingewiesen, dass hier ein Memory Leak droht, welches eigentlich schon gefixt sein sollte (abgesehen davon, dass das Portal hier eh von niemandem genutzt wird), ergo sofort abgeschaltet.

Der Proxy-Cache war eigentlich für die Endpoint-Updates aktiviert, aber der Webcache läuft dann ja auch mit - dessen Indexierung sorgt ja recht gerne auch für Probleme mit dem "anderen" Proxy - SQUID - ergo wurde auch dies deaktiviert.

All die vorgeschlagenen "Optimierungen" waren allerdings vor gut einem Monat NOCH NICHT NÖTIG. Im Gegenteil, selbst das dual - Scanning brachte die 220er nicht in die Knie, bei gleicher Benutzeranzahl und gleichem Traffic / concurrent Connections. 

Leider gibt es ja ansonsten noch andere Probleme mit den GoDaddy-Zertifikaten und den von der UTM-SNORT-IPS selbst geblockten Endpoint-Installationspaketen. So viel Feuerwehr spielen gab es zuletzt bei Endian. Und das will schon etwas heißen.

Hallo,
auch wir können dieses Problem hier leider bestätigen. WebAdmin ist nicht mehr erreichbar oder zickt mit extremen Wartezeiten und vermeintlich falschen Passwörtern rum, ATOP läuft und zeigt (sofern man überhaupt noch per SSH draufkommt, PING geht hoch bis in den Sekundenbereich oder steigt ganz aus) "postgres", "mdw.plx" und "httpproxy" mit hoher CPU-Last, snort bleibt immer gleichmäßig bei 15-25% (wobei dieser schon stark auf Performance mit wenigen Regeln optimiert ist), Swap geht hoch, RAM über 90%, und SDA ist komplett ausgelastet.

Angefangen hat der ganze "Spaß" vor ein paar Wochen, als der ha_sync plötzlich Ausfall meldete, dann Neustart, dann tagelang keine Erreichbarkeit für den DB-Abgleich. Erst ein Neustart von Master und später Slave brachte Abhilfe, die ha-DB war wieder erreichbar. Premium Support war schon drauf, erkannte einige Fehler, aber ansonsten leider Ratlosigkeit.

Interessant: obwohl wir das HTML5-Portal meines Wissens nicht aktiviert hatten, war es durch ha_sync irgendwann mal aktiviert worden. Ein missglückter DB-Abgleich zwischen Master und Slave? Jedenfalls wurde verschiedentlich schon darauf hingewiesen, dass hier ein Memory Leak droht, welches eigentlich schon gefixt sein sollte (abgesehen davon, dass das Portal hier eh von niemandem genutzt wird), ergo sofort abgeschaltet.

Der Proxy-Cache war eigentlich für die Endpoint-Updates aktiviert, aber der Webcache läuft dann ja auch mit - dessen Indexierung sorgt ja recht gerne auch für Probleme mit dem "anderen" Proxy - SQUID - ergo wurde auch dies deaktiviert.

All die vorgeschlagenen "Optimierungen" waren allerdings vor gut einem Monat NOCH NICHT NÖTIG. Im Gegenteil, selbst das dual - Scanning brachte die 220er nicht in die Knie, bei gleicher Benutzeranzahl und gleichem Traffic / concurrent Connections. 

Leider gibt es ja ansonsten noch andere Probleme mit den GoDaddy-Zertifikaten und den von der UTM-SNORT-IPS selbst geblockten Endpoint-Installationspaketen. So viel Feuerwehr spielen gab es zuletzt bei Endian. Und das will schon etwas heißen.