Debian 10: Arbeitsspeicher läuft langsam voll

Hi,

seit meiner Neuinstallation von Debian 10 auf eine neue SSD habe ich das Problem, dass mein RAM langsam aber sicher vollläuft. Das geht dann soweit, dass er dann via SSH nicht mehr erreichbar ist und auch die Konsole nur noch sehr verzögert auf Eingaben reagiert. Anmelden kann dann gerne mal 10 Sekunden dauern. Begrüßt werde ich dann dort mit einer entsprechenden Zeile:
https://plumbr.io/blog/memory-leaks/out-of-memory-kill-process-or-sacrif ... - bei mir ist's immer MySQL - allerdings wird es dadurch auch nicht besser, nach meinem Verständnis hat er den Prozess dann schon gekillt oder er scheitert daran.

Auf dem Server läuft:
- Routing (Transfernetz zur FRITZ!Box)
- OpenVPN-Server und -Clients für Standortverbindungen und Remotezugriff
- Nextcloud + MariaDB
- Dnsmasq
- FreeRADIUS

Ich bin jetzt schon hingegangen und habe o.g. Dienste mal beendet und geschaut was passiert - leider wächst die Auslastung weiter.

Im HTOP sehe ich nur eine hohe Auslastung oben, aber keinen Prozess mit einer hohen Auslastung. TMPFSs habe ich einige, auch hier ist via df -h aber alles mit wenigen MB belegt. Gleichen Aufbau hatte ich unter Deb 9 auch.

Ansätze, wie ich das Problem weiter eingrenzen oder gar beheben kann? Meiner Meinung bleibt nur die SSD oder irgendwas "systemiges" von Debian 10 in Frage..
Sofern wichtig: SSD ist eine 60GB von KingDian

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 482567

Url: https://administrator.de/contentid/482567

Ausgedruckt am: 23.11.2024 um 09:11 Uhr

9 Kommentare

Neuester Kommentar

Moin,

Daß RAm unter linux bis zum "Anschlag" genutzt wird, ist normal. Alles was nciht durch Prozesse benötigt wird, wird als cache genutzt, sofern es benötige wird. Bei mir z.B.

~$ free
                           Gesamt      belegt        frei      gemns.   Puffer/Cache   verfügbar
Speicher:                32927960     7521028      973472      223328       24433460    23899676
Auslagerungsspeicher:    33538044     1254836    32283208

Wie sieht denn "free" bei Dir aus?

Nach dem load zu urteilen tut sich bei Dir eigentlich nicht viel. Und 4GB sind halt nicht mehr "zeitgemäß". Die sind halt sehr schnell durch cache und Puffer aufgebraucht.

lks

Hallo 01Bear,

grundsätzlich seh ich das anders als @Lochkartenstanzer, 4GB sollten für die Anwendung (solange keine nnn User) locker reichen und selbst wenn sollte dass das System nicht so aufblähen, dass du dich nichtmal mehr einloggen kannst. Da ist anderes im argen. Daher, schonmal auf Schadsoftware oder Miskonfiguration gecheckt? (MariaDB auf 200% des nutzbaren Rams o-ä?)

Viele Grüße,

Christian
certifiedit.net

Innerhalb welcher Zeit kannst Du Dich nicht mehr einloggen? Sind die VPN Clients dann noch online?

Das geht dann soweit, dass er dann via SSH nicht mehr erreichbar ist und auch die Konsole nur noch sehr verzögert auf Eingaben reagiert.

"Swapped" er denn schon?

Dass der RAM von Linux selbst für Caching benutzt wird habe ich auch gelesen. Allerdings habe ich das so verstanden, dass dieser dann weiterhin unter free -h als available zu sehen ist - das ist bei mir nicht der Fall. Einen Screenshot von free kann ich gerade nicht erzeugen, da das System gerade neugestartet wurde.

Die 4GB haben vorher locker ausgereicht um via Virtualisierung sogar noch eine Windows-VM mit 2GB RAM laufen zu lassen, ohne dass es Probleme gab. Virtualisierung habe ich unter der Neuinstallation aber nicht mit installiert, eben nur die o.g. Programme.

