Hohe Load - finde den Grund einfach nicht.

[henfri]

Hallo,

SDB ist eine normale Festplatte (btrfs RAID/gespiegelt).

Ich habe ja schon Schritt für Schritt Dienste gestoppt. Da ging die Load ja kontinuierlich runter und es gab keinen stepchange.
Das spricht doch auch dafür, dass nicht ein Dienst die I/O Aktivität erzeugt...

Wie auch immer: würdest du das mit iotop machen?

Edit: iotop sagt unter einem MB/s.

Anbei aktuelle Diagramme.

influx ist übrigens einer der Docker container.

Gruß,
Hendrik

 

[riversource]

Das spricht doch auch dafür, dass nicht ein Dienst die I/O Aktivität erzeugt...

Ja. Die Dienste warten aufeinander. Gerade influx ist ja prädestiniert für Time Series Data, und das erzeugt natürlich Grundlast. Man sieht in deinem Graph, dass du im Mittel 400 I/O Operationen pro Sekunde (!) hast (Lesen und Schreiben) - in der Spitze über 4000. Das ist viel. Damit ist das I/O System augenscheinlich überlastet. Vielleicht kannst du das ganze über Caching entspannen, aber dafür muss natürlich auch genug RAM zur Verfügung stehen. Jedenfalls ist da das Nadelöhr. Möglicherweise ist die Server Hardware mit der I/O Last, die du ihm zumutest, auch einfach überfordert.

Da könnte ggf. wirklich eine NVME SSD was bringen. Achte drauf, eine mit hohen IOPS werden zu bekommen. Die Datenrate ist nebensächlich. Aber das allein wird vermutlich nicht die Wende bringen.

 

[henfri]

Hallo,

ok, danke für die Erklärung.
Es ist erstaunlich, dass es so viele I/O Operationen gibt. Wie kann ich die in der Kommandozeile darstellen lassen?
Dann könnte ich ja mal wieder dienste deaktivieren und gucken - oder kann man auch IO-Operationen pro Prozess anzeigen lassen?

Ich gebe dir Recht, dass irgendwas in der Konfiguration im Argen sein. Denn die Dienste die hier laufen sollten von einem Raspi ja auch locker gepackt werden.

Gruß,
Hendrik

 

[DEADBEEF]

Pidstat, iostat, iotop. du hast da einige Möglichkeiten um dir die Last genauer bzw den Verursacher anzusehen.

 

[henfri]

Hallo,

wir benötigen ja die IO Ops/s.
Pidstat&iotop geben die nicht aus (probiert&laut manpage)


Bei IOStat sehe ich:

tps Indicate the number of transfers per second that were issued to the device. A transfer is an I/O request to the device. Multiple logical requests can be
combined into a single I/O request to the device. A transfer is of indeterminate size.

Ist es das, was wir suchen?
Oder:

Blk_w+d (kB_w+d, MB_w+d)
The total number of blocks (kilobytes, megabytes) written or discarded.

Das Problem ist, dass der Report nur pro device angezeigt wird:

iostat -d -h
Linux 6.1.0-0.deb11.5-rt-amd64 (homeserver) 14.05.2023 x86_64 (4 CPU)

tps kB_read/s kB_wrtn/s kB_dscd/s kB_read kB_wrtn kB_dscd Device
879,08 15,0M 2,9M 0,0k 819,7G 158,6G 0,0k sda
2,04 13,0k 670,0k 0,0k 711,3M 35,7G 0,0k sdb
2,18 17,9k 670,0k 0,0k 973,3M 35,7G 0,0k sdc

Habt ihr ein anderes Tool, welches geeignet wäre die IO Ops/s pro pid darzustellen?

Gruß,
Hendrik

 

[riversource]

Prozesse, die es in iotop nach oben schaffen, sind sicherlich die erste Anlaufstelle.

 

[henfri]

Hallo,

ich habe iotop mal 2-3 min im accumulative modus laufen lassen.
Da finden wir natürlich nur die übertragene Menge, nicht aber die IO Ops.

