WEB- Proxy hängt mehrmals täglich

Was sagt denn das /var/log/up2date.log um die Uhrzeit aus dem WebAdmin-Screenshot?

Was sagt denn das /var/log/up2date.log um die Uhrzeit aus dem WebAdmin-Screenshot?

Leider nix:

2014:01:30-14:23:46 astaro-1 auisys[14220]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="preinst_check" package="geoipxt"
2014:01:30-14:23:52 astaro-1 auisys[14220]: id="3716" severity="info" sys="system" sub="up2date" name="Up2date Package Installer finished, exiting"
2014:01:30-15:01:02 astaro-1 audld[21118]: Starting Up2Date Package Downloader
2014:01:30-15:01:02 astaro-1 audld[21118]: patch up2date possible

Gerade wieder um ca 10:15 einen langen Hänger mit 100% CPU Auslastung laut WebAdmin gehabt.

Up2Date zeigt an, dass es kurz vorher etwas gemacht hat. Aber in dem Fallback Log habe ich dann Einträge gefunden, die besser zur Uhrzeit des Problems passen.

up2date:Gerade wieder um ca 10:15 einen langen Hänger mit 100% CPU Auslastung laut WebAdmin gehabt.

Up2Date zeigt an, dass es kurz vorher etwas gemacht hat. Aber in dem Fallback Log habe ich dann Einträge gefunden, die besser zur Uhrzeit des Problems passen.


up2date:

2014:02:04-10:07:02 astaro-1 audld[15172]: Starting Up2Date Package Downloader

2014:02:04-10:07:05 astaro-1 audld[15172]: patch up2date possible

2014:02:04-10:07:17 astaro-1 audld[15172]: id="3701" severity="info" sys="system" sub="up2date" name="Authentication successful"

2014:02:04-10:08:57 astaro-1 audld[15172]: id="3707" severity="info" sys="system" sub="up2date" name="Successfully synchronized fileset" status="success" action="download" package="clam"

2014:02:04-10:08:58 astaro-1 auisys[15327]: Starting Up2Date Package Installer

2014:02:04-10:08:58 astaro-1 auisys[15327]: Searching for available up2date packages for type 'appctrl'

2014:02:04-10:08:58 astaro-1 auisys[15327]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="preinst_check" package="appctrl"

2014:02:04-10:09:03 astaro-1 auisys[15327]: Searching for available up2date packages for type 'avira'

2014:02:04-10:09:03 astaro-1 auisys[15327]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="preinst_check" package="avira"

2014:02:04-10:09:08 astaro-1 auisys[15327]: Searching for available up2date packages for type 'geoip'

2014:02:04-10:09:08 astaro-1 auisys[15327]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="preinst_check" package="geoip"

2014:02:04-10:09:14 astaro-1 auisys[15327]: Searching for available up2date packages for type 'clam'

2014:02:04-10:09:14 astaro-1 auisys[15327]: Installing up2date package file '/var/up2date//clam/u2d-clam-7.12077-12097.patch.tgz.gpg'

2014:02:04-10:09:14 astaro-1 auisys[15327]: Verifying up2date package signature

2014:02:04-10:09:14 astaro-1 auisys[15327]: Unpacking installation instructions

2014:02:04-10:09:14 astaro-1 auisys[15327]: Unpacking up2date package container

2014:02:04-10:09:15 astaro-1 auisys[15327]: Running pre-installation checks

2014:02:04-10:09:15 astaro-1 auisys[15327]: Starting up2date package installation

2014:02:04-10:10:08 astaro-1 auisys[15327]: Still waiting for process 'sync' (pid=15416, timeout 8388607 seconds, 8388577 remaining)

2014:02:04-10:10:38 astaro-1 auisys[15327]: Still waiting for process 'sync' (pid=15416, timeout 8388607 seconds, 8388547 remaining)

2014:02:04-10:10:39 astaro-1 auisys[15327]: id="371Z" severity="info" sys="system" sub="up2date" name="Successfully installed Up2Date package" status="success" action="install" package_version="7.12097" package="clam"

2014:02:04-10:10:39 astaro-1 auisys[15327]: New Pattern Up2Dates installed

2014:02:04-10:10:46 astaro-1 auisys[15327]: Searching for available up2date packages for type 'man8'

2014:02:04-10:10:46 astaro-1 auisys[15327]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="preinst_check" package="man8"

2014:02:04-10:10:51 astaro-1 auisys[15327]: Searching for available up2date packages for type 'ohelpng'

2014:02:04-10:10:52 astaro-1 auisys[15327]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="preinst_check" package="ohelpng"

2014:02:04-10:10:57 astaro-1 auisys[15327]: Searching for available up2date packages for type 'geoipxt'

2014:02:04-10:10:57 astaro-1 auisys[15327]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="preinst_check" package="geoipxt"

2014:02:04-10:11:15 astaro-1 auisys[15327]: id="3716" severity="info" sys="system" sub="up2date" name="Up2date Package Installer finished, exiting"

fallback:

2014:02:04-10:14:17 astaro [user:notice] ":

2014:02:04-10:14:17 astaro [user:notice] ":

2014:02:04-10:14:17 astaro [user:notice] ":

2014:02:04-10:14:18 astaro [user:notice] ":

2014:02:04-10:14:18 astaro [user:notice] ":

2014:02:04-10:14:27 astaro [local6:info] clamd[8256]: Database correctly reloaded (3101290 signatures)

2014:02:04-10:15:12 astaro [user:notice] ":

2014:02:04-10:15:12 astaro [user:notice] ":

2014:02:04-10:15:15 astaro [user:notice] ":

2014:02:04-10:15:15 astaro [user:notice] ":

