Dosta cesto imam ozbiljnih problema sa memory managementom na Macu, u smislu da mi naraste inactive memory na stetu free memory, a algoritam za ciscenje cache-a ocito ima svojih mana.

Naravno, free memory = wasted memory, i super je da se koristi kao cache (to rade svi danas moderni os-ovi), ali garbage collector je lose implementiran na Mac os x, i to čini mi se od verzije 10.5. Na 10.6 sam to ozbiljnije primjetio (jer sam presao na 64-bit), a na 10.7 Lionu mi se stroj poceo "zabijat".

Kako su scenariji koji dovode do ovog problema bili razliciti, i nema bas strogog pravila da ce uvijek u istom trenutku problem iskrsnuti, malo sam se pozabavio problematikom, te slozio test case, koji mi uvijek dovodi do ovoga problema. Snimio sam screen video, i stavio na youtube, pa tko zeli neka pogleda, meni je cak smijesno i zabavno



Dakle, koristim tar+gzip nad Pictures folderom, namjerno sa velikom kolicinom datoteka ... Prije pokretanja pustim "purge" da se ocisti cache, i krenem sa cca. 4,8 GB free memorije, a inactive nekih 40 mb. Ubrzo se inactive pocinje povecavati, i nakon 10 minuta, ostanem sa free memorijom ispod 100 mb. Sam bsdtar proces zauzim par mb memorije, tako da ne mozemo govoriti o memory leaku procesa. Tada pokrenem prvo Safari, pa iPhoto, pa Word ... Safari se podize preko 1 minute. Primjetimo da os pocne swapat blokove na disk, pa prijavljuje page out-e. Sa iPhoto je valjda još gore ...

Inače, web je krcat sa prituzbama na ovakav nacin upravljanja memorijom u os x-u, i ocito se radi ili o lose napisano algoritmu gc-a, ili je jednostavno bug. apple naravno, niti na svojim community forumima, ne komentira.

Jedno od rjesenja je da se iskljuci dynamic pager, ali to je ruzan hack, i u slucaju ako ne vodite racuna, i zauzme se cijeli RAM, dobit cete kernel panic, i vjerojatno freeze cijelog sistema ...

Inače stroj je:
sysinfo:
Model Name: MacBook Pro
Model Identifier: MacBookPro6,2
Processor Name: Intel Core i7
Processor Speed: 2,66 GHz
Number of Processors: 1
Total Number of Cores: 2
L2 Cache (per Core): 256 KB
L3 Cache: 4 MB
Memory: 8 GB

vm_stat i top izgledaju ovako kad nastupe problemi:
top:
Processes: 88 total, 3 running, 10 stuck, 75 sleeping, 485 threads 20:23:36
Load Avg: 2.82, 4.02, 3.38 CPU usage: 18.16% user, 5.18% sys, 76.65% idle SharedLibs: 664K resident, 0B data, 0B linkedit.
MemRegions: 19262 total, 875M resident, 52M private, 1567M shared.
PhysMem: 1148M wired, 1990M active, 4954M inactive, 8092M used, 98M free.
VM: 204G vsize, 1091M framework vsize, 8619895(9) pageins, 6664(0) pageouts.
Networks: packets: 13319885/8926M in, 14377064/13G out. Disks: 2472664/92G read, 1805914/61G written.

vm_stat:
Mach Virtual Memory Statistics: (page size of 4096 bytes, cache hits 0%)
free active spec inactive wire faults copy 0fill reactive pageins pageout
1826 512463 15872 1272373 294131 1435177K 8888972 529309K 122377 8620058 6664


Evo par linkova:
workstuff.tumblr.com/post/20464780085/so...-x-memory-management
https://plus.google.com/116685507294337280246/posts/camYp28M9St
blog.dans.im/post/659478311/mac-os-x-10-...ory-management-fixed

Ja se ne kužim toliko da bi komentirao sve ove gore navode, ali činjenica je da nešto gadno ne štima... Radim na MacPro sa 24GB RAM-a i jako često ostanem sa oko ili čak ispod 100MB slobodne memorije. Nedavno sam prešao sa Lightrooma 3.6 na 4.0 i mislio dam da je to LR memory leak problem, ali izgleda da ipak nije. Kad radim sa iPhotom isto se događa, dobro, ne pojede svu memoriju kao LR ali imam jako puno neaktivne memorije. Sistem je 10.7.3

