26.02.2022, aktualisiert um 10:23:26 Uhr

4816

Server extrem langsam bis zum Stillstand

Hallo ihr alle,

ich verwalte einen von einem großen Provider gemieteten dedicated Server unter Ubuntu 18.04.6 LTS (GNU/Linux 4.15.0-135-generic x86_64). Er lief viele Monate problemlos und ohne Unterbrechungen.

Plötzlich gab es in zwei aufeinanderfolgenden Nächten große Probleme. Der Server antwortete extrem langsam und beim zweiten Mal gar nicht mehr, wobei auf ein PING weiterhin reagiert wurde.

Beim ersten Mal führte ich die vom Provider empfohlene "kurze" Untersuchung auf Hardwarefehler über eine externe Konsole durch. Dies ergab nach mehreren Stunden ein negatives Ergebnis und nach einem Hard-Reboot funktionierte der Server wie gewohnt.

In der nächsten Nacht wiederholte sich das Ereignis. Diesmal führte ich sofort einen erfolgreichen Hard-Reboot aus.

In der darauffolgenden Nacht gab es kein besonderes Ereignis.

In der Datei "kern.log" findet sich für den entsprechenden Zeitraum eine Fülle von sich wiederholenden Einträgen. Ich habe sie unten angehängt. Liegt doch ein Hardwarefehler vor oder gibt es eine andere Ursache? Ich kann auch eine "lange" Untersuchung auf Hardwarefehler durchführen. Allerdings fällt dann der Server möglicherweise für einen halben Tag aus.

Was meint ihr?

Gruß
Ralph

Feb 25 03:05:27 kernel: [46602.660633] Hardware name: Supermicro Super Server/X11SSL-F, BIOS 2.0c 10/06/2017
Feb 25 03:05:27 kernel: [46602.660635] Call Trace:
Feb 25 03:05:27 kernel: [46602.660643] dump_stack+0x6d/0x8e
Feb 25 03:05:27 kernel: [46602.660650] warn_alloc+0xff/0x1a0
Feb 25 03:05:27 kernel: [46602.660661] __alloc_pages_slowpath+0xdc5/0xe00
Feb 25 03:05:27 kernel: [46602.660677] ? ___slab_alloc+0x34d/0x4f0
Feb 25 03:05:27 kernel: [46602.660688] __alloc_pages_nodemask+0x29a/0x2c0
Feb 25 03:05:27 kernel: [46602.660700] alloc_pages_current+0x6a/0xe0
Feb 25 03:05:27 kernel: [46602.660713] sa_cache_save+0x479/0x520 [snapapi26]
Feb 25 03:05:27 kernel: [46602.660728] pending_req_handler_thread+0x29d/0x3a0 [snapapi26]
Feb 25 03:05:27 kernel: [46602.660738] kthread+0x121/0x140
Feb 25 03:05:27 kernel: [46602.660753] ? snapapi_make_request+0x210/0x210 [snapapi26]
Feb 25 03:05:27 kernel: [46602.660768] ? kthread_create_worker_on_cpu+0x70/0x70
Feb 25 03:05:27 kernel: [46602.660778] ret_from_fork+0x35/0x40
Feb 25 03:05:27 kernel: [46602.660795] snapapi_prht: page allocation failure: order:0, mode:0xc2(__GFP_HIGHMEM|__GFP_IO|__GFP_FS), nodemask=(null)
Feb 25 03:05:27 kernel: [46602.660797] snapapi_prht cpuset=/ mems_allowed=0
Feb 25 03:05:27 kernel: [46602.660805] CPU: 7 PID: 21501 Comm: snapapi_prht Tainted: G OE 4.15.0-135-generic #139-Ubuntu

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

Content-ID: 2009189073

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

Ausgedruckt am: 22.11.2024 um 05:11 Uhr

16 Kommentare

Neuester Kommentar

Moin,

Hmm… zum Log kann ich nicht viel sagen, würde mich aber nicht nur auf Hardwarefehler fokussieren.

Denkbar wäre es, das zwei nicht gewollte Prozesse deine Maschine massivst ausgelastet haben?
Gab es massive Versuche von Extern, die Maschine zu attackieren (DoS)?
Gibt es geplante Aktivitäten, die in diesen beiden Nächten „aus dem Ruder“ liefen? Datensicherung? ETL-Prozesse? …

Wenn es doch Hardwarefehler sind und du die Koste gemietet hast: kann dich der Provider unterstützen? Im gehört die Kiste ja immerhin…

Edit :

page allocation failure: order:0

danach würde ich mal schauen. Liest sich (im WWW), als wenn dir der RAM ausgeht und es ggf. Probleme beim Swappen gibt.

Gruß
em-pie