2014:02:04-10:15:45 astaro [user:notice] ":

2014:02:04-10:16:02 astaro-2 clamd[8175]: Reading databases from /var/pattern/clam

2014:02:04-10:16:15 astaro-2 clamd[8175]: Database correctly reloaded (3101290 signatures)

2014:02:04-10:20:28 astaro [daemon:info] admin-reporter[13477]: Successful SSH login

2014:02:04-10:21:58 astaro [user:notice] ":

2014:02:04-10:24:43 astaro [user:notice] ":

2014:02:04-10:24:43 astaro [user:notice] ":

Update:
nachdem unser Fall nun beim Escalation Support gelandet ist, haben wir als ersten Schritt die lokale Content DB deaktiviert.
"Global Escalation Team würde empfehlen sc_local_db auf 'none' zu setzen und drauf zu achten diese Einstellungen unter keinen Umständen auf 'mem' oder 'disk' zu stellen."

Für Debug Logging wird atop verwendet und läuft jetzt mit.

Auffällig bei den von mir geposteten TOP Werten war im Problemfall vor allem der WA Wert. Dieser ist bei einem Systemhänger für längere Zeit über der 90% Marke. Die CPU wartet also auf IO.
Cpu(s): 2.8%us, 1.2%sy, 0.0%ni, 0.0%id, 95.9%wa, 0.0%hi, 0.2%si, 0.0%st

Ich habe mal die IO Werte der beiden Partitionen mitgeloggt, die am intensivsten genutzt werden. Man sieht, dass hier permanent geschrieben wird (blau). Und zwar oft gleichzeitig und mit IO Werten von 200-300 IO/s. Das packt keine einzelne SATA HDD ohne Latenzen.
Der Support sagt allerdings: "Seitens der berichteten Disk I/O konnte der Global Escalation Support derzeit kein Problem auf der UTM feststellen."

Hallo,
wir haben mit unseren beiden ASG320's (aktuellste FW) das selbe Phänomen das Stelektro beschreibt.
Teilweise fängt sich das System wieder und arbeitet weiter als wäre nichts gewesen.
Andernfalls schalten wir die jeweils aktive Kiste aus womit der Slave dann die Arbeit übernimmt.
Es ist scheinbar ein Problem, welches mit der Auslastung zusammenhängt. Über Weihnachten/Neujahr gab es diese Hänger nicht. Seit die Urlaubszeit vorbei ist tritt das Problem wieder häufiger auf (teilweise 2x am Tag).
Haben heute testweise den Transparenten Proxy für unser Gäste-Wlan deaktiviert, da hier im Forum zu lesen war, dass dieser viel Leistung benötigt.

Zudem würde ich gern wissen was der Wert sc_local_db none genau bewirken soll.
Hat das geholfen?

Gruß
jauer

Hatten heute wieder zwei dieser Aussetzer. Hat sich aber in beiden Fällen wieder gefangen. Das deaktivieren des transparenten Proxys hat demnach nicht geholfen.
Ohne die Performance der HDD slebst gemonitort zu haben würde das Verhalten aber ja die Beobachtungen von Stelektro bestätigen.
Der Wert sc_local_db none scheint ja schon seit längerem per Default so gesetzt zu sein. Habe das auf unserer ASG überprüft.

Man sollte wohl der Ursache nachgehen, weshalb zu unterschiedlichen Zeitpunkten sich die Schreib-/Leserate auf die HDD so erhöht.

Bei uns laufen die Kisten wieder mit einer normalen Performance, seitdem die Content DB nicht mehr lokal geladen wird. Der Case ist auch inzwischen geschlossen. Ich würde mir wünschen, dass man die HDD gegen eine SSD tauschen könnte, dann wäre vor allem die gefühlte Reaktionszeit viel schneller. Leider ist dies aufgrund der strikten Hardwarepolicy des Astaro Installers nicht möglich. Dieser prüft leider auch die Festplatte mit einer Kompatibilitätsliste ab.
Die Schreibzugriffe finden permanent durch Logging und Caching des Webproxies statt. Lesezugriffe stellte ich kaum fest. Verstärkt und mit starken Latenzen traten die Schreibzugriffe bei den Avira/Clam Updates auf. Aber nicht nur zu diesen Zeiten. Öfters konnte ich den Grund dafür nicht erkennen. Allerdings legen Einträge im http proxy log nahe, dass das vorallem beim Update der lokalen Content DB passierte ((nil)" function="sc_check_servers"). Diese Hänger waren immer besonders heftig und lange.

Wie man sc_local_db ein- bzw umstellt:

1) enable SSH for both loginuser && root in WebAdmin > System Settings > Shell Access
2) ssh to ASG and login with loginuser
3) su root
4) cc set http sc_local_db none
5) /var/mdw/scripts/httpproxy restart

Optionen für sc_local_db:

use disk / mem / none to choose between disk, memory or no local database.

Just for Info: Ich habe ein "bissl rumprobieret" ... Zuerst habe ich die UTM (220) auf eine hardwareausstattungähnliches System migriert und dort ähnliche Erfahrungen, aber mit bedeutend weniger Auswirkungen, machen müssen. Interessant war ja immer, dass es keinen bestehenden Verbindungen betraf (SSH, Videostream etc.).

Beide Plattformen in das Monitoring der lokalen Gegebenheiten (CPU, I/O, RAM etc.) aufgenommen und im 5 Sekundentakt abgefragt. Die hwä Platttform kam bedeutend besser mit klar. Nachdem ich der hwä Plattform den RAM verdoppelt habe, waren gar keine Performanceengpässe mehr vorhanden. Das gleiche habe ich mit der UTM gemacht - passt. Die Welt ist wieder in Ordnung ...

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.