Hohe Load - finde den Grund einfach nicht.

[henfri]

Hallo,

mein Linux Server (Openmediavault) hat eine sehr hohe Load. Vor allem, seit ich den Rechner vor einigen Tagen neu gestartet habe.
Anbei einige Screenshots dazu

Den Neustart sieht man am 2. Mai an der Unterbrechung.

Die CPU Auslastung ist nicht besonders hoch - und sinkt sogar nach dem Neustart, während die Load einen gegenläufigen Trend hat:

Bei Festplatte und Co sehe ich nix auffälliges.

Prozessor ist ein Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz und es laufen einige Docker Container und eine Home-Assistant VM.

Ich habe schon viel gesucht und diesen Einzeiler gefunden, der wartende Prozesse anzeigt

ps -eo s,user,cmd | grep ^[RD] | sort | uniq -c | sort -nbr | head -20

Das gibt aber einen leeren Output.


Top liefert mir dies:

Tasks: 559 total,   1 running, 557 sleeping,   0 stopped,   1 zombie
%CPU(s): 14,6 us, 10,2 sy,  0,0 ni, 73,0 id,  0,5 wa,  0,0 hi,  1,6 si,  0,0 st
MiB Spch:   7737,1 total,    136,9 free,   4546,4 used,   3053,8 buff/cache
MiB Swap:  20480,0 total,  17862,6 free,   2617,4 used.   3171,5 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
   3076 libvirt+  20   0 2320800 462744   5720 S  34,8   5,8 481:41.09 qemu-system-x86
   4737 root      20   0   10,4g 600156  16472 S  13,2   7,6  47:03.10 influxd
   4459 henfri    20   0 2920652 138424      0 S   7,3   1,7  83:18.84 python3
 867687 henfri    20   0  120688  16956  10700 S   7,3   0,2   0:31.32 smbd
    934 root     -51   0       0      0      0 S   6,0   0,0  11:15.14 irq/122-enp0s31f6
 875488 root      20   0       0      0      0 Z   6,0   0,0   0:00.18 php
   4805 root      20   0   11200   4436   1648 S   4,3   0,1  68:55.55 htop
     70 root      20   0       0      0      0 S   4,0   0,0   5:31.54 kswapd0
  13552 admin     20   0  734284 288008   4324 S   2,3   3,6  41:02.03 bundle
     59 root      20   0       0      0      0 S   1,7   0,0   3:02.20 kcompactd0
 875445 root      20   0   11392   4500   3356 R   1,7   0,1   0:00.13 top
     15 root      -2   0       0      0      0 S   1,0   0,0  13:17.07 ktimers/0
     28 root      -2   0       0      0      0 S   1,0   0,0  13:33.38 ktimers/1
     36 root      -2   0       0      0      0 S   1,0   0,0  14:31.01 ktimers/2

Hier sehen wir schon, das qemu viel benötig - aber nicht sooo viel. Das sind 32% von einem Kern (von 4).
Bei einem Load von 4 (den ich aktuell habe) müssten aber ja alle Kerne zu 100% ausgelastet sein -wenn es denn an der CPU liegt.

Warum die VM 32% CPU braucht können wir nochmal in einem eigenen Thread ergründen (es sei denn, jemand meint, dies sei die Ursache). Denn wenn ich mich in der VM einlogge, ist die CPU Auslastung minimal.

Um der Sache weiter auf den Grund zu gehen habe ich dann mal Schritt für Schritt alles abgeschaltet:

load: 7.0
VM aus --> load: 4.0
docker aus --> load: 3.0
reboot, mount SSD-Datenpartition auskommentiert
wieder hoch, load 2.76
smbd gestoppt - unverändert
knxd gestoppt - unverändert
nginx gestoppt - 2.07
nut-server
owserver
spamassassin
libvirtd
nut-monitor
owftp
owhttpd
xrdp
xrdp-sesman
gestoppt. - 1.66
pmcd stop
pmie stop
pmlogger stop
pmproxy stop
virtlogd stop
collectd stop
fail2ban stop
load jetzt 0.64, steigt aber wieder auf 1.2 - aber auch nginx wieder gestartet

