fundal
Rulem mai multe servere KVM pe Ubuntu 16.04 și am început să testăm upgrade-ul la 20.04.
Ceea ce am descoperit este că, deși nu am văzut niciodată vreo utilizare de swap pe serverele noastre 16.04, după câteva zile, un server 20.04 va afișa câteva sute de MB de utilizare de swap.
Nu este o problemă mare, deoarece vmstat arată foarte puțină activitate de schimb, iar graficele munin confirmă că schimbul de intrare/ieșire este nesemnificativ, dar vrem totuși să înțelegem comportamentul.
Până acum am folosit Nagios pentru a monitoriza utilizarea schimburilor și pentru a alerta dacă este găsit.
Sistemul care a fost actualizat din 16.04 până în 20.04 rulează cinci VM-uri cu încărcare ușoară.
Sistemul gazdă arată că a folosit meme în jur de 29 G din aproximativ 200 GB memorie totală. Fără vârfuri sau ceva care să determine utilizarea mem-ului să ajungă atât de mare. Utilizarea memoriei VM este restricționată și nu există alte procese care necesită memorie care rulează pe serverul KVM în sine.
root@kvm-xx:~# free -m
total folosit gratuit partajat buff/cache disponibil
Mem: 193336 29495 768 5 163072 162404
Schimb: 6675 240 6435
Sus, exemplu de schimbare a proceselor:
PID VIRT RES SHR S %MEM COMMAND SWAP
6447 18,2g 15,8g 22908 S 8,4 qemu-system-x86 239352
6160 2661052 1,9g 21880 S 1,0 qemu-system-x86 90788
6315 2129436 644388 21856 S 0,3 qemu-system-x86 29724
6391 10,4g 7,9g 22832 S 4,2 qemu-system-x86 24028
6197 6505584 3,0g 23008 S 1,6 qemu-system-x86 10972
5686 9908 2944 2720 S 0,0 cron 60
5805 24404 14440 4388 S 0,0 munin-nodul 4
Ieșire tipică de la vmstat, care nu afișează nicio modificare în schimbarea intrare/ieșire.
root@kvm-xx:~# vmstat 2 10
procs -----------memorie---------- ---swap-- -----io---- -system-- ------cpu -----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 407620 869916 214784 165081536 0 0 270 12 5 2 0 2 98 0 0
2 0 407620 869900 214784 165081536 0 0 0 28 8533 24140 0 2 98 0 0
1 0 407620 869836 214784 165081536 0 0 0 28 8642 24682 0 2 98 0 0
Acest sistem a funcționat timp de un an cu 0 swap pe 16.04 cu aceleași VM-uri și încărcare.
Ce a fost încercat și testat
După actualizare, s-a constatat că numad nu a fost instalat și că VM-urile nu au fost fixate pe vcpu-uri pe același procesor fizic. Adică utilizarea memoriei pe nodurile numa. Numad instalat și fixare verificată. Cred că utilizarea de schimb a fost mai mare inainte de această schimbare, dar nu pot spune cu certitudine.
Mă așteptam ca acest comportament să fie legat de kernel, așa că a fost actualizat de la 5.4 la kernel-ul HWE 5.11. Același comportament atât pe 5.4, cât și pe 5.11.
Am încercat să dezactivăm KSM (Kernel samepage mergeing), deoarece nu avem nevoie de el și să-l eliminăm ca posibilă sursă de utilizare a schimburilor.
Am încercat să dezactivez complet schimbul pentru a vedea dacă a existat o înfometare reală a memoriei în care Ucigașul OOM va veni la petrecere. Acest lucru nu s-a întâmplat, așa că mi se pare că schimbul nu este necesar, dar este încă folosit dintr-un anumit motiv.
Idei și gânduri
Cred că din anumite motive, nucleul decide să schimbe paginile inactive pentru a le schimba, chiar și cu swappiness = 0. Acesta este probabil un comportament care s-a schimbat cu noile nuclee livrate cu 20.04.
În mod ideal, ne-am dori ca nucleul să schimbe doar în ultimă instanță, ca comportament anterior, și să folosim monitorizarea utilizării swap pentru a detecta utilizarea swap-ului și a declanșa o alarmă Nagios.
Am citit mai multe fire pe subiecte similare, dar am găsit informații contradictorii despre care ar putea fi explicația.
Ceea ce vreau cu adevărat să evit este o situație în care facem upgrade la unele dintre serverele noastre 16.04 mai grele încărcate la 20.04 și vedem că această problemă escaladează într-o problemă reală în producție.
Sunt conștient de swapoff / swapon la mutarea manuală a memoriei din swap, dar întrebarea este de ce se schimbă în primul rând.
Dacă cineva are o perspectivă în acest sens, ar fi foarte apreciat.
Mulțumiri!
