Mysql-Prozess der Keymachine wird automatisiert gekillt

[blaue_mango]

---------------------------------------------------------------------------

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
Vermutlich


Server-Betriebssystem + Version
Ubuntu 22.04 (64-bit)


Eingesetzte Server-Virtualisierung-Technologie
KVM


KeyHelp-Version + Build-Nummer
25.2 (Build 3483)


Problembeschreibung / Fehlermeldungen
- Der Mysql-Prozess wird automatisch gekillt
- Dadurch ist komplett Keyhelp inkl. aller Benutzer nicht mehr erreichbar.
- Nach einem Neustart ist es wieder in Ordnung

connection refused keymachine 2025-09-25 154105.png (19.76 KiB) Viewed 923 times

Erwartetes Ergebnis
- Server läuft stabil

Tatsächliches Ergebnis
- Server ist ohne ersichtliches Eingreifen unsererseits in unregelmäßigen Abständen nicht mehr verfügbar.

Schritte zur Reproduktion
- nicht bekannt

Zusätzliche Informationen

Bereits probiert:
- In der Benutzerverwaltung den Memory Limit der Nutzer herabsetzen
- In der Benutzerverwaltung unter PHP-FPM die pm.max_children erhöhen (z.B. von 3 auf 8)
- /etc/mysql/mariadb.conf.d (das hat ChatGPT vorgeschlagen und es klang plausibel):
-> innodb_buffer_pool_size = 4G
-> max_connections = 75
-> table_open_cache = 512
-> query_cache_size = 64M

- Der Swap-Speicher ist regelmäßig im roten Bereich.
Nach einem Neustart ist es dann wieder "normal":

---

Hallo,

wir brauchen bitte Unterstützung.

Es ist jetzt schon mehrfach vorgekommen, dass der Mysql-Server auf unserer Keymachine nicht mehr erreichbar ist und dadurch die komplette Keymachine inklusive aller darauf befindlichen Dienste nicht mehr funktioniert.

In einem Ticket wurde bereits geantwortet, dass aus den Logs wohl ersichtlich sei, dass der mysql-Prozess gekillt wird, weil er Out of Memory ist.

Was kann ich noch bereitstellen, damit wir eine Lösung finden?

Wie können wir herausfinden, was der Übeltäter ist?

Danke euch

Grüße

[Florian]

Hallo,

die Prozesse werden auf Basis Ihres OOM-Scores getötet.

Code: Select all

cat /proc/$PID/oom_score

Je höher der Wert, um so höher die Wahrscheinlichkeit, dass er getötet wird. Man kann das Anpassen, zumindest während der Laufzeit des Servers, aber das löst natürlich das grundlegende Problem nicht.

Tritt das Phänomen dann immer zeitlich gleichmäßig auf, z.B nachts oder so?

[Florian]

PS: Als Keyweb-Kunde kann man auch ein Ticket machen, nur als Hinweis

[blaue_mango]

Hallo,

...
Tritt das Phänomen dann immer zeitlich gleichmäßig auf, z.B nachts oder so?

Können wir das im Nachhinein noch zuverlässig nachvollziehen?
Und wäre das hilfreich?
Wenn der SQL-Prozess gekillt wird, müssen wir ja über das KCP gehen oder Proxmox, um neu zu starten.


Hier noch ein Screenshot des Monitorings.
Der Knick ist der Neustart.

[Florian]

Hallo,

im Nachhinein ist das schwer, daher fragte ich ob das immer zur selben Zeit eintritt. Dann kann man das beobachten.

Wieso über Proxmox? Wenn nur der MariaDB gekillt wird ist doch SSH noch erreichbar und man startet den MariaDB darüber neu.

[blaue_mango]

Hallo,

im Nachhinein ist das schwer, daher fragte ich ob das immer zur selben Zeit eintritt. Dann kann man das beobachten.

Wieso über Proxmox? Wenn nur der MariaDB gekillt wird ist doch SSH noch erreichbar und man startet den MariaDB darüber neu.

Danke für deine Rückfrage. Das hat den Hintergrund, dass so auch SSH-unerfahrene den Server im Notfall neu starten können.

Hier ist noch ein Screenshot der Datenbank-Statusseite.

Kann man darauf eventuell was unauffälliges erkennen?

Schöne Grüße

[Florian]

Hallo,

nein da ist nichts ungewöhnliches.

Wie sieht es denn zeitlich aus? Tritt das immer zur selben Zeit auf?

[tab-kh]

Einerseits wird gesagt, dass der MySQL-Prozess automatisch gekillt wird, anderseits ist die Datenbank-Speicherauslastung danach immer noch über 8 GiB Speicher?
Das verstehe ich nicht so ganz. Ich würde eigentlich erwarten, dass nachdem der OOM-Killer zugeschlagen hat sich diese Auslastung zügig gegen 0 bewegt oder zumindest kurz auf das Niveau nach einem Neustart, oder liege ich da falsch?

Anhand des Zeitausschnitts des Monitoring würde ich davon ausgehen, dass der MySQL-Prozess am ehesten so um die 17 Uhr gekillt werden müsste, wenn er denn gekillt wird. Bis dahin steigt die Speicherauslastung noch, danach ist sie fast konstant bis zum Neustart des Servers. Woher wisst ihr denn dass der MySQL-Prozess automatisch gekillt wurde, wenn ihr die Kiste einfach neustartet wenn nichts mehr zu gehen scheint? Aus den Logs eher nicht, sonst wüsstet ihr ja auch, wann es passiert ist und könntet auf einfache Weise auch alle Zeitpunkte des Auftretens zu früheren Zeitpunkten finden.

