Hohe Watestates - Swap voll - Memory bei 60%

[etron770]

System:

Intel Core i7-980
HDD4x HDD SATA 1,5 TB
PLUS RAID Controller 4-Port SATA PCI-E - Adaptec 5405
RAM3x RAM 8192 MB DDR3
Festplattenauslastung in Ordnung
Proxmox Hauptsystem mit LXC Containern
Raid 10

RAM usage 60.43% (14.19 GiB of 23.48 GiB)
HD space(root) 22.56% (227.41 GiB of 1007.81 GiB)
SWAP usage 97.86% (11.74 GiB of 12.00 GiB)
CPU(s)
12 x Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz (1 Socket)
Kernel Version
Linux 5.4.106-1-pve #1 SMP PVE 5.4.106-1 (Fri, 19 Mar 2021 11:08:47 +0100)
PVE Manager Version
pve-manager/6.3-6/2184247e



vmstat 1
b swpd free buff cache si so bi bo in cs us sy id wa st
2 1 11505128 277240 1185296 9827772 2184 0 2188 256 1809 2957 0 0 93 6 0



Ich habe im gesamten System immer wieder hohe WA

iotop zeigt dann bei [loopxy] und/oder [jbd2/loop-xy] 99%IO
selbst bei einem einfachen find auf dem Root gehen wa auf ca 90 hoch
CPU usage geht dann auf 30 oder mehr
Tastatureingaben z.B find Abbruch dauern ewig

wie kann ich denn der Ursache auf den Grund gehen

Die Frage ist woher kommt der hohe Swap usage
swapoff - a und swapon bringt:
NAME TYPE SIZE USED PRIO
/dev/sda1 partition 12G 11,1G -2
Wenn 60% des Ram frei sind, warum wird der Swap nicht gelöscht ....

 

[etron770]

Update:
Der Status des Speichers war:
MiB Mem : 24043,6 total, 257,3 free, 13048,9 used, 10737,4 buff/cache
MiB Swap: 11101,7 total, 0,0 free, 11101,7 used. 8061,2 avail Mem
swapoff -a zeigte keine Wirkung
nach
echo 1 > /proc/sys/vm/drop_caches
und dann
swapoff -a

begann sich der Swap zu leeren
das aber sehr langsam

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  1 5763912 3278408 205212 8032008  880    0   880  2996 2226 5407  1  1 92  6  0
 1  0 5762940 3276088 205300 8032096  852    0   852  3796 2297 4468  0  1 94  5  0
 0  1 5761772 3275080 205364 8032112  988    0   988   368 1850 3230  0  0 95  5  0
 0  1 5760920 3272904 205396 8032212  684    0   708   116 2185 4389  1  2 93  5  0
 0  1 5759804 3272140 205428 8032280  912    0   912   180 2221 5299  0  1 92  7  0
 2  1 5758000 3268580 205508 8032956 1520    0  1520   896 2681 7138  2  3 87  7  0
 0  1 5756216 3278172 205736 8034892 1520    0  2572  4948 4546 19321  4  2 87  7  0

Bei 5 Gb hat swapoff dann sich beeendet, nach swapon swapoff -a begann er sich wieder weiter zu leeren

Ist das normal das buff/cache den restlichen freien Speicher belegt?

 

[Till]

Ist das normal das buff/cache den restlichen freien Speicher belegt?

ja, denn der Kernel verwendet nicht benötigten RAM zum cachen, dadurch wird das system schneller. Siehe auch

Help! Linux ate my RAM!

 

[etron770]

Schon, aber dass man dann den swap nicht mehr freibekommt und der die Buffer löschen muss ist doch seltsam
Und das löschen des Swaps dauer ewig, scheinbar weil der durch lauter kleine Blöcke belegt ist, wenn ich das richtig sehe.. Das dauert nun schon über eine Stunde bis swapoff fertig wird

 

[Till]

Ja, das ist schon etwas merkwürdig. Vermutlich irgend was mit lxc, wenn möglich mal rebooten und schauen ob es erneut auftritt.

 

[etron770]

Ok swap ist leer, aber das Problem der Waitstates ist immer noch vorhanden.
auf einen langsamem PC mit einer Platte gehten bei find die WS gerade mal auf 0,1
Bei den Server mit Raid controller schießen die werte sofort hoch.
irgendetwas läuft ds schief

Total DISK READ:       390.84 K/s | Total DISK WRITE:        75.38 K/s
Current DISK READ:     390.84 K/s | Current DISK WRITE:     142.38 K/s
Total DISK READ:        14.75 M/s | Total DISK WRITE:         3.48 M/s
TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                     15289 be/4 root 1200.97 K/s 0.00 B/s 0.00 % 99.53 % find / -name exim.conf
 1627 be/0 root      181.46 K/s    0.00 B/s  0.00 % 99.99 % [loop0]
12717 be/4 Debian-e    0.00 B/s    0.00 B/s  0.00 % 99.99 % showq -t unix -u -c
12989 be/4 vnstat      0.00 B/s    0.00 B/s  0.00 % 99.99 % clamscan --stdout ~5027-IdrSVInt/parts
12988 be/4 vnstat    178.67 K/s    0.00 B/s  0.00 % 99.99 % clamscan --stdout ~4722-lDmgb_oi/parts
 4786 be/0 root        0.00 B/s   69.79 K/s  0.00 % 99.99 % [loop3]
 4792 be/4 root        2.79 K/s    0.00 B/s  0.00 % 99.99 % [kmmpd-loop3]
 9236 be/4 100000     13.96 K/s    2.79 K/s  0.00 %  1.39 % python3 /usr/bin/f~an-server -xf start
 7231 be/0 root       13.96 K/s    0.00 B/s  0.00 %  1.37 % [loop7]
 1716 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kmmpd-loop1]
 1279 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/u24:2-events_power_efficient]
 1710 be/0 root        0.00 B/s    2.79 K/s  0.00 %  0.00 % [loop1]

 

[etron770]

Vermutlich war die Ursache für die hohen Waitstates zwei Bots auf der Webserver VM die mit einem kompletten IPV4 C Netz mehrfach gleichzeitig den Server abgesucht haben.
Kam zu diesen Zugriffen noch ein paar Downloads von größeren Dateien hinzu, oder z.B eine find / ... so stiegen die WS detulich an.
Seit ich diese beiden Bots mit fail2ban aussperre sind die WS wieder normal.