task apache2 blocked for more than xyz seconds

[vdm]

Hallo zusammen,

auf einem von mehreren webservern bekomme ich diese Fehlermeldung: task apache2 blocked for more than 120 seconds
Der Webserver war vorher ein Ubuntu Server und ist jetzt ein neu installiertes Debian 12.
Der Webserver war vorher auf der einen Node, jetzt auf einer anderen Node.
In den Optionen habe ich es auch ohne ACPI schon probiert und in der /etc/sysctl.conf habe ich schon mit
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
erfolglos probiert.
Das Filesystem der VM habe ich ebenfalls geprüft und der zpool ist ebenfalls gesund.

Der Webserver betreibt eine Nextcloud und hat 2-4 CPUs (ausprobiert) und 4-8GB RAM.
Auf der Platte ist weit ausreichend Platz vorhanden.

Der Webserver hat eine NFS Anbindung auf einen Fileserver.
Es gibt einen weiteren Webserver mit Horde, der ebenfalls ein NFS auf denselben Fileserver hat.

Wenn der Fehler auftritt, geht der Apache Prozess kaputt und irgendwann geht auch kein sauberer Shutdown mehr und ein Reset muss gemacht werden. Dann gehts wieder ne Zeit lang.

Weitere Foreneinträge habe ich gefunden, es kann sein, dass dieser Fehler wegen einem Backup ausgelöst wird.
Auf den beiden Nodes laufen umgschaut 25 VMs und COntainer, diese eine Maschine hier, die treibt mich zum Wahnsinn und mir fällt auch nichts mehr dazu ein.

Kann mir bitte bitte jemand auf die Sprünge helfen, des gibts ja gar ned

Viele Grüße,
Andreas

 

[vdm]

Und das System ist aktuell, mit der PVE Version: 8.0.4 (running kernel: 6.2.16-18-pve)

 

[vdm]

Und als Backup Server läuft der Proxmox Backup Server, falls das relevant sein sollte. Backups laufen alle paar Stunden.
Etwa zu der Zeit geht der Webserver kaputt.
Der QEMU Gast Agent ist installiert und aktiv.

 

[vdm]

Und nach genauerem Schauen, es passiert immer während des Backups.
Obwohl dieser Server nicht mal im Backuplauf enthalten ist.
Was kann das denn sein?

 

[Falk R.]

Kann es sein, dass du während des Backups, hohe IO Delay Werte hast? Dann wären die Disks zum Zeitpunkt des Backups zu sehr ausgelastet.

 

[vdm]

Daran habe ich auch schon gedacht, ohne es mal anzuschauen. Einfach weil es sind 4 webserver, 3 davon apache, 2 davon haben die selbe config und nur dieser eine - trotz neuinstallation - stirbt mir immer weg.
Die AUslastung der Server ist, weil Familysystem, äußerst gering.

 

[vdm]

Meinst du es wäre zum Ausprobieren zielführend, würde man die Performance vom Backup etwas drosseln?
Und wenn das ginge, wo würde ich das einstellen?

 

[vdm]

Aber, es ging jetzt jahrelang - ohne jemals in irgendein Timeout zu laufen

 

[Falk R.]

eventuell mcht ja langsam eine Disk schlapp und hatdadurch höhere Latenzen. Im Enterprise Umfeld sehe ich soetwas öfters.

 

[vdm]

Das ist natürlich ein sehr guter Punkt. Habe mir mal mit smartctl den zfs pool vom PVE Server angeschaut.
Alle Platten PASSED ohne Hinweis.
Dann bin ich rüber zum PBS. Erste Platte PASSED ohne Hinweis, die zweite Platte sieht aber so aus:


root@pbs:~# smartctl -d ata -H -d auto /dev/sdb
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.2.16-19-pve] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Please note the following marginal Attributes:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
190 Airflow_Temperature_Cel 0x0022 052 035 040 Old_age Always In_the_past 48 (Min/Max 34/61 #1519)


Ist das schon ein Problem?

 

[vdm]

Aber wenn es in Zusammenhang mit der Platte im Backup Server steht, warum stirbet der Server dann, wenn ganz andere VMs backup'ed werden? Das hängt ja nicht zusammen, irgendwie. Glaube ich. Denn die Platten im Server sind ja fein.

 

[Falk R.]

Was sagen denn die SMART Werte deiner Disks im PVE?

 

[vdm]

Wenn du die Werte mit -a meinst, die Platten im Server sehen so aus:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0004   132   132   054    Old_age   Offline      -       96
  3 Spin_Up_Time            0x0007   192   192   024    Pre-fail  Always       -       358 (Average 487)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       22
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000a   100   100   067    Old_age   Always       -       0
  8 Seek_Time_Performance   0x0004   128   128   020    Old_age   Offline      -       18
  9 Power_On_Hours          0x0012   099   099   000    Old_age   Always       -       7342
 10 Spin_Retry_Count        0x0012   100   100   060    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       22
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       313
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       313
194 Temperature_Celsius     0x0002   171   171   000    Old_age   Always       -       35 (Min/Max 25/60)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):

Und beim Test sagen sie PASSED

 

[Falk R.]

Das kann man ja gar nicht lesen, zumindest auf dem Smartphone. Pack sowas bitte in Code (oben anklicken)

 

[vdm]

Danke, bearbeitet. So sieht es viel besser aus.

 

[Falk R.]

Danke, bearbeitet. So sieht es viel besser aus.

Bei mir irgendwie nicht.

 

[vdm]

Jetzt

 

[Falk R.]

Ja, viel besser. Fehler hast du da keine drauf. Hattest du schon geschaut, ob du während des Backups IO Delay angezeigt bekommst?

 

[vdm]

Also das I/O Delay liegt zumeist bei unter 70%, manchmal sehe ich dass es kurz auf 100% steigt, doch das ist seit Jahren so und auch nur immer sehr kurz als Peak. Ich habe auch bisher immer 100% Bandbreite genutzt.
Die Bandbreite für das Backup habe ich seit gestern auf 100Mbit gestellt und der Fehler ist weiterhin da.

 

[Falk R.]

Ein so hohes IO Delay ist eindeutig zu viel.
Ab 5% gehe ich schon auf suche.