Možeš li mi objasniti kako ti misliš da bi OS trebao "upravljati memorijom"? Aplikacija je ta koja zauzme memoriju, i dok ju ta ista aplikacija ne oslobodi sve što OS može je prebaciti dio zauzete memorije na swap ako nedostaje fizičke.

Ako stroj nema dovoljno fizičke memorije tada se pojavljuje još jedan problem, a to je fragmentacija memorije. Tako da u tom situaciji OS mora swap-ati čak i kad zbrojeno zauzeće memorije svih aplikacija ne prelazi veličinu fizičke memorije.
Ono što "purge" odradi je defragmentacija slobodne memorije. Totalno nepotrebna operacija kad se uzme o ubzir da "purge" sam po sebi troši CPU resurse, a sustav će ionako sam po sebi opet završiti u istom stanju kako budeš pokretao ili zatvarao pojedine aplikacije, odnosno kako pojedine aplikacije budu zauzimale ili oslobađale memoriju.

Aplikacije na OS X-u mogu ali nemoraju koristiti Garbage Collection. Naime postoje i drugi načini baratanja memorijom u aplikaciji kao što su:
- direktno malloc/free/brk/sbrk (to koriste tar i gzip)
- Reference Counting
- ARC (Automatic Reference Counting - postoji tek od Lion-a)

Pritom je GC po pitanju zauzeća memorije najgori jer najdulje drži memoriju zauzetu.

Sve u svemu nije bitno koliko piše da ima memorije slobodne, već koliko treba sustavu da odradi posao (pravi posao, a ne prazni benchmarki ili beskorisno izvršavanje tar+gzip) koji od njega tražiš.
Referenca za to bi ti moglo biti:
1. Mjeri vrijeme za taj posao bez da koristiš purge
2. Mjeri vrijeme za taj isti posao + vrijeme izvršavanja "purge"

Problem je što ljudi imaju neku svoju predodžbu što bi neaktivna i slobodna memorija trebale predstavljati.
Najbolje je ne gledati koliko piše da ima neaktivne ili slobodne memorije. Jedino što treba gledati je da li sustav konstantno swap-a, te u tom slučaju dodati još RAM-a (poželjno dodati i ako ne swap-a jer će sve brže raditi).
To je ujedno i razlog zašto Apple ne omogučava korisnicima da na iOS-u gledaju koliko imaju slobodne memorije: za to naprosto nema potrebe, a ljudi imaju naviku to krivo interpretirati.

Recimo moj sustav konstantno swap-a a imam 24GB Ram-a ....?

Ako postoje swap datoteke, odnosno swap zauzeće to ne mora značiti da sustav konstantno swap-a, već može biti da je samo jednom u prošlosti (od bootanja) došao u situaciju da je morao swap-ati.
Ako ti se uspori dovoljno da ti smeta, onda kupi još RAM-a.
Ako je tko kriv za zauzeće memorije to su aplikacije, a ne OS X.

Pa ne rendam ja HD Video, je istina da radim sa dosta RAW fotografija i relativno velikim LR Library-jem ali ne kužim, da kupim 100GB Rama, pa 24GB bi trebalo biti više nego dovoljno? Činjenica je da nakon nekog vremena ostanem sa hrpetinom neaktivne memorije i da se krene punit "page out" Nadam se samo da je do LR-a i da će bit riješeno sa novim update-om....

Num, mislim da ili nisi pažljivo pročitao što ljude muči, ili posve pogrešno interpretiraš pojam "inactive" memorije. Nedavno smo o tome ovdje pisali. Inactive memorija je ona koja je donedavno bila korištena, a sustav je čuva za slučaj da opet pokrenemo istu aplikaciju koju smo nedavno quitali, ili da opet otvorimo isti dokument koji smo maločas zatvorili. No, *SUSTAV* (ne aplikacija) je taj koji inactive memoriju mora *OSLOBODITI* za korištenje prije nego krene swapati.

Ako zafali free memorije, a nema ni inactive (dakle, sva je ili used, ili wired), onda ide swap i za takvu situaciju može biti kriva aplikacija i eventualno može pomoći još RAM-a

Ako zafali free memorije, a inactive memorije ima ko salate, a sustav krene swapati umjesto da dealocira inactive u free i uzme si to - e to je problem OS-a. Čega drugog bi bio?

