Declanșează manual schimbul?

Mă joc cu ZFS pe Proxmox și am observat că schimbul nu pare să intervină niciodată. Valoarea schimbului este setată în prezent la 50, dar nu se schimbă niciodată decât dacă ajung la 100% utilizarea RAM, acționând ca și cum schimbul este setat la 0.

Cum pot forța manual schimbarea să ruleze? Singurul mod în care pot face acest lucru este instalând ceva de genul https://github.com/julman99/eatmemory să consume memoria sistemului de peste 100%

cat /proc/meminfo

MemTotal: 528099208 kB
MemFree: 33819676 kB
MemDisponibil: 30995036 kB
Buffere: 65056 kB
Memorate în cache: 368868 kB
Schimbat în cache: 4978016 kB
Activ: 383870632 kB
Inactiv: 71255296 kB
Activ(anon): 383654260 kB
Inactiv(anon): 71140760 kB
Activ(fișier): 216372 kB
Inactiv(fișier): 114536 kB
Inevitabil: 160824 kB
Mlocked: 160824 kB
Schimb total: 1875374420 kB
SchimbFree: 1576041808 kB
Murdar: 128 kB
Scriere inversă: 0 kB
AnonPagini: 450155280 kB
Cartografiat: 185764 kB
Shmem: 92400 kB
KRecuperabil: 1316628 kB
Placă: 7796824 kB
SRecuperabil: 1316628 kB
SUnreclaim: 6480196 kB
KernelStack: 49616 kB
PageTabele: 1746424 kB
NFS_Instabil: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 2139350296 kB
Committed_AS: 1255929500 kB
VmallocTotal: 34359738367 kB
VmallocUtilizat: 6192420 kB
VmallocChunk: 0 kB
Percpu: 1302144 kB
Hardware corupt: 0 kB
AnonHugePagini: 176281600 kB
ShmemHugePagini: 0 kB
ShmemPmdMapped: 0 kB
FileHugePagini: 0 kB
FilePmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 72
HugePages_Free: 72
HugePages_Rsvd: 0
HugePages_Surp: 0
Dimensiune mare a paginii: 2048 kB
Hugetlb: 147456 kB
DirectMap4k: 49376056 kB
DirectMap2M: 406616064 kB
DirectMap1G: 81788928 kB

swappiness nu forțează utilizarea spațiului de swap. Nici nu te va scuti de a nu avea suficientă memorie.

Valori mai mari ale schimbul încurajează recuperarea paginilor anonime, nu doar cache-ul paginilor. Dar acest lucru nu face mare lucru pentru ZFS pe Linux, care nu folosește cache-ul paginii Linux.

Practic, vreau să existe întotdeauna o anumită cantitate de RAM liberă. ... La adaugă curentul meu de sistem folosește 230/256 GB de RAM fără nicio schimbare folosit încă. ... dacă creez o altă mașină virtuală când RAM-ul este la 99% nu va porni.

Faceți o planificare a capacității pentru a nu supraabona memoria. Mai puțin o comandă magică pentru a-i spune hipervizorului să păstreze memoria liberă și mai mult disciplina ta de a nu începe mai mulți oaspeți decât ai resurse pentru.

230/256 GB este utilizat în proporție de 90%, mult mai mult decât poate intra în presiunea memoriei, nu este bun pentru performanță. Ceea ce poate necesita limitarea memoriei oaspeților, 56 x 4 GB invitați, pentru a alcătui unele numere. Dacă cele două zeci de GB rămase sunt suficiente pentru a rula nucleul hypervisor și pentru a avea totuși o oarecare rezervă, este ceva pe care îl puteți descoperi în testare.

Editare: din meminfo, gazda dvs. de 500 GB este sub presiunea memoriei și se schimbă.

• MemDisponibil la 5,8% din total este scăzut. 29 GB pentru a lucra pe o gazdă de 500 GB nu este foarte mult.
• SwapTotal minus SwapFree arată 285 GB de utilizare a spațiului de swap. 1788 GB de schimb total înseamnă că nu se va epuiza în curând. Amintiți-vă că majoritatea stocării persistente este cu ordine de mărime mai lentă decât DRAM.
• 0,4 GB în cache este destul de scăzut în cifre absolute. În concordanță cu utilizarea ZFS pe Linux, care nu utilizează cache-ul obișnuit al paginii Linux VFS.Ca rezultat, swappiness tunable nu face aproape nimic în acest mediu. Dacă aruncați cache-urile manual, nu faceți asta, probabil că dăunează performanței.

Schimbarea se face în seturi de pagini la un moment dat, când este necesar. Gazda nu va elibera brusc un întreg oaspete de 100 GB atunci când solicitările de memorie pentru oaspeți sunt mai mici. Asta ar fi foarte scump.

Sunt sceptic cu privire la supraabonarea memoriei în general și la balonarea în special și nu le recomand. Încurajarea memoriei scăzute poate fi riscantă pentru performanță, deoarece, în cel mai rău caz, revendicarea introduce latență și ar putea enerva criminalul OOM. Vedeți încercările dvs. de a porni oaspeții la o utilizare ridicată, după un anumit punct, nucleul nu va acorda alocările de memorie.

Confirmați că gazda are > 100 GB RAM (fără a lua în calcul schimbul) disponibil înainte de a începe un oaspete de 100 GB. Închideți oaspeții înainte de a le reduce dimensiunea memoriei. Neabonarea excesivă este mai costisitoare în ceea ce privește costurile de memorie, dar are performanțe mai consistente și este mai ușor de întreținut.