Raspi4 hoge CPU load door kswapd0 bestand

[Sa1]

Ruim een jaar maak ik gebruik van een Raspberry Pi4. Heb de 8GB variant gekozen. Hierop heb ik docker-compose geïnstalleerd en draai daar inmiddels 17 containers. Dit draait al lange tijd zo en ben daar altijd bijzonder tevreden over geweest. Ik had dit draaien met een SSD van het merk ADATA, met wat kunstgrepen is het gelukt om deze via USB te laten booten (kennelijk ondersteund de disk bepaalde SCSI commands niet die per default in de USB3 standaard zitten).

Sinds een week of twee loopt hij echter bijna iedere nacht vast. Na wat onderzoek blijkt dat wanneer er veel disk activiteit is, hij crasht.

Heb een nieuwe installatie gedaan met een nieuwe T5 SSD USB schijf van Samsung. Dockers overgezet en alles werkt weer, echter heb ik een vrij bijzonder probleem en dat is dat mijn load constant extreem hoog is, vooral bij disk activiteit schiet hij de lucht in, hij gaat dan echt geregeld naar de 21 toe en gemiddeld blijft hij een beetje steken op 6, 6, 6. Dit heeft natuurlijk behoorlijke impact op de werking van het geheel. Verschillende containers raken 'unhealty' en andere werken niet meer lekker (bijv Unifi container kan ik geen listing van de clients of devices opvragen).

Als ik ga kijken met het commando 'top' dan zie ik dan het proces kswapd0 constant hoge CPU vraagt en met SSD activiteit alleen nog maar meer. Dan gaat hij echt naar 100%+.

Ik zou heel graag willen weten wat het is dat er voor zorgt dat dit proces zo hard de lucht in gaat (draait onder root) en waarom deze naar voren komt. Heb redelijk gezocht op het internet, maar kom eigenlijk alleen maar vrij oude informatie tegen. Het schijnt ook een bug te zijn geweest, maar dat is al lang niet meer aan de orde dus.

Extra info:

Device: Raspberry Pi 4, 8GB boot van USB SSD T5 1TB van Samsung.
Uname -r: 5.10.52-v71+
Free -m: total 7897, free: 4540, swap totaal 99, used 0.

Wat ik al heb geprobeerd:

vm.swappines heb ik gewijzigd naar 0 (echo vm.swappiness=0 | sudo tee -a /etc/sysctl.conf). Dit was een van de adviezen op het internet. Na reboot lijkt het echter niets te doen. Waarde is wel aangepast, maar geen effect.

Het commando "echo 1 > /proc/sys/vm/drop_caches" zou er voor moeten zorgen dat hij direct weggaat, maar dat lijkt ook niet te helpen.

Heb plex als een docker draaien, die heeft een aantal shares gekoppeld vanaf m'n NAS. Die waren via CIFS gemount, dat heb ik omgezet naar NFS. Maakt ook geen drol uit.

Plex uitschakelen lijkt in eerste instantie een oplossing, maar na verloop van tijd gaat hij toch weer CPU opeisen. Overigens dat hij 's nachts vast liep kwam waarschijnlijk omdat er een paar geplande taken vanuit plex container liepen. Dit heeft dus eigenlijk een jaar lang zonder problemen gefunctioneerd, maar is ineens gebeurt.

Mocht ik meer info moeten geven dan graag laten weten. Ik ben het spoor een beetje bijster en weet ook niet meer wat ik moet doen om verder te zoeken.

[DJMaze]

kswapd zorgt ervoor dat je excessieve geheugen gebruik naar de swap partitie gaat.
Blijkbaar heb je te weinig RAM (of stuk)

[Sa1]

DJMaze schreef op woensdag 4 augustus 2021 @ 12:37:
kswapd zorgt ervoor dat je excessieve geheugen gebruik naar de swap partitie gaat.
Blijkbaar heb je te weinig RAM (of stuk)

Bedankt voor je antwoord. Ik snap wat het doet, maar als je gaat kijken dat van de 8GB er nog 4,5GB vrij is, dan lijkt me dat dat het punt niet kan zijn, toch? Of ben ik nu gek, hoezo zou hij gaan cachen als er gewoon nog ruim voldoende beschikbaar is. Zeker ook omdat ik heb aangegeven dat hij dat juist niet moet doen. Is dan de conclusie dat het stuk is?