Total DISK READ:        33.56 M/s | Total DISK WRITE:        34.69 M/s
Current DISK READ:      33.64 M/s | Current DISK WRITE:      10.55 M/s
    PID  PRIO  USER     DISK READ DISK WRITE>  SWAPIN      IO    COMMAND
  11701 be/4 henfri       16.00 K      3.19 G  ?unavailable?  smbd --foreground --no-process-group
   1363 be/4 root         31.23 M    175.41 M  ?unavailable?  [btrfs-transaction]
  19676 be/4 henfri      368.00 K    122.38 M  ?unavailable?  smbd --foreground --no-process-group
   8725 be/4 root         30.55 M     72.84 M  ?unavailable?  influxd --config /var/lib/influxdb/influxdb.conf
   5431 be/4 henfri      202.76 M     17.97 M  ?unavailable?  python3 bin/smarthome.py --foreground
   4717 be/4 root          9.18 M     17.81 M  ?unavailable?  [btrfs-transaction]
   3111 be/4 libvirt-   1072.00 K      5.77 M  ?unavailable?  qemu-system-x86_64 -name guest=HomeAssistant_new,debug-thr~ges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on
    185 be/4 root       1200.00 K      4.47 M  ?unavailable?  [kworker/u8:6-btrfs-endio]
  20925 be/4 root       1116.00 K      4.00 M  ?unavailable?  [kworker/u8:5-btrfs-endio]
  11876 be/4 root       1244.00 K      3.16 M  ?unavailable?  [kworker/u8:12-btrfs-endio-write]
  20927 be/4 root        768.00 K      3.16 M  ?unavailable?  [kworker/u8:7-btrfs-endio]
  11886 be/4 root        940.00 K      2.83 M  ?unavailable?  [kworker/u8:16-btrfs-endio-meta]
  21775 be/4 root        936.00 K      2.56 M  ?unavailable?  [kworker/u8:8-btrfs-endio-write]
   1414 be/4 root        800.00 K      2.48 M  ?unavailable?  [kworker/u8:9-btrfs-endio]
   3196 be/4 root          5.95 M      2.45 M  ?unavailable?  dockerd -H fd:// --containerd=/run/containerd/containerd.sock
     50 be/4 root        732.00 K   1856.00 K  ?unavailable?  [kworker/u8:2-btrfs-endio-meta]
  20415 be/4 root        304.00 K   1104.00 K  ?unavailable?  [kworker/u8:4-btrfs-worker]
  11070 be/4 openmedi      3.52 M    892.00 K  ?unavailable?  pihole-FTL no-daemon
  14863 be/4 n2disk        0.00 B    792.00 K  ?unavailable?  postgres: stats collector process
  12574 be/4 35002        10.53 M    632.00 K  ?unavailable?  java -Djava.awt.headless=true -cp /tika-server-standard-2.~tika-server-forked-tmp-16316705738328727046 -numRestarts 0
    256 be/3 root          0.00 B    540.00 K  ?unavailable?  [jbd2/sda2-8]
  11884 be/4 root        144.00 K    528.00 K  ?unavailable?  [kworker/u8:14-btrfs-endio-meta]
  11888 be/4 root        208.00 K    496.00 K  ?unavailable?  [kworker/u8:17-btrfs-worker]
  15298 be/4 root         23.82 M    364.00 K  ?unavailable?  bin/mongod --dbpath /usr/lib/unifi/data/db --port 27117 --~igerEngineConfigString=cache_size=256M --bind_ip 127.0.0.1
   8953 be/4 472          39.48 M    336.00 K  ?unavailable?  grafana-server --homepath=/usr/share/grafana --config=/etc~s cfg:default.paths.provisioning=/etc/grafana/provisioning
  14768 be/4 openmedi     21.80 M    324.00 K  ?unavailable?  prometheus -web.listen-address=localhost:9090 -storage.loc~228 -config.file=/var/opt/gitlab/prometheus/prometheus.yml
  12116 be/4 openmedi      0.00 B    204.00 K  ?unavailable?  postgres: stats collector
  10082 be/4 root         23.26 M    164.00 K  ?unavailable?  java -Dunifi.datadir=/unifi/data -Dunifi.logdir=/unifi/log~Dfile.encoding=UTF-8 -jar /usr/lib/unifi/lib/ace.jar start
   2061 be/4 www-data      0.00 B    144.00 K  ?unavailable?  nginx: worker process
   2984 be/4 pcp           0.00 B    108.00 K  ?unavailable?  pmlogger -N -P -r -T24h10m -c config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
   1951 be/4 root          0.00 B     96.00 K  ?unavailable?  rrdcached -B -F -f 3600 -w 900 -b /var/lib/rrdcached/db/ -~journal/ -p /run/rrdcached.pid -l unix:/run/rrdcached.sock
   1507 be/4 root          0.00 B     84.00 K  ?unavailable?  rsyslogd -n -iNONE
   1583 be/4 squeezeb      0.00 B     52.00 K  ?unavailable?  bash /usr/sbin/squeezeboxserver_safe /usr/sbin/squeezeboxs~ --cachedir /var/lib/squeezeboxserver/cache --charset=utf8
  14786 be/4 root          0.00 B     44.00 K  ?unavailable?  svlogd -tt /var/log/gitlab/gitlab-monitor