reboot: load wieder auf 7.6

Die VM (HomeAssistant) macht also schon viel aus.
Aber auch danach ist die Last noch hoch.

Was kann ich noch machen, um der Sache auf den Grund zu kommen?

Gruß,
Hendrik




FYI:
Die Docker-Container sind

pihole
unifi1
knx-ng_smarthome-ng_1
nextcloud_app_1
nextcloud_db_1
paperless-ng_webserver_1
paperless-ng_tika_1
paperless-ng_gotenberg_1
paperless-ng_db_1
paperless-ng_broker_1
knx-ng_smartvisu_1
knx-ng_grafana_1
knx-ng_influxdb_1
knx-ng_renderer_1
speedtest
gitlab_gitlab_1
opensprinkler
vaultwarden
scrutiny
portainer_portainer_1
heimdall
TasmoAdmin

 

[riversource]

CPU ist nur ein Aspekt für einen hohen Load. IO Aktivität, z.B. Disk oder Net, treibt den Load Wert auch ohne CPU Last nach oben. Deshalb sind VMs und Docker natürlich prädestiniert für hohe Load Werte.

Dabei ist auch der Durchsatz gar nicht so sehr entscheidend, sondern eher die Anzahl der Zugriffe und vor allem Wartezeiten. Wenn ich deinen einen Graph sehe mit Disk IO Times in der Größenordnung 1 Sekunde (!), dann braucht man glaube ich nicht weiter zu suchen. Das würde ich selbst auf einem VPS eher Werte um 1 ms erwarten.

 

[henfri]

Hallo,

Ok also scheint die Platte zu bremsen?
Es ist eine SSD. Ist die vielleicht am Lebensende?

Allerdings erklärt das ja nicht den starken Zuwachs nach dem Reboot. Die IO Times haben sich danach ja nicht geändert.

Gruß,
Hendrik

 

[CubeID]

Wie hoch ist die Auslastung wenn du in der HA VM auf der GUI schaust? Einstellungen > Hardware
Zeitlich könnte es mit dem Mai-Release von HA zusammenhängen. Was hast du an Addons/Integrations in HA?

 

[henfri]

Guter Gedanke...
Zwischen 7 und 12%. Durchschnitt 10%
Integrationen sind
Huawei Solar
Landroid
VSCode
Onewire
Knx

 

[CubeID]

Wie viele Cores hast du der VM gegönnt?

 

[henfri]

Nur eine.

 

[CubeID]

Dann pack mal einen zweiten oder gar dritten Core dazu. Es geht nicht unbedingt darum dass er die Leistung braucht, jedoch können dadurch Aufgaben besser und schneller parallel laufen.
Das habe ich bspw. selbst bei Pihole gemerkt, obwohl der Pi 1B fast immer im Idle war, läuft das auf dem Zero 2 jetzt nochmal etwas knackiger weil die IOs nicht aufeinander warten müssen.

 

[henfri]

Leider keine Besserung mit zwei Cores.

 

[henfri]

Habt ihr noch weitere Ideen?

 

[riversource]

Du musst den I/O Pfad optimieren. Wie gesagt, I/O Times von 1 Sekunde, da braucht man nicht weiterzusuchen. Was ist denn der Massenspeicher des Hosts, und was nutzen die Container? Ein ZFS Image?

 

[henfri]

Der Massenspeicher ist eine micron 1100 m2 SSD.

Ich hatte da kürzlich auch einen Dateisystemfehler. Vielleicht hat die es wirklich hinter sich.

Gibt es einen Benchmark, den ich hier verwenden kann?
Ich nehme an das liegt ja nicht einzig um die Megabyte pro Sekunde?

Der Host ist HomeAssistant -offizielles Image.
Ich weiss nicht welches Datei System da verwendet wird. Aber da es ist Debian11 ist vermute ich weder ZFS noch btrfs.

 

[andy_m4]

Gibt es einen Benchmark, den ich hier verwenden kann?

