Mysql-Prozess der Keymachine wird automatisiert gekillt

[Tobi]

DDOS? Hmmm… Ich weiß ja nicht…
Aber wenn einer unserer Server angegriffen wird, dann sind das bestenfalls Minuten bevor der Alarm losgeht.

In den Grafiken erkennt man aber m. E. n., dass sich die Last über mehrere Tage aufbaut bis der Server schließlich hängenbleibt. Das deutet für mich eher auf nicht ordnungsgemäß beendete MySql Verbindungen hin.

[blickgerecht]

DDOS? Hmmm… Ich weiß ja nicht…
Aber wenn einer unserer Server angegriffen wird, dann sind das bestenfalls Minuten bevor der Alarm losgeht.

Stimmt, da hast du Recht! Der Kill der Datenbank hatte mich nur daran erinnert. Dachte, die Erfahrungen helfen vielleicht.

[blaue_mango]

Guten Morgen,

wir überwachen den Status mittlerweile über API und können so immer vorsorglich reagieren.

Hier ist noch ein Screenshot der Auslastung über einen längeren Zeitraum.

Kann es vielleicht mit dem Virenscanner oder der Backup-Verwaltung zusammenhängen?
(Backup ist wöchentlich am Wochenende auf eine KeyDisc; Virenscanner ist Standardeinstellung)

Schöne Grüße

[tab-kh]

Virenscanner Standardeinstellung ist ja Montags zwischen 1 und 2 Uhr. Der Virenscanner kann schon einiges an RAM fressen. Wenn der läuft, dann ist das RAM auf einem Server, der eh schon reichlich RAM nutzt und mit dem Swap kurz vor dem Limit liegt natürlich besonders knapp.

Ich schätze also mal, dass es deswegen dann oft um genau diese Zeit kracht. Der Datenbankserver hat sich schon eine Menge RAM gekrallt, dann startet der Virenscanner und will auch RAM, je nachdem wie große Dateien er scannt, gerne auch größere Mengen davon. Dann reicht es eben nicht mehr und der OOM-Killer muss eingreifen. Eine wirklich gute Lösung wird er dann auch nicht finden können. Killt er den Datenbankserver, geht nichts mehr. Killt er ClamAV, dann wird gar nie nach Viren gescannt.

Wünschenswert wäre m.E., den Datenbankserver nur soviel RAM nutzen zu lassen, dass noch Reserven für ClamAV vorhanden sind. Wenn der Datenbankserver nur noch einige wenige GB RAM übrig lässt und der Webserver auch noch RAM verbraucht, wird das RAM bei laufenden ClamAV relativ schnell nicht mehr ausreichen. Eventuell hilft https://mariadb.com/docs/server/ha-and- ... allocation

Und/oder, falls es so eine Zeitspanne überhaupt gibt, den ClamAV zu einer Zeit laufen zu lassen, wo ansonsten nicht so viel los ist. Alternativ wäre natürlich auch mehr RAM eine Möglichkeit , die aber natürlich die Kosten erhöht. Dann darf der Datenbankserver entsprechend mehr RAM verbrauchen.

Bei Standardeinstellung für vm.swappiness könnte es eventuell auch dazu kommen, dass insbesondere während des Backups relativ viele Dateien ins RAM geladen sind. Dieses RAM kann zwar prinzipiell relativ "billig" und schnell wieder freigegeben werden, aber eventuell nicht schnell genug, wenn bei bereits ausgelastetem RAM plötzlich noch der ClamAV mal eben ein paar GB haben will.

[24unix]

Code: Select all

Wünschenswert wäre m.E., den Datenbankserver nur soviel RAM nutzen zu lassen, dass noch Reserven für ClamAV vorhanden sind

Essentielle Dienste für nonsense beschränken?

Warum deaktivierst Du den nicht einfach?

Das ist wie SPAM-Filterung, das gehört auf den Client. Und es gibt eh nur ein OS, das mit Viren Probleme hat.

Wenn Du dich mit dem Schlangenöl sicherer fühlst, erhöhe doch einfach den Swap.

[tab-kh]

Wir reden hier aber nicht von Mail, sondern vom wöchentlichen Komplettscan. Insofern ist mir das mit dem "Client" nicht ganz klar. Sicher, ClamAV findet sowieso kaum was außer ein paar false positives, jedenfalls bei mir. Bei mir hat er in Jahren keine tatsächliche Malware gefunden, insofern könnte ich ihn auch weglassen. Inwieweit man ihn mit Kunden auf dem Server dann lieber doch haben will, das bleibt jedem Admin selbst überlassen.
Wenn ClamAv dann aber doch laufen soll, dann bleibe ich bei dem was ich geschrieben habe. Wenn man da nur den Swap erhöht, wird sich der Spassfaktor mit dem Server wohl kaum verbessern. Was soll denn noch mehr rausgeswappt werden (mehr als 4 GB wie bisher) ohne dass die Kiste praktisch steht?

[24unix]

Sicher, ClamAV findet sowieso kaum was außer ein paar false positives, jedenfalls bei mir.

Eben.
Überall aus, ausser bei der Kiste mit 32GB RAM.

Wenn man da nur den Swap erhöht, wird sich der Spassfaktor mit dem Server wohl kaum verbessern. Was soll denn noch mehr rausgeswappt werden (mehr als 4 GB wie bisher) ohne dass die Kiste praktisch steht?

Wie viel RAM hat die Kiste denn?

[tab-kh]

AUf einem der Screenshots werden knapp 15 GB angezeigt. Der Datenbankserver schnappt sich den Löwenanteil im Lauf der Zeit und lässt dann noch vielleicht 4-5 GB übrig für Apache PHP/FPM . Dann kommt irgendwann ClamAV und er ist tot. Also der Server hat schon RAM. Aber wieviele Kunden da drauf sind und was sie so alles laufen lassen weiss ich nicht.

[24unix]

Ach, das war ja gar nicht Dein Thread, darum hatte ich den Screenshot nicht angesehen, sorry.

Bei ~15GB RAM kann man locker 8 GB Swap nutzen.

[tab-kh]

Klar, kann man- Aber was soll da rausgeswappt weden? Die ca 9-10 GB Puffer von MariaDB eher nicht, sonst wäre man wohl besser dran, wenn man MariaDB das RAM limitiert. Typischerweise weiss so ein Datenbankserver besser mit ihm von vornherein bekannten Limits umzugehen als damit, dass das OS ihm ohne Vorankündigung plötzlich seine Puffer rausswappt oder ihn gar killt, weil ClamAV zusätzlich gestartet wurde und RAM braucht, was nicht zur Verfügung steht.

Deswegen würde ich eben schauen, dass MariaDB entweder durch entsprechende Einstellungen etwas weniger RAM verwendet - oder eben gleich ein System mit mehr RAM benutzen. Oder eben auf ClamAV verzichten. Auf meinem Server - ohne Kunden (außer mir) - würde ich vielleicht auch mal zram ausprobieren. Aber mit zahlenden Kunden auf dem Server würde ich persönlich eher keine solchen Experimente machen wollen.