Samba hat gerade viel zu tun, da ein Windows-Backup läuft.

Ansonsten fällt Influx und btrfs, sowie smarthome auf.
Unifi finde ich jetzt auch nicht so wenig...

Gruß,
Hendrik

 

[riversource]

Samba hat gerade viel zu tun, da ein Windows-Backup läuft.

Wenn das eine Ausnahme-Situation ist, macht es natürlich überhaupt keinen Sinn, die Messung dann zu machen. Das verzerrt das Ergebnis natürlich drastisch. Andererseits sorgt sowas natürlich für hohe Load Werte.

Ansonsten fällt Influx und btrfs, sowie smarthome auf.

Da fallen noch mehr Datenbanken auf: Mongo, postgres, rrd. Und dazu influx. Warum so viele Datenbanken? Fileserver und gitlab; prometheus und grafana, ... Mir scheint, das ist ein wild zusammengewürfelter Haufen Dienste ohne jeden Sinn und Verstand. Viele Dinge, die vergleichbare Funktionalität anbieten und sich gegenseitig die Ressourcen kannibalisieren.

Ich denke, da musst du zurück ans Reißbrett. Die ganze Architektur des Servers macht so keinen Sinn. Fasse Dienste zusammen und lasse sie aufs gleiche Backend zugreifen. Ich hab auf meinem VPS auch mehrere Dienste, die eine Datenbank brauchen, aber da gibt es dann eine Datenbank, auf die alle zugreifen. Und die läuft auf dem Host, und nicht in einem Container, um den Massenspeicherzugriff zu optimieren. Dazu solltest du ernsthaft überlegen, ob das alles wirklich auf nur einem Server laufen muss.

 

[henfri]

Wenn das eine Ausnahme-Situation ist, macht es natürlich überhaupt keinen Sinn, die Messung dann zu machen. Das verzerrt das Ergebnis natürlich drastisch. Andererseits sorgt sowas natürlich für hohe Load Werte.

wenn das Backup nicht laufen würde, würden die anderen Prozesse doch nicht weniger oder mehr übertragen.
Die Load-Werte habe ich hier doch gar nicht beobachtet. Es ging doch darum, Prozesse zu finden die hohe IO-Last erzeugen.
Da ist das Backup ja rein additiv

Da fallen noch mehr Datenbanken auf: Mongo, postgres, rrd. Und dazu influx. Warum so viele Datenbanken? Fileserver und gitlab; prometheus und grafana, ... Mir scheint, das ist ein wild zusammengewürfelter Haufen Dienste ohne jeden Sinn und Verstand.

Ich finde, dass du hier ein wenig schnell bist.

rrd wird vom Betriebssystem (openmediavault) genutzt um z.B. die Performance-Daten zu erzeugen.
Postgres wird von paperless-ngx verwendet. Da geht bestimmt auch eine andere DB. Aber dann funktioniert es halt erstmal nicht und dann muss ich frickeln, damit es funktioniert. Mit Postgres geht es out of the box und wird supported.
Mongo wird von Unifi verwendet. Rest s.o.
Influx wird vom Smarthome für Grafana verwendet. Rest s.o.
Gitlab verwende ich für die Versionsverwaltung meiner Konfiguration.