Schadsoftware ist unwahrscheinlich, die wenigen Dinge, die installiert sind kommen vom Debian-Mirror bzw. von Nextcloud.com.
Sofern es eine Fehlkonfiguration von MySQL bzw. auch einem verwendeten PHP-Cache ist: Sollte dies doch aufhören, sofern der Dienst nicht gestartet ist oder gehe ich davon falsch aus? Grundsätzlich ist dies auf 1GB SQL-Cache gestellt, siehe my.cnf:
Habe ich entsprechend aus der Nextcloud-Installationsanleitung copypastet, sollte aber auch damals schon so ausgesehen haben.

[server]
skip-name-resolve
innodb_buffer_pool_size = 128M
innodb_buffer_pool_instances = 1
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 32M
innodb_max_dirty_pages_pct = 90
query_cache_type = 1
query_cache_limit = 2M
query_cache_min_res_unit = 2k
query_cache_size = 64M
tmp_table_size= 64M
max_heap_table_size= 64M
slow-query-log = 1
slow-query-log-file = /var/log/mysql/slow.log
long_query_time = 1

[client-server]
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

[client]
default-character-set = utf8mb4

[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_general_ci
transaction_isolation = READ-COMMITTED
binlog_format = ROW
innodb_large_prefix=on
innodb_file_format=barracuda
innodb_file_per_table=1
innodb_buffer_pool_size=1G
innodb_io_capacity=4000

VPNs sind dann nicht mehr online. Meine Vermutung ist, dass der OOM dann ans Werk geht, Dinge killt, welche großen Speicher brauchen, dieser dann aber wieder schnell vollläuft.

SWAP ist ein gutes Thema... <beichte>Habe ich bisher nie genutzt bzw. auch konfiguriert...</beichte>
Habe ich heute nachgezogen. Sofern das Problem beim nächsten Mal auftritt bzw. kurz davor ist: Welche Daten neben einem free -h wären hier für eine Diagnose noch hilfreich? Im htop kann ich den Übeltäter eben nicht erkennen, dmesg werde ich mir dann auch einmal anschauen und ggf. posten.

Mysterium scheint sich gerade gelöst zu haben:

Ich habe nun ALLE Dinge unter Generalverdacht gestellt und diese auch aus dem Autostart entfernt - da dort nichts kritisches läuft kein Problem.
Entsprechend dann mal alle 2 Stunden einen weiteren Dienst gestartet und geschaut ab welchem Punkt das dann mehr wurde...

Ironischerweise scheint es Systemd selbst zu sein, welches für mein Check_MK-Monitoring über Socket abgefragt wird - jedes Mal gibt es dann ca. 2-4MB mehr im RAM, welche dort auch bleiben. Ich habe alle Plugins für SMART und APT entfernt - Problem bleibt.

Beim direkten Starten des Agents auf dem System (als Skript) passiert dies nicht...
Ich habe nun erstmal auf die Alternative mit xinetd umgestellt. Wieso dies auftritt muss ich mir im Detail noch anschauen.

War systemd nicht mit Debian 10 sowieso abgesägt, oder verwechsel ich das? Ich meine sogar, dass cmk xinetd bevorzugt (vielleicht aus dem Grund?) - die Intuitive Miskonfigurationssache war wohl richtig?

Sofern installiert verwendet Check_MK xinetd - habe ich bisher aber nur auf Systemen, welche kein systemd haben, beispielsweise OpenWrt bzw. auch einige Alpine-Systeme.

Mein Ansatzfehler war (wie auch schon meistens) Problemquellen im Vorhinein auszuschließen. Merkwürdig finde ich trotzdem, dass er diese Menge RAM, die er sich ja nimmt nirgends zuordnet im htop. Oder suche ich da an falscher stelle / gibt es einen Flag zum anzeigen von System-internen Dingen? In der Manpage habe ich nichts dazu gefunden..