Swappiness láma (elmélet)

Fórumok

Egy 16GB memóriával szerelt debian-t futtató gépen átlagosan és tartósan 8GB a szabad memória mérete - inkább több -, mégis rendszeresen megemelkedik a swout értéke.

A vm.swappiness és vm.vfs_cache_pressure változókat már megtaláltam, de igazából nem értem, ha a memória fele még szabad, miért használja folyamatosan a swap-et a rendszer?

Be lehet (érdemes?) úgy állítani a rendszert, hogy a swap-et csak végszükség esetén használja, és a folyamatos üzemben ne nyúljon feleslegesen a lemezhez? Ehhez a vm.swappiness nullázása elég, vagy valami más módon lehet ezt elérni?

Hozzászólások

Desktopon érdemes, igen a swappiness 0 elég.

Nekem is swappiness = 0 van beállítva, mégis, amikor elfogyott a RAM, veszett HDD-kerregtetésbe kezdett. Az amúgy jól és gyorsan dolgozó linuxom egy használhatatlan zombi lett, arra sem volt CPU-ja, hogy a Caps Lock LED-et ki/be kapcsolgassa, csak a HDD-t reszelte. Atom idegesítő, hogy intenzív swap esetén (de minek, ha a swappiness = 0? ha nincs RAM, szálljanak el alkalmazások, de ne tekerjen) a linuxos desktop gép teljesen használhatatlan lesz.

olyan olcso a ramok, hogy nem latom ertelmet swap hasznalatnak. ami nem fer bele 8-16G-be, annak nincs ott keresnivaloja. ha elfogy a ram akkor jojjon a baltas gyilkos (oom), es tegyen rendet. egyedul azert szoktam hagyni egy kicsi swapot, hogy a memoryleakes programok maradvanyai keruljenek ki oda.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Az a baj, hogy amikor elfogy a memória, akkor nem a swap az egyetlen megoldás...

Jön a kernel és azt mondja: "Nini, itt ez a jó kis programocska. Böszme sok helyet foglal és épp nem fut. Nosza, takarítsuk ki a memóriából - ha kell, majd újratöltöm lemezről!"
Ezzel a probléma átmenetileg megoldódik - csak ugye ezen a ponton eljő az az idő, amikor ezzel a módszerrel azért vágok ki egy másik programot, hogy legyen hova az előzőekben kivágottatt visszatölteni, had fusson egy kicsit. Utána megint mehet a levesbe, majd ismét beolvasom.
Amikor már ennyire kevés a memória, akkor természetesen ez a program sem cache-ből fog betöltődni...
Eredmény: kerreg a diszk, tetű lassú a rendszer.

Szóval nem mindenre az a megoldás, hogy swap - és ha sokat kerreg, akkor kiölöm a swap-et.

Picit értelmesebb program és/vagy cache implementáció, GC-vel rendelkező futtatókörnyezetek, stb. figyeli az OS-től jövő infót, hogy kevés-e a memória. Windowson van rá API, úgy emékszem Linuxon is. Ilyenkor a normálisan megírt progrmaok tudnának alkalmazkodni a helyzethez.

en 2GB cache hasznalat felett inditok egy sysctl vm.drop_caches=1 -et

neked aztan fura humorod van...

ha tele a memoria a sok cache miatt, unresponsive lesz a rendszer, az os nagyon lassan szabadul meg a cache-tol, flush utan amire szukseg lesz azt az ssd-rol sokkal hamarabb betolti mint hogy arra varjak hogy az os megszabaduljon a cache-tol, es hogy csak azutan induljon el a program, de lehet hogy csak nalam

neked aztan fura humorod van...

elolvastam a leirasat, de ezzel hogy kell beallitani hogy max 2GB cache-t hasznaljon, vagy ami meg jobb lenne, hogy haggyon nekem 2GB ures memoriat a gyors programinditas erdekeben?

ugyanez windows alatt is erdekelne, mert az sql szerver is ugyanilyen unresponsive mert kepes tele-cache-elni a memoriat, de itt megelegszek azzal ha a nem sql fajlok fs cache-et kidobja valami a memoriabol

koszi!

neked aztan fura humorod van...

Szerintem ezt nem lehet beállítani így. Sokkal körülményesebben talán.

Ez az opció azt mondja, hogy mennyire ragaszkodjon a cache méretéhez/tartalmához. Jelzem, hogy a disk cache-t nem érdemes visszanyesni. Elvileg gyorsítja a programok indítását. (persze egy memória gyorsaságú ssd mellet valóban nem szükséges (dehát kinek van annyi pénze)).

Az általad felvetett reszponzivitás hibát szerintem nem itt kellene keresni.

Csak akkor szólok hozzá egy témához, ha értelmét látom.

nem tudom hol keressem, ha tele a memoria cache-el akkor unresponsive, ha flusholom akkor responsive

i7-3610QM-es notebook samsung 860 evo 1TB ssd 16GB DDR3

mondjuk arra nem emlexem hogy hanyas debianban csinaltam ezt, azota upgradeltem busterre, kiprobalom hatha mar nem kell

neked aztan fura humorod van...

" ugyanez windows alatt is erdekelne, mert az sql szerver is ugyanilyen unresponsive mert kepes tele-cache-elni a memoriat, "

 

Állíts neki max %-ot, ha nem csak MSSQL fut a gépen. Mondjuk MSSQL kb. mindent maga kezel, hogy hogy akarod kidobatni vele a ramból a dolgokat. A miértet meg aztán végképp nem értem. Ha most ez egy kis méretű adatbázis, akkor eleve nem fogja teleenni a ramot. Ha nagy, de kevés user, akkor meg igazából mindegy. Ha meg nagy és sokan használják, akkor meg miért is akarsz a cachetől megszabadulni?

latszik hogy az sql process hasznal 12GB memoriat 4GB-t minden mas process es a maradek 16GB "keszenleti" amiben feltetelezem lehetnek sql fajlok amik maradhatnak, es minden mas amire viszont nincs szuksegem, csak ez utobbit szeretnem flusholni

neked aztan fura humorod van...

AFAIK SQL Server maga kezeli a cachet. Előző munkahelyemen pl. 97%-ig ki volt húzva a memóriahasználat, aminek jelentős részét az SQL Server tette ki. VM-nek volt olyan 90-95G ram adva, igaz vagy 2-300 GB-nyi adatbázisunk volt és az a VM egy dedikált SQL Server volt.

Viszont ez most egy dedikált SQL server, vagy egy fejlesztői gép? Ha fejlesztői, akkor miért nem localdb-zel? Vagy miért nem húzod vissza az SQL server beállításai közt, hogy hány % vagy hány GB ramot használhat? (Ha jól emlékszem, utóbbit is meg lehet adni).

"mégis rendszeresen megemelkedik a swout értéke."

ez számokban mit jelent?

Most olvastam, hogy a linux filesystem cache része a page cache-nek.

A swapoff kikapcsolja a fájlrendszer gyorsítását is? Annak nem úgy kellene működnie, hogy a linux minden szabad memóriát felhasznál a fájlrendszer gyorsítására, függetlenül attól, hogy van-e memórialapozás vagy sem?