Das hat also schon alles seinen Grund.

Viele Dinge, die vergleichbare Funktionalität anbieten und sich gegenseitig die Ressourcen kannibalisieren.

Bist du sicher, dass -bei gleicher Aufgabe- zwei unterschiedliche Datenbanken wesentlich mehr Resourcen benötigen als eine?
Kann das bei der -lachhaften- Aufgabe der Grund sein? Nochmal: Die Aufgabe muss ein RasPi im Schlaf schaffen.

Ich denke, da musst du zurück ans Reißbrett. Die ganze Architektur des Servers macht so keinen Sinn. Fasse Dienste zusammen und lasse sie aufs gleiche Backend zugreifen. Ich hab auf meinem VPS auch mehrere Dienste, die eine Datenbank brauchen, aber da gibt es dann eine Datenbank, auf die alle zugreifen. Und die läuft auf dem Host, und nicht in einem Container, um den Massenspeicherzugriff zu optimieren.

Nein, ich werde die DBs nicht konsolidieren. Dazu reichen meine Fähigkeiten nicht und es erzeugt neue Probleme.

Dazu solltest du ernsthaft überlegen, ob das alles wirklich auf nur einem Server laufen muss.

Aber klar! Das ist doch keine Aufgabe für einen Server. Wie oft lade ich was bei Gitlab hoch? Alle zwei Wochen mal.
Die rrd-Daten sind nur die geposteten Performance-Daten. Das ist doch lachhaft und würde beim zweiten Server nur ein zweites Mal gemacht werden.

Zwei Server brauchen zweimal 10W idle Verbrauch. Das muss ja nicht sein.

Gruß,
Hendrik

 

[riversource]

wenn das Backup nicht laufen würde, würden die anderen Prozesse doch nicht weniger oder mehr übertragen.

Oh doch. Natürlich hat das Einfluss, allein schon auf die Warteschlange. Das Zugriffsverhalten der einzelnen Apps ändert sich deutlich, Zugriffe werden gebündelt und über NCQ ggf. auch umsortiert.

Das hat also schon alles seinen Grund.

Es mag ja sein, dass du für jeden einzelnen Dienst einen Grund hast. Aber wie sie aufgesetzt sind, dafür gibt es keinen Grund.

Bist du sicher, dass -bei gleicher Aufgabe- zwei unterschiedliche Datenbanken wesentlich mehr Resourcen benötigen als eine?

Oh ja. Vor allem für Disk I/O. Die finden nämlich konkurrierend statt, und nicht koordiniert.

Kann das bei der -lachhaften- Aufgabe der Grund sein? Nochmal: Die Aufgabe muss ein RasPi im Schlaf schaffen.

Jede Einzelne vielleicht. Alle zusammen sicher nicht. Vor allem nicht, wenn sie so aufgesetzt sind.

Nein, ich werde die DBs nicht konsolidieren. Dazu reichen meine Fähigkeiten nicht und es erzeugt neue Probleme.

Aber es löst auch welche, vor allem Performance Probleme.

Zwei Server brauchen zweimal 10W idle Verbrauch. Das muss ja nicht sein.

Das sehe ich auch so.

Du hast halt die Wahl. Die hohen Load Werte sind ja ein eindeutiges Zeichen, dass das System an der Lastgrenze arbeitet. Das kann gefühlt noch reichen, aber damit ist es irgendwann vorbei. Wenn Zugriffe schon Sekunden brauchen, wann wird es zu ersten Problemen durch Timeouts kommen? Und dann hast du die Wahl: Entweder du machst dich an die Optimierung, oder du spendierst mehr Ressourcen. Ich denke auch, dass man das System mit den Diensten und dem Nutzungsverhalten auf der HW zum Laufen kriegen kann. Aber nicht mit 5 konkurrierenden Datenbanken in der Konstellation.

 

[henfri]

Hallo,