@smayoo: dobro si opisao što je neaktivna memorija, no nažalost stvar je malo složenija:
Kako je neaktivna memorija donedavno bila korištena, velika je šansa da je fragmentirana, tako da ako neka aplikacija želi alocirati veći komad memorije, tada bez obzira što ukupno gledano ima dovoljno slobodne+neaktivne memorije sustav mora swap-ati ako unutar slobodnih i neaktivnih blokova memorije nema dovoljno velikog kontinuiranog bloka memorije koji bi se mogao korititi za alociranje, Tu OS stvarno nema izbora.
Neznam za OS X kernel, no neki drugi kerneli (npr. BSD) imaju opciju preuranjenog swap-anja. To omogućava brže pokretanje novih procesa kada se već unaprijed zna da će se morati swap-ati jer će memorija za novi proces biti odmah raspoloživa jer su unaprijed dijelovi memorije koji se ne koriste prebačeni na swap. Na administratoru je da tu opciju uključi ako misli da bi dala bolje performanse. Naravno, dodati još RAM-a je bolje rješenje.

Btw. neaktivnu memoriju netreba oslobađati jer to već je oslobođena memorija, odnosno ukupna raspoloživa (slobodna) memorija je "free"+"inactive".

Nije već oslobođena, jer bi onda bila "free", nego je određena da se može osloboditi ako zatreba. No, da skratimo, da slažem se da problem može nastati ako je memorija fragmentirana, ali mislim da to nije slučaj u problemima koje opisuju emilio i stain. Tu se veliki komadi memorije i alociraju, i dealociraju, ali ih OS ne pušta iz inactive u free.

Ja sam kod sebe baš išao napraviti test (na 10.6.5) sa svojih 8 GB RAM. Digao sam virtualku Windowse kojima VitualBox rezervira (wired) 2,5 GB, povrh toga imam još 1,5 GB Active (za tko zna što sve), Inactive sam pokretanjem i quitanjem aplikacija nagurao na 3,92 GB, a free mi je ostao na 80 MB (give or take). Daljnjim pokretanjem aplikacija i otvaranjem dokumenata (npr. AutoCAD, poznati žderač resursa, + ogromni nacrti), Free memorija pliva od 80 do 11 MB, Inactive se pomalo smanjuje, Active se povećava, ali od swapanja ni "s". Dakle, sve radi kako bi trebalo raditi.

> Možeš li mi objasniti kako ti misliš da bi OS trebao "upravljati
> memorijom"? Aplikacija je ta koja zauzme memoriju, i dok ju ta ista
> aplikacija ne oslobodi sve što OS može je prebaciti dio zauzete memorije
> na swap ako nedostaje fizičke.
Mislim da nisi shvatio problem. Ovdje se radi o problemu sa "inactive" memorijom. Time upravlja OS pomoću cache/buffer algoritama. Ista funkcionalnost postoji na svima modernim OS-ovim danas, samo se različito zove. Stvar je u tome što OS X iz nekog razloga prioritetno alocira prostor za program data (npr. files, pics, bitmaps ... ), u smislu da ga ne pregazi i dodjeli prostor u free ram, kada je potrebno resursa za novi proces. U konkretnom slučaju (i ostalim primjerima što ljudi prijavljuju po forumima), aktivira se dynamic pager koji swap-a sadržaj inactive memorije na disk, jer smatra da to treba ostati u memoriji (točnije VM-u). Aplikacija to uopće ne primjećuje, to je za same user procese potpuno transparentno.

> Ono što "purge" odradi je defragmentacija slobodne memorije. Totalno
> nepotrebna operacija kad se uzme o ubzir da "purge" sam po sebi troši
> CPU resurse, a sustav će ionako sam po sebi opet završiti u istom stanju
> kako budeš pokretao ili zatvarao pojedine aplikacije, odnosno kako
> pojedine aplikacije budu zauzimale ili oslobađale memoriju.
Ne radi se o defragmentaciji !

purge(8) BSD System Manager's Manual purge(8)
NAME
purge -- force disk cache to be purged (flushed and emptied)
SYNOPSIS
purge
DESCRIPTION
Purge can be used to approximate initial boot conditions with a cold disk
buffer cache for performance analysis. It does not affect anonymous mem-
ory that has been allocated through malloc, vm_allocate, etc.