[ Voor 9% gewijzigd door Sa1 op 04-08-2021 15:22 ]

[Sa1]

mmm... heb misschien toch iets gevonden.

code:

I've found another workaround that works well for me so far: create a file /etc/sysctl.d/60-workaround-kswapd-allcpu.conf with the following contents and reboot:
vm.min_free_kbytes=67584

Gevonden op https://bugzilla.kernel.org/show_bug.cgi?id=65201#c20 ook links gevonden naar https://bugzilla.kernel.org/show_bug.cgi?id=110501#c15 blijkt dat het probleem al zo oud is als de weg naar Rome.

Niet te vroeg juigen natuurlijk, maar bij de vorige reboots was het proces al snel weer op 100% en hij staat nu al een poosje aan en heeft nog steeds een acceptabele load.

[ Voor 16% gewijzigd door Sa1 op 04-08-2021 16:00 ]

[Mike2k]

Het swappen gebeurt niet pas als het geheugen helemaal vol is. Je kunt een maximale hoeveelheid geheugen toewijzen aan een proces. Denk bijvoorbeeld aan de JVM xms en xmx opties.

Hierbij zou het kunnen dat je maar de helft van het geheugen in gebruik hebt en er toch geswapt wordt...misschien staat je docker ingesteld om maar een maximale hoeveelheid geheugen te gebruiken ?

[Sa1]

Ships, daar gaat ie weer:

code:

op - 16:28:22 up 51 min,  3 users,  load average: 8.13, 6.31, 4.57
Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
%Cpu(s): 17.5 us, 74.4 sy,  0.0 ni,  1.3 id,  1.4 wa,  0.0 hi,  5.5 si,  0.0 st
MiB Mem :   7897.4 total,   4758.3 free,   1384.0 used,   1755.0 buff/cache
MiB Swap:    100.0 total,    100.0 free,      0.0 used.   6354.7 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   65 root      20   0       0      0      0 R  99.0   0.0   6:38.51 kswapd0

[Sa1]

Mike2k schreef op woensdag 4 augustus 2021 @ 16:05:
Het swappen gebeurt niet pas als het geheugen helemaal vol is. Je kunt een maximale hoeveelheid geheugen toewijzen aan een proces. Denk bijvoorbeeld aan de JVM xms en xmx opties.

Hierbij zou het kunnen dat je maar de helft van het geheugen in gebruik hebt en er toch geswapt wordt...misschien staat je docker ingesteld om maar een maximale hoeveelheid geheugen te gebruiken ?

Als ik info opvraag van docker, krijg ik het volgende:

code:

WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory TCP limit support
WARNING: No oom kill disable support

Als ik het goed begrijp met wat er op internet staat is dat er dan in het geheel geen ondersteuning is om hier beperkingen op te zetten.

[Sa1]

Ben er niet uit gekomen helaas, en het was mega frustrerend, inmiddels ben ik dus van scratch af gestart. Het betreffende proces blijft nu rustig en hij staat al uren aan.

Hopelijk blijft het zo goed lopen, bedankt voor jullie input.

[Sa1]

Mooi, het is nu vet snel!

code:

pi@docker:~ $ wget -4 -O /dev/null http://speedtest.novoserve.com/10GB.bin
--2021-08-06 11:00:55--  http://speedtest.novoserve.com/10GB.bin
Resolving speedtest.novoserve.com (speedtest.novoserve.com)... 185.80.233.178
Connecting to speedtest.novoserve.com (speedtest.novoserve.com)|185.80.233.178|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10737418240 (10G) [application/octet-stream]
Saving to: ‘/dev/null’

/dev/null                               100%[===============================================================================>]  10.00G   112MB/s    in 93s

2021-08-06 11:02:28 (110 MB/s) - ‘/dev/null’ saved [10737418240/10737418240]

Deze download snelheden kreeg ik niet met m'n vorige image. Heb nu de ARM64 draaien, hoewel nog beta draait hij heerlijk.

[ Voor 11% gewijzigd door Sa1 op 06-08-2021 11:26 . Reden: uhh NL is prima ]

[aawe mwan]

Sa1 schreef op vrijdag 6 augustus 2021 @ 11:06:
Mooi, het is nu vet snel!
[...]
Heb nu de ARM64 draaien, hoewel nog beta draait hij heerlijk.

Had je eerst de 32-bits versie draaien op de 8GB Pi?