Vielleicht läuft er ja noch und kann nur wegen Speichermangel nicht mehr vernünftg arbeiten. Also ich würde da definitiv erst mal per SSH reinschauen bevor der Server neu gestartet wird. Dann sieht man ob der MySQL-Prozess läuft und wieviel Speicher er ggf. benutzt.

Man sollte die Aktionen des OOM-Killers aber auch im Journal finden können, wenn er denn tatsächlich zuschlägt.

[blaue_mango]

...
Woher wisst ihr denn dass der MySQL-Prozess automatisch gekillt wurde, wenn ihr die Kiste einfach neustartet wenn nichts mehr zu gehen scheint? Aus den Logs eher nicht, sonst wüsstet ihr ja auch, wann es passiert ist und könntet auf einfache Weise auch alle Zeitpunkte des Auftretens zu früheren Zeitpunkten finden.
...

Hallo, vielen Dank für deine Antwort.

Es stand so in den Logs drin:

Code: Select all

root@km1111-04:~# cat /var/log/syslog.1|grep memory
Mar 15 01:01:25 km1111-04 kernel: [18552299.388263] out_of_memory+0x106/0x2e0
Mar 15 01:01:25 km1111-04 kernel: [18552299.388442] Tasks state (memory values in pages):
Mar 15 01:01:25 km1111-04 kernel: [18552299.388865] Out of memory: Killed process 818 (mariadbd) total-vm:15462804kB, anon-rss:9533040kB, file-rss:0kB, shmem-rss:0kB, UID:112 pgtables:26276kB oom_score_adj:0

Hallo,

nein da ist nichts ungewöhnliches.

Wie sieht es denn zeitlich aus? Tritt das immer zur selben Zeit auf?

Der obige Log-Ausschnitt ist der einzige, den ich vom exakten Zeitpunkt habe.
Wenn das bei der Lösungssuche hilfreich ist, werde ich versuchen, das bei den nächsten Malen auch in Erfahrung zu bringen.


Folgende Info habe ich noch zusätzlich aus einem Ticket:

Am 22.06. gegen 02:07:50 Uhr wurde vor dem mysql service ein "keyhelp-php74-fpm" Prozess terminiert. Vermutlich hat dieser u.A. dazu geführt, dass der MySQL-Prozess terminiert wurde.
Der Server hatte schlichtweg einfach keine freien Ressourcen mehr.


Ich hänge ein paar Screenshots an aus welchen dies erkennbar ist.
Swap ist auch über den gesamten Zeitraum am Limit gewesen.

Kann man daraus irgendwelche Schlüsse ziehen oder die Ursache eingrenzen?

[Jolinar]

Kann man daraus irgendwelche Schlüsse ziehen oder die Ursache eingrenzen?

Meine Schlußfolgerung: Nach der Aussage des Supports gehen dir die verfügbaren Ressourcen (hier der RAM) aus. Ich vermute mal, daß irgendeine Anwendung auf deinem Server sehr viel DB-Leistung braucht.
Letztlich wird dir hier ein Hardwareupgrade helfen.
Zur Ursache: Hier sollte geprüft werden, warum die DB-Last so hoch ist...Es wäre zumindest möglich, daß da irgendwas nicht so läuft, wie es normalerweise laufen soll...

[Florian]

mysqltuner laufen lassen wäre auch ne Möglichkeit. Der warnt normal auch wenn die Einstellungen einen zu hohen Speicherverbrauch verursachen können

[blaue_mango]

Kann man daraus irgendwelche Schlüsse ziehen oder die Ursache eingrenzen?

Meine Schlußfolgerung: Nach der Aussage des Supports gehen dir die verfügbaren Ressourcen (hier der RAM) aus. Ich vermute mal, daß irgendeine Anwendung auf deinem Server sehr viel DB-Leistung braucht.
Letztlich wird dir hier ein Hardwareupgrade helfen.
Zur Ursache: Hier sollte geprüft werden, warum die DB-Last so hoch ist...Es wäre zumindest möglich, daß da irgendwas nicht so läuft, wie es normalerweise laufen soll...

Gibt es eine Möglichkeit, herauszufinden, was die hohe DB-Last verursachen könnte?

Beziehungsweise überhaupt herauszufinden, ob ein Benutzer und wenn ja, welcher dafür verantwortlich ist?

Danke für eure Antworten bisher!

[Jolinar]

Gibt es eine Möglichkeit, herauszufinden, was die hohe DB-Last verursachen könnte?

siehe hier->
viewtopic.php?p=56119#p56119

[Tobi]

Ich würde zusätzlich mal das slow_query_log aktivieren.
https://mariadb.com/docs/server/server- ... g-overview

[blickgerecht]

Gibt es eine Möglichkeit, herauszufinden, was die hohe DB-Last verursachen könnte?
Beziehungsweise überhaupt herauszufinden, ob ein Benutzer und wenn ja, welcher dafür verantwortlich ist?

Für uns war das auch ein übliches Muster für Angriffe (DDoS) auf Websites. Vor dem "Schärfen" von fail2ban war es dann auch immer die Datenbank, die ausgestiegen ist.

Bei Wordpress reichen da bspw. schon viele (absichtliche) 404-Aufrufe, da die immer über Wordpress via PHP und Datenbankabfrage verarbeitet werden.

Wir haben dann am Anfang per Hand und mit Skripten mal die Apache-Logs durchgesehen. Stoppte man die Anfragen nicht (per fail2ban) waren es auch oft die gleichen IPs. Da kann man dann recht schnell sehen, wo ein großes Aufkommen war (Benutzer aus Pfad bspw.). Die Analyse hat uns dann auch geholfen, das anzupassen, für den gesamten Server.

Hier findest du die Logs:

Code: Select all

/home/users/*/logs/*/access.log