> Aplikacije na OS X-u mogu ali nemoraju koristiti Garbage Collection.
> Naime postoje i drugi načini baratanja memorijom u aplikaciji kao što su:
> - direktno malloc/free/brk/sbrk (to koriste tar i gzip)
> - Reference Counting
> - ARC (Automatic Reference Counting - postoji tek od Lion-a)
Opet, nisi razumio. Ovdje se misli na GC algoritam vm managera, kada anonymus data iz "inactive" memorije treba počistiti. Ti misliš na kodiranje aplikacija sa gc-om (npr. objective-c 2 gc)

> Sve u svemu nije bitno koliko piše da ima memorije slobodne, već koliko
> treba sustavu da odradi posao (pravi posao, a ne prazni benchmarki ili
> beskorisno izvršavanje tar+gzip) koji od njega tražiš.
Prazan benchmark ?! Čovječe, tar+gzip/bzip se masovno koriste za automatizirane backup-e, pogotovo na serverima. Ja sam prikazao primjer gdje VMM OS-a uvijek radi na nacin koji sam opisao kao problematican (greska algoritma), a taj primjer je nista drugo nego moje bash skripte za backup

num kaže:

Ovdje se upravo radi o tome da OS, točnije dynamic_pager pocne sa nepotrebnim swapanjem, umjesto da jednostavno i jeftino dealocira "inactive" i na taj način oslobodi prostor u free, koji je potreban za druge ili nove procese. Ja sam poceo promatrati memoriju na MAC-u upravo zbog ovih anomalija, kada mi sustav drasticno uspori iz nikakvog razloga. swapanje zaista jest uzrok globalnom usporavanju rada os-a (jer to radi prioritetno), ali uzrok toga swapanja se vidi promatranjem memorije: top, vn_stat, purge, shark ...

num kaže:

točno to, tako kaže i apple. ali, očito nije uvijek tako, jer često inactive ne želi dealocirati. razlog je upravo gc algoritam VMM-a.

Btw, ovo nije problem specifican za OS X. To su prije bile boljke *BSD-a, i Solaris-a, jer su algoritmi očito pisani sa manjim količinama RAM-a na umu (ili neznam što). Koliko mi je poznato, i FreeBSD i Solaris su se na tome polju modernizirali ... a negdje sam našao da OS X još ima paging algoritme iz Solarisa 2.7 (dakle 90-ete)

Btw, probao sam sa iskjucenim Spotlight servisom:
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
Ista stvar.

Probao sam samo tar, bez bzip/gzip.
Ista stvar.

Evo primjer, računalo je upaljeno cca 45 minuta, jedino što sam na njemu radio je import i rendering standard size preview fotografija u LR cca 40GB Raw fotografija i bez obzira na hrpetinu neaktivne memorije krenulo je svapanje....

Moj ad hoc komentar bi bio da je problem u nekim aplikacijama koje "cure". Radim na Mac Pro s Lionom i nemam nikakvih problema tog tipa, dapače nedavno sam bio nabrojao 50 dana uptimea s preko 5 milijuna page-ina i samo 115 page-outa.

Većinom koristim zadnji Adobe CS, iWork i OpenOffice. Glavni browser mi je Safari, ponekad dignem Firefox kada zeza Flash na Safariju. Ne koristim Lightroom.

Evo moje trenutačno stanje nakon 16(!!!) dana od restarta:

Davore, ajde malo osjećaji off i logika on. Pogledaj Stainov screenshot. Ima 19,8 GB (slovima: DEVETNAEST ZAREZ OSAM) inactive (ponavljam: INACTIVE)) memorije.

Ako je memorija inactive, onda ju je aplikacija otpustila. Ako ju je otpustila, kakve veze ima čak i da curi? To može biti problem jedino OS-a, ako on kraj tolike inactive memorije swapa na disk.

Ili imaš neko drugo (logično) objašnjenje?

Da je problem vezan samo za OS onda bismo ga svi imali, a to očigledno nije slučaj. Meni ništa ne curi/otpušta/ne-otpušta s aplikacijama koje ja koristim, stroj radi i po preko 50 dana do nekog restarta i potpuno bez swapa. Ako on već nakon sat vremena ima problem (što se vidi iz screenshota), a ja nemam niti nakon 16 dana (a nije bilo problema niti nakon 50) očigledno je da postoji kombinacija koja radi problem i koju je on "ubo".