Moin,

ich würde zunächst mal ein BIOS-Update für das Mainboard vorschlagen. Das laufende BIOS 2.0c ist von 2017 und hat die diversen Microcode-Updates noch nicht. aktuell wäre BIOS 2.6 aus 2021. Vgl. https://www.supermicro.com/Bios/softfiles/14093/X11SSL(-F)_X11SSM_BIOS_2 ...

Weiterhin lässt der Auszug aus dem kern.log auf ein installiertes Kernelmodul von Acronis True Image schließen (snapapi), eventuell benötigt dies auch mal ein Update oder verursacht das Problem.

Gruß

cykes

Feb 25 03:05:27 kernel: [46602.660795] snapapi_prht: page allocation failure: order:0, mode:0xc2(__GFP_HIGHMEM|__GFP_IO|__GFP_FS), nodemask=(null)

Sieht mir danach aus als wäre der Hauptspeicher vollgelaufen, wenn der Prozess keine Pages mehr alloziieren kann dann wird sehr wahrscheinlich die RAM Auslastung durch einen Prozess auf der Kiste aus dem Ruder laufen. Das würde auch das anfängliche Zähe reagieren erklären. Lass dir die Speicherauslastung der jeweiligen Prozesse mal kontinuierlich in ein Log schreiben.
Z.B. die Ausgabe von

ps -eo pmem,pcpu,vsize,pid,cmd | sort -k 1 -nr | head -n 5

Zitat von @cykes:

Moin,

ich würde zunächst mal ein BIOS-Update für das Mainboard vorschlagen. Das laufende BIOS 2.0c ist von 2017 und hat die diversen Microcode-Updates noch nicht. aktuell wäre BIOS 2.6 aus 2021. Vgl. https://www.supermicro.com/Bios/softfiles/14093/X11SSL(-F)_X11SSM_BIOS_2 ...

Weiterhin lässt der Auszug aus dem kern.log auf ein installiertes Kernelmodul von Acronis True Image schließen (snapapi), eventuell benötigt dies auch mal ein Update oder verursacht das Problem.

Gruß

cykes

Vielen Dank für den Hinweis auf Acronis. Um 02:30 startet tatsächlich eine solche Datensicherung und zusammen mit dem Agenten wurde auf dem Server sicherlich auch ein solches Kernel-Modul installiert.

Ich habe unter diesem Aspekt soeben an den Provider geschrieben. Mal sehen, ob dort auch ein Zusammenhang gesehen wird.

Gruß
Ralph

Zitat von @1915348599:

Feb 25 03:05:27 kernel: [46602.660795] snapapi_prht: page allocation failure: order:0, mode:0xc2(__GFP_HIGHMEM|__GFP_IO|__GFP_FS), nodemask=(null)

ps -eo pmem,pcpu,vsize,pid,cmd | sort -k 1 -nr | head -n 5

Ein Monitoring lief mit. Ist mir eben erst eingefallen, sorry. Aber wesentlich Neues ergibt sich dadurch auch nicht.

In dem entsprechenden Zeitraum war sowohl der Arbeitsspeicher als auch die CPU voll ausgelastet. Allerdings konnte ich nicht erkennen, durch welchen Prozess. Der Prozess mit dem höchsten Anteil war "service_process-bin", was auch immer das sein mag. In der Statistik zu den Prozessen war aber keine signifikante Abweichung zu den anderen Nächten zu entdecken.

Es weist immer mehr auf ein Problem mit der Acronis-Sicherung hin. Mal sehen, was der Provider antwortet.

Nach allem, was ich bisher mitbekommen habe, werden an aktiven Servern keinerlei Reparaturen durchgeführt. Stattdessen werden die Server komplett ausgetauscht. Gegen eine Kostenbeteiligung wird der Massenspeicher in den neuen Server eingebaut. Ist das nicht möglich, weil er defekt ist oder wünscht der Kunde das nicht, muss er auf dem neuen Server seine eigene Datensicherung einspielen.

Aber ich werde trotzdem auf das veraltete BIOS hinweisen. Und Acronis ist, wie ich an anderer Stelle schon geschrieben habe, ein heißer Kandidat als Problemverursacher.

Gruß
Ralph

Hallo,
hast Du ein Monitoring für den Server?
Meist kann man zu dem Zeitpunkt daraus Informationen ablesen.
CPU/RAM/Storage-Auslastung und -Verzögerung.

Wenn nicht, anschaffen

Stefan

Bei bestimmten Intel-Netzwerkkarten z.B. den x520 gab es im Treiber ein Memory-Leak. Da lief dann einfach der Hauptspeicher voll bis zum absoluten Stillstand des Systems. Wie lange das dauert, war von den übertragenen Datenmengen über die Netzwerkkarten abhängig.

