linux kernel porabi po nekaj casa malo manj kot 10 GB rama?

Linux-zen kernel 4.8.6-1 za noncache, ki ga nikoli ne sprosti (razen seveda z resetom. Normalno je nekje do 2 gb ob zahtevni uporabi, oziroma par sto mb pri nezahtevni, cez cas pa zelo hitro pride na 10 GB (ni nekega posebnega opravila ob katerem se to zgodi, lahko je v idle na namizju, lahko pa premetava kupe datotek sem ter tja, predvaja kak film, poganja kak zahtevnejsi program, transcoda video iz x264 na x265 (hja prostor na disku ni zastonj :/) s handbrakom + vcasih se kak live stream preko plexa, poganja chromium s 100 + tabi, loada torrente, oziroma vse to hkrati) ki ji sprosti sele ob ponovnem zagonu. Prav tako dokler se mu enkrat ne zmesa, odvecni pomnilnik normalno sprosti nazaj. Cache dela in se sprosca/zaseda normalno (oziroma na silo v terminalu). Drugih tezav ni, racunalnik deluje hitro in stabilno, doseze tudi po 20+ dni uptima (bi lahko vec ce ga ne bi vsake toliko ugasnil da pocistim prah in podobno).

Ostale specifikacije so i5 4460 (kdaj bomo videli cenovno dostopne 16 jedernike pri enakih frekvencah in dual socket podporo), neka gigabyte plata z b85 chipsetom, 32gb rama (skoda da ne gre do vsaj 256gb :/), 1x 500 gb sata ssd + 5x3 tb hdd, to bi blo okvirno to

distribucija je arch Linux, namizje kde (ce bi imel gnome potem bi si bil itak sam kriv)

lahko dam config.gz oziroma kako drugo konfiguracijsko datoteko

Po moje ti Chromium zabija ... uf 100 tabov, saj imaš samo dve oči ...

Linux vedno porabi skoraj ves RAM. To je popolnoma normalno.

A healthy Linux system with more than enough memory will, after running for a while, show the following expected and harmless behavior:

free memory is close to 0
used memory is close to total
available memory (or "free + buffers/cache") has enough room (let's say, 20%+ of total)
swap used does not change

http://www.linuxatemyram.com

joj ste mojstri ampak res

ne govorim o temu ko nezasedeni pomnilnik rabi za cache/bufferje, to je normalno in zaželjeno

govorim o temu

smem -k -w -K /boot/vmlinuz-linux-zen

Area                           Used      Cache   Noncache
firmware/hardware                 0          0          0
kernel image                  17.9M          0      17.9M
kernel dynamic memory         26.9G      26.2G     705.0M
userspace memory               3.2G     632.3M       2.6G
free memory                  261.4M     261.4M          0

ce pogledamo pod kernel dynamic memory vidimo da skupno porablja 26.9GB, od tega je 26.2G cache (ta del ni sporen, itag ga če se rabi za kaj drugega sprosti, če maš veselje ga pa na roke)

no potem imamo pa postavko noncache v kateri je tezava, zdaj sicer ne, ampak prej ali slej zraste na okoli 10 GB in za razliko od cacha se ne sprosti, za razliko od aplikacij pa ne gre v swap no to je problem

Brane22 je 7. dec 2016 ob 02:20 izjavil:

Chromium je zelo agresiven kar se rezervacije pomnilnika tiče, tudi če ga sam compilaš, boš opazil da direktno šnjofa po headerjih kernela in je odvisen od verzije kernela.

Dogaja se, da rezervira goro RAM-a, ki ga en sprošča in ker je ta zaseden fragmentirano ( po majhnih koščkih), ko stvar preseže neko mejo in prvič trči ob omejitev sistema, postane še bolj agresiven in zatrokira cel stroj.

Stvar se sploh opazi ob velikem številu odprtih tab-ov.

hvala brane, ampak tudi če zaprem vse programe bo tistih 10 gb še vedno zasedenih

Prilepi output free -m

Aja pa še ena fora mi pade na pamet.

Pred časom so updatali virtual memory subsuystem tako, da ta omogoča alokacije huge pageov, tako da lahko rezerviraš recimo namesto standardnega 4k ali 8k framea tudi večje, recimo 2MB ali 1GB, v mejah, ki jih podaja sodobni HW.

Štos tega je zmanjšati režijsko delo kernelu, ki mu ni treba ob alokaciji recimo 256MB iskati okrog 64000 posameznih pageov, filati njihove vnose v MMU translacijsko tabelo itd.

AMpak posledica tega pa je, da mora tako področje obstajati neprekinjeno tudi v fizičnem ramu, to pa je nemogoče garantirati, če obstoječi sistem rezervira 4k pageje kjerkoli mu paše.

Okrog tega so neke frke z rezervacijo in alokacijo in ker Chrome izkorišča latest and greatest kernel fičrs, čisto možno da ob crkotju nekaj subprocesov taka področja ostanejo trajno rezervirana za alokacije hugepagov dane velikosti, tudi ko originalnih procesov, ki so to zahtevali, ni več.
Kako bi to preveril, mi brez branja dodatne dokumentacije, trenutno ne pade na pamet.

Eh, shekali so ti stroj, pa sedaj gostuješ otroško pornografijo v tistih skrivnostnih gigabajtih.

Šalo na stran, poženi free, top (s < > sortiraj po različnih stolpcih porabe pomnilnikov), vmstat, grepaj in sortiraj VM po /proc/*/status, pa boš morda pametnejši.

Poskriptaj reliably reproducible test case, preveri če lahko ponoviš na zadnjem vanilla kernelu in če ja, pojdi vprašat na lkml.

Top 10 procesov po kurjenju RAM-a:

ps -auxf | sort -nr -k 4 | head -10

Tole trolaš. Normalno lahko cache le prisilno izprazniš oziroma izklopiš za določen ukaz. Edino če si kernel sam popravljal :) Pa tudi sicer mi ni jasna prednost konstantne uporabe brez ...

zakaj misliš da je to troll post?

noben os ni kritiziran za bv, problem ki se je pojavil je lepo predstavljen, predstavljene so tudi rešitve, ki sem jih probal in končna ugotovitev da sem naložil malo novejšo verzijo kernela in rahlo spremenil nastavitve pri kompilanju, kar zgleda kot da je odpravilo težavo (potrka na les)... od včeraj je noncache kernel memory med 300 in 400 mb in ne raste.. lepo bi bilo vedeti sicer zakaj je do tega sploh prišlo, ampak oh well

hja možno, se bom s tem ukvarjal če se ta težava spet pojavi, zaenkrat je uptime že več kot en dan kernel non cache poraba pa še vedno med 300 in 400 mb :)

maš mogoče kak link do tega?

drugače je ta verzija od 6. decembra in je malo pred stock 4.8.12 tako da mogoče je že not popravek

hvala, sem pogledal pa zgleda je v 4.8.12-2 že not (v -1 pa ne)