Dakle, moja logika kaže da se to pojavljuje samo u nekoj kombinaciji OS-a i aplikacija. Ovdje po opisu izgleda očigledno da Lion i Lightroom imaju problem. Možda ga Snow i Lightroom nisu imali? Možda jesu?

Kao Adobe Reseller mogu zatražiti NFR (not for resale) kopiju za demo, pa kada je nabavim ću instalirati i baš probati da li i meni radi problem. Vjerujem da je u tome štos.

Slažem se da je očito problem u nekoj kombinaciji. Ali sa strane OS-a, a ne aplikacije (jer aplikacija nema više nikakav utjecaj na memoriju koja je inactive). Ajde, probaj, Zanimljivo bi bilo vidjeti rezultat (naime, može biti da nije stvar u Lion+Lightroom samo. Možda ima veze još nešto.).

Ovo ne dokazuje da postoji problem. Jednako ponašanje sam vidio i na Linux i FreeBSD serverima koji se nikad ne gase. Evo scenarija u kojima se to može dogoditi:

1. Prethodna aktivnost na računalu je tražila dovoljno memorije da je bilo potrebno korištenje swap-a. Nakon toga su se potrebe za memorijom smanjile (pojavila se velika količina neaktivne memorije), no zauzeće swap-a i dalje ostaje. To je u potpunosti ispravno ponašanje. Swap ne mora biti odmah oslobođen (nema potrebe).

2. Pageout algoritam pamti kad su zadnji put korištene pojedine stranice memorije. U svrhu ubrzanja rada računala, taj isti algoritam može neke od tih stranica prebaciti (pojednostavljujem da bude razumljivije, u stvarnosti može biti više koraka) na swap kako bi se još memorije oslobodilo za druge aktivnosti (pokretanje novih aplikacija, cache-iranje diska, itd.). Tu algoritam mora napraviti cost/benefit procjenu koja u nekim situacijama korisniku možda i ne djeluje kao najbolji izbor.

@stain: "swap used" nije swap-anje već zauzeće swap diskovnog prostora. Samo zauzeće ne govori ništa o tome da li u tom trenutku OS radi page-in ili page-out (swap-anje).
Zauzeće swap diskovnog prostora bez swap-anja ništa ne usporava, pa OS niti nema potrebe da ga oslobodi prije vremena.

Eto, i ovo što kaže Num ima logike. Pravo pitanje je da li se stroj zaista fizički uspori kada dođe do toga, postoji li osjetno usporenje u obradi i snimanju fotografija nakon te "anomalije"?

O tome je Stain već pisao u drugom threadu. Da, uspori mu se.

dpasaric kaže:

Sve je moguce. Ali posto se radi o disk cache/buffer-u, koji primarno sluzi da aplikacije pri ucitavanju program data svaki put ne kopaju po disku, sumnjam. To ne bi trebalo imati nikakve veze sa user aplikacijama, to su mehanizmi vm managera, tj. kernela.

Stain kaže:

da bis mogao pratiti u realtime-u swapanje na disk, koristi vm_stat sa definiranim intervalom, npr. status (tj. delta) svakih 5 sec:

Ok, ljudi nije me bilo par dana a vidim da su se u temu uključili ljudi kojima vjerujem

Kako sam i napomenuo ovdje ili u nekom drugom threadu, ne kužim se dovoljno da bi mogao davati točne informacije. Mislim na ono Num-ovo da swap used nije swapanje itd...

Danas me ceka hrpetina posla u LR i sve što mogu napraviti je svako nekoliko napraviti screen shoot activity monitora uz opis koje su aplikacije bile korištene (ako takvo što može pomoći nekome da mi definira problem) Da li je dovoljan screen shoot samo onog dijela AM koji sam već postao ili treba još nešto poslikat?

Ovo je stanje nakon 2 dana, naravno da sam koristio "free memmory" više puta, zato trenutno nije zauzeta kompletna memorija....

Ovo je stanje nakon restarta, aktivne app. Mail, Safari, iCal, Activity monitor...

Prijavio sam bug Apple-u, putem http://bugreport.apple.com
Nakon par dana dobio sam odgovor da "This bug has been closed as a Duplicate. The issue is being tracked under under the original Bug ID# ........ which is also listed in the Related Problem section of your bug report."

Da li netko zna kako otvoriti prijavljeni bug od neke druge osobe/korisnika ? Meni je u izvjestaju samo navedeni bug id#, od kojeg je moj kao duplikat, ali ne mogu ga otvoriti ...