Du könntest erst mal ein einfachen Lesetest mit dd machen. DAs ist vielleicht nicht perfekt, liefert aber erste Hinweise.
Außerdem könntest Du die S.M.A.R.T.-Werte mal mit smartctl auslesen. Die können Hinweise für einen Defekt liefern.
Wenn Lesefehler auftreten, sollten die im Log auftreten. Debian verwendet standardmäßig journald. Darüber kriegst Du dann auch das Log.

Das sind jetzt eher einfache Dinge, die nicht unbedingt zum Ziel führen müssen, aber man hat die Chance hinweise zu bekommen oder zumindest den Fehler einzukreisen bei gleichzeitig wenig Aufwand. Daher würde ich damit beginnen.

ist vermute ich weder ZFS noch btrfs.

Meine Güte.
Guck doch einfach nach. Dann musst Du nicht vermuten.

 

[riversource]

Der Massenspeicher ist eine micron 1100 m2 SSD.

Das Schätzchen ist natürlich wirklich alt, und auch noch mSATA.

Ich nehme an das liegt ja nicht einzig um die Megabyte pro Sekunde?

Es geht überhaupt nicht um die MB pro Sekunde. Das ist das letzte, was hier interessiert. Es geht um die Zugriffszeiten.

Der Host ist HomeAssistant -offizielles Image.

Das ist doch nicht der Host, sondern läuft in einer VM? Es geht um das Dateisystems des Hosts (Servers), und um das Image Format der Container/VMs. Davon hängt ja schließlich maßgeblich ab, wie sich deine Zugriffszeiten entwickeln.

 

[henfri]

Hallo,

dann ersetze ich mal die SSD.
Würde eine Silicon Power 1TB UD90 funktionieren? Die ist NVME.
Das Board hat PCI Express x1PCI Express x16M.2/M-Key (link)

"Die eben erwähnte M.2-Schnittstelle unterstützt jetzt auch die aktuellen PCI Express NVMe SSD Module, wodurch höchste Performance erreicht werden kann. Es können jedoch weiterhin auch SATA SSD Module verwendet werden. "

Sollte passen, oder?

Sorry, ja. Der Client ist HomeAssistant. Der läuft in der VM. Dateisystem des Servers ist btrfs.

HDParm sagt:

hdparm -tT /dev/sda3

/dev/sda3:
 Timing cached reads:   26658 MB in  1.97 seconds = 13535.22 MB/sec
 Timing buffered disk reads: 806 MB in  3.01 seconds = 268.22 MB/sec

Dbench sagt:

dbench -D /srv/dev-disk-by-id-ata-Micron_1100_MTFDDAV256TBN_17501A32891E-part3/ -t 60 2
dbench version 4.00 - Copyright Andrew Tridgell 1999-2004

Running for 60 seconds with load '/usr/share/dbench/client.txt' and minimum warmup 12 secs
failed to create barrier semaphore
0 of 2 processes prepared for launch   0 sec
2 of 2 processes prepared for launch   0 sec
releasing clients
   2     13979   185.46 MB/sec  warmup   1 sec  latency 32.710 ms
   2     26999   160.53 MB/sec  warmup   2 sec  latency 8.326 ms

   2    363279    49.87 MB/sec  execute  59 sec  latency 30.282 ms
   2  cleanup  60 sec
   0  cleanup  60 sec

 Operation      Count    AvgLat    MaxLat
 ----------------------------------------
 NTCreateX      95974     0.052    45.978
 Close          70490     0.006     1.006
 Rename          4076     0.276    12.505
 Unlink         19386     0.134    11.047
 Qpathinfo      87127     0.026    42.228
 Qfileinfo      15219     0.006     0.564
 Qfsinfo        15967     0.011     0.550
 Sfileinfo       7827     0.025     0.662
 Find           33689     0.100     4.206
 WriteX         47499     0.059     7.485
 ReadX         150928     0.009     1.620
 LockX            316     0.011     0.103
 UnlockX          316     0.010     0.139
 Flush           6733    14.411   294.001

Throughput 49.8667 MB/sec  2 clients  2 procs  max_latency=294.019 ms

Smartctl:

Spoiler