ich habe jetzt mal alle Datenbanken abgeschaltet -- kein Effekt auf Load

Stop von smarthomeng -0.3 bis -0.6
Samba aus -1 (kumulativ es lief ein Windows-Backup, das habe ich erst später bemerkt)
HomeAssistant aus -1.3 (kumulativ)

Danach sah dann iotop so aus:

Total DISK READ:         0.00 B/s | Total DISK WRITE:         0.00 B/s
Current DISK READ:       0.00 B/s | Current DISK WRITE:       0.00 B/s
    PID  PRIO  USER    DISK READ>  DISK WRITE  SWAPIN      IO    COMMAND
   8953 be/4 472        1860.00 K    604.00 K  ?unavailable?  grafana-server --homepath=/usr/share/grafana --config=/etc~s cfg:default.paths.provisioning=/etc/grafana/provisioning
   3196 be/4 root        144.00 K   1448.00 K  ?unavailable?  dockerd -H fd:// --containerd=/run/containerd/containerd.sock
   1363 be/4 root         48.00 K     43.97 M  ?unavailable?  [btrfs-transaction]
  11070 be/4 openmedi     24.00 K    924.00 K  ?unavailable?  pihole-FTL no-daemon
  12574 be/4 35002        20.00 K    596.00 K  ?unavailable?  java -Djava.awt.headless=true -cp /tika-server-standard-2.~tika-server-forked-tmp-16316705738328727046 -numRestarts 0
 406878 be/4 root         16.00 K    528.00 K  ?unavailable?  [kworker/u8:9-btrfs-endio-write]


    PID  PRIO  USER     DISK READ DISK WRITE>  SWAPIN      IO    COMMAND
   1363 be/4 root         80.00 K     85.22 M  ?unavailable?  [btrfs-transaction]
   3196 be/4 root        296.00 K      2.69 M  ?unavailable?  dockerd -H fd:// --containerd=/run/containerd/containerd.sock
  11070 be/4 openmedi    132.00 K   1928.00 K  ?unavailable?  pihole-FTL no-daemon
  12574 be/4 35002        92.00 K   1260.00 K  ?unavailable?  java -Djava.awt.headless=true -cp /tika-server-standard-2.~tika-server-forked-tmp-16316705738328727046 -numRestarts 0
    256 be/3 root          0.00 B   1084.00 K  ?unavailable?  [jbd2/sda2-8]

Trotzdem geht der load manchmal wieder rauf bis ca. 3.3

Alle DockerContainer aus --> 1.2

Die hohen Load Werte sind ja ein eindeutiges Zeichen, dass das System an der Lastgrenze arbeitet. Das kann gefühlt noch reichen, aber damit ist es irgendwann vorbei. Wenn Zugriffe schon Sekunden brauchen, wann wird es zu ersten Problemen durch Timeouts kommen?

Ja, aber ich gehe davon aus, dass es sich um ein (Konfigurations?) Problem handelt.

Aber nicht mit 5 konkurrierenden Datenbanken in der Konstellation.

Aber s.o.: Alle DBs aus und die Last ist weiterhin hoch.

Nochwas: Ich habe (bewusst) nix geänder in den letzten Wochen. Aber wie du hier siehst, war der Rechner in der Vergangenheit keinesfalls überlastet. In Woche 18 beginnt das plötzlich:

Gruß,
Hendrik

 

[riversource]

Dann musst du herausfinden, was du in Woche 18 geändert hast.

 

[DEADBEEF]

Welche Distribution nutzt du? mit iostat -P werden mir I/O pro Prozess angezeigt

 

[henfri]

Hallo,

ich nutze Debian 11.
iostat -P gibt mir auch die I/O pro prozess. Dabei ist smarthome auffällig.