Hatte ich bei diversen Xen-Servern und konnte die Ursache zunächst auch nicht ausfindig machen.

Ein schnelles, kleines monitoring könntest du auch selbst auf dem Server etablieren, zB mit

atop

Im Prinzip ein etwas erweitertes "top" - hierin werden in festgelegten Intervallen div. System-Parameter überwacht, übersichtlich dargestellt und auch (farblich hervorgehoben) ggf. auf "bottlenecks" hingewiesen.

Du kannst - in der entspr. Config - die folgenden Parameter anpassen:

LOGINTERVAL
LOGPATH

um so zB nicht alle 10 Min (default), sondern alle 10 Sek. eine Darstellung abzuspeichern, die du dir im Nachhinein bequem anschauen kannst:

atop -r /path/to/atop_logfile -b HH:MM

-> ab dem angegebenen timestamp kannst du dann mit "t" (next sample) bzw. "T" (previous sample) die einzelnen Momentaufnahmen durchgehen, bis du ggf. etwas Auffälliges findest.

Hallo ihr alle!

Herzlichen Dank für die vielen freundlichen und nützlichen Antworten.

Dadurch bin ich darauf gebracht worden, dass es am Kernelmodul der Acronis-Sicherung liegen könnte. Ich habe dies an den Support des Providers geschrieben. Wenn es eine substantielle Antwort gibt, melde ich mich hier wieder.

Gruß
Ralph

Hello,

Did you manage to get this issue solved ?

I've got the same issue and the server also has Acronis Backup installed.

Hallo nokoya,

ich bin eben meine Mails durchgegangen. Leider finde ich nach der Antwort, dass ein Ticket erstellt wurde und dass sich die Fachabteilung bei mir melden würde, keine weiteren Mails zu diesem Problem. Ich habe dann auch nicht mehr daran gedacht, zum einen, weil es sich nicht wiederholt hat, zum anderen aber auch, weil inzwischen ein anderes reproduzierbares Problem aufgetaucht war, das die Aufmerksamkeit auf sich gezogen hat.

Zwischendurch hieß es einmal, ich sollte den Agenten aktualisieren. Er war aber schon aktuell. Aber vielleicht hilft das bei dir?

Gruß
Ralph

Hallo ihr alle,

es gibt Neuigkeiten zu diesem Thema.

Derselbe Effekt (Server extrem langsam bis zum Stillstand) ist bei der nächtlichen Sicherung eines anderen Server mehrfach aufgetreten.

Erstaunlicherweise lief die Sicherung problemlos ab, wenn ich sie tagsüber angestoßen habe. Daraufhin habe ich den Zeitpunkt der nächtlichen Sicherung etwas verschoben und seitdem gibt es keine Fehler mehr. Mein Provider meint, dass eventuell zu der problematischen Zeit eine Indizierung gemounteter Dateisysteme stattfinden könnte. Denn die Fehlerprotokolle enthielten Hinweise auf Probleme beim Mounten von Dateisystemen über SMB.

Was meint ihr dazu?

Merkwürdig ist auch, dass jetzt noch, obwohl die Sicherung schon lange vorbei ist, nach "df" das Folgende (Auszug) angezeigt wird:

/dev/loop1 56960 56960 0 100% /snap/core18/2409
/dev/loop2 63488 63488 0 100% /snap/core20/1494
/dev/loop4 69504 69504 0 100% /snap/lxd/22753
/dev/loop3 63488 63488 0 100% /snap/core20/1518
/dev/loop5 69632 69632 0 100% /snap/lxd/22526
/dev/loop6 48128 48128 0 100% /snap/snapd/16010
/dev/loop7 48128 48128 0 100% /snap/snapd/16292
//SMB3.xxx.yyy.COM/root 2428752529 367 2428752162 1% /run/.mnt_net_smb_72AD374A-4550-4FC9-BBED-7D4C82BA5CCA
/dev/loop8 56960 56960 0 100% /snap/core18/2538

Was meint ihr dazu? Ist das noch normal? Bei einem anderen Server, der auch mit Acronis gesichert wird, gibt es diese Anzeige nicht außerhalb der Sicherungszeiten.

Gruß
Ralph

Hi,

die ganzen loop-devices benötigt er für den Snapshot des Servers vor der effektiven Sicherung.
Dass die nach der Sicherung aber nicht mehr freigegeben werden spricht wiederum für einen Fehler im Acronis.

Gruß

cykes

Hello raba34,

Same like mine, I've total 6 server backup with acronis. Just one of them having this issue. Asking Acronis but no solutions until now because the issue was hard to reproduce. Maybe we should try referer Acronis support to this thread to help us fix the issue.