=== START OF INFORMATION SECTION ===
Model Family: Crucial/Micron Client SSDs
Device Model: Micron_1100_MTFDDAV256TBN
Serial Number: 17501A32891E
LU WWN Device Id: 5 00a075 11a32891e
Firmware Version: M0MA020
User Capacity: 256.060.514.304 bytes [256 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: < 1.8 inches
TRIM Command: Available, deterministic, zeroed
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-3 T13/2161-D revision 5
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sat May 13 16:02:33 2023 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x04) Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 632) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 5) minutes.
Conveyance self-test routine
recommended polling time: ( 3) minutes.
SCT capabilities: (0x0035) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.

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 0x002f 100 100 000 Pre-fail Always - 2
5 Reallocate_NAND_Blk_Cnt 0x0032 100 100 010 Old_age Always - 2
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 5906
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 1868
171 Program_Fail_Count 0x0032 100 100 000 Old_age Always - 0
172 Erase_Fail_Count 0x0032 100 100 000 Old_age Always - 0
173 Ave_Block-Erase_Count 0x0032 041 041 000 Old_age Always - 886
174 Unexpect_Power_Loss_Ct 0x0032 100 100 000 Old_age Always - 23
183 SATA_Interfac_Downshift 0x0032 100 100 000 Old_age Always - 0
184 Error_Correction_Count 0x0032 100 100 000 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
194 Temperature_Celsius 0x0022 066 051 000 Old_age Always - 34 (Min/Max 9/49)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 2
197 Current_Pending_ECC_Cnt 0x0032 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 100 100 000 Old_age Always - 0
202 Percent_Lifetime_Remain 0x0030 041 041 001 Old_age Offline - 59
206 Write_Error_Rate 0x000e 100 100 000 Old_age Always - 0
246 Total_LBAs_Written 0x0032 100 100 000 Old_age Always - 169485660915
247 Host_Program_Page_Count 0x0032 100 100 000 Old_age Always - 5300349094
248 FTL_Program_Page_Count 0x0032 100 100 000 Old_age Always - 6005482389
180 Unused_Reserve_NAND_Blk 0x0033 000 000 000 Pre-fail Always - 2050
210 Success_RAIN_Recov_Cnt 0x0032 100 100 000 Old_age Always - 0

SMART Error Log Version: 1
No Errors Logged

Das sieht doch alles normal aus?

Gruß,
Hendrik

 

[riversource]

dann ersetze ich mal die SSD.

Das ist aber erst der letzte Punkt auf der Liste. Bedenke: Die Wahrscheinlichkeit, dass es ein Konfigurationsproblem ist, ist erheblich höher, und dann hilft eine neue SSD nicht. Ich würde erst mal alles andere ausschließen, bevor ich Geld ausgebe. Und die Benchmarkwerte sehen gut aus, daran liegt es nicht. Geld ausgeben kannst du dann immer noch, wenn du willst.

Sorry, ja. Der Client ist HomeAssistant. Der läuft in der VM. Dateisystem des Servers ist btrfs.

Und das Image Format der VM? qcow2? ZFS?

 

[henfri]

Ok, dann wird die SSD erstmal nicht getauscht. Danke für den Tipp.
Aber die schlechte Performance kombiniert mit den Dateisystem-Fehlern hat mich zweifeln lassen.

Das Format der VM ist qcow2. Ich hab die VM auch einmal neu aufgesetzt - ohne Besserung.

Es kann aber ja auch nicht nur die VM sein, denn wenn ich diese stoppe, dann hab ich ja immernoch eine hohe Last.

Gruß,
Hendrik

 

[riversource]

Nee, nur die VM sicher nicht. Aber du schreibst ja auch noch von einigen Docker Containern, und dann sieht man in deiner top Ansicht eine influxdb und php Prozesse. Dazu taucht der Kernel Swap Daemon oben in der Liste auf. Jedes Einzelne sicher kein Show Stopper, aber in Summe halt viel.

 

[henfri]

Ja, verstehe.
Aber was mache ich nun?

 

[riversource]

Finde heraus, was I/O Aktivität erzeugt. Die langen Wartezeiten kommen ja nicht von Zauberhand, vor allem, da die Zugriffszeiten im Benschmark im ms Bereich liegen. In deinen Graphen gibt es auch ein sdb. Was ist das für ein Laufwerk?