lsof -p 30 |grep -v IPv |grep -v lib  |more
COMMAND PID      USER   FD      TYPE             DEVICE    SIZE/OFF     NODE NAME
python3  30 smarthome  cwd       DIR               0,69        2328    34615 /usr/local/smarthome/plugins
python3  30 smarthome  rtd       DIR               0,69         218      256 /
python3  30 smarthome  txt       REG               0,69       14416     5586 /usr/local/bin/python3.9
python3  30 smarthome  mem       REG               0,50                 5586 /usr/local/bin/python3.9 (path dev=0,69)
python3  30 smarthome    0u      CHR              136,0         0t0        3 /dev/pts/0
python3  30 smarthome    1u      CHR              136,0         0t0        3 /dev/pts/0
python3  30 smarthome    2u      CHR              136,0         0t0        3 /dev/pts/0
python3  30 smarthome    3w      REG               0,75         354 27330801 /usr/local/smarthome/var/log/smarthome-alexa.log
python3  30 smarthome    4w      REG               0,75        1968 27253379 /usr/local/smarthome/var/log/smarthome-alexa4shng.log
python3  30 smarthome    5w      REG               0,75           0 18531071 /usr/local/smarthome/var/log/smarthome-bewaesserung-dbg.log
python3  30 smarthome    6w      REG               0,75         232 27320553 /usr/local/smarthome/var/log/smarthome-forecastsolar.log
python3  30 smarthome    7w      REG               0,75        3108 27253510 /usr/local/smarthome/var/log/smarthome-knx-plugin-debug.log
python3  30 smarthome    8w      REG               0,75           0 18531073 /usr/local/smarthome/var/log/smarthome-landroid.log
python3  30 smarthome    9w      REG               0,75       58421 27313320 /usr/local/smarthome/var/log/smarthome-lichtstatus-dbg.log
python3  30 smarthome   10w      REG               0,75    33108289 27313383 /usr/local/smarthome/var/log/smarthome-mqtt-dbg.log
python3  30 smarthome   11w      REG               0,75        1136 27339173 /usr/local/smarthome/var/log/smarthome-telegram.log
python3  30 smarthome   12w      REG               0,75      277647 27313482 /usr/local/smarthome/var/log/smarthome-uvr-dbg.log
python3  30 smarthome   13w      REG               0,75         891 27317793 /usr/local/smarthome/var/log/smarthome-xiaomi.log
python3  30 smarthome   14w      REG               0,75      163237 27313354 /usr/local/smarthome/var/log/ow_busmonitor.log
python3  30 smarthome   15w      REG               0,75    15877205 27313323 /usr/local/smarthome/var/log/knx_busmonitor.log
python3  30 smarthome   16w      REG               0,75     5487695 27380694 /usr/local/smarthome/var/log/smarthome-details.log
python3  30 smarthome   17w      REG               0,75         129 27317483 /usr/local/smarthome/var/log/item-value-change.log
python3  30 smarthome   18w      REG               0,75      775569 27313355 /usr/local/smarthome/var/log/smarthome-warnings.log
python3  30 smarthome   19r      REG               0,75           2 26049223 /usr/local/smarthome/var/run/smarthome.pid
python3  30 smarthome   20u  a_inode               0,14           0     1048 [eventpoll]
python3  30 smarthome   21u  a_inode               0,14           0     1048 [eventpoll]
python3  30 smarthome   24u  a_inode               0,14           0     1048 [eventpoll]
python3  30 smarthome   26u  a_inode               0,14           0     1048 [eventpoll]
python3  30 smarthome   29u     unix 0x0000000016d600b6         0t0    53007 type=STREAM
python3  30 smarthome   30u     unix 0x000000004bfa2264         0t0    53008 type=STREAM
python3  30 smarthome   32u      REG               0,75 17666276352   106710 /usr/local/smarthome/var/db/smarthome.db
python3  30 smarthome   42u     sock                0,8         0t0  1252348 protocol: TCPv6
python3  30 smarthome   46u  a_inode               0,14           0     1048 [eventpoll]

dabei habe ich alles was "lib" ist rausgefiltert. Wenn ich das nicht mache, werden eine ganze menge Python-libraries angezeigt.
Aber eigentlich sollte python ja jede library nur beim Import laden und dann im Speicher behalten...
Also so recht kann ich mir keinen Reim daraus machen..

Ich hab dazu auch nebenan mal gefragt:
https://knx-user-forum.de/forum/sup...py-liest-sehr-viel-von-der-platte#post1868975

Gruß,
Hendrik