Newsgroup: it.comp.macintosh
Titolo: memoria inattiva, vorrei capire una cosa

stando a questo 
http://support.apple.com/kb/ht1342
, la memoria
inattiva contiene "informazioni presenti nella memoria [che]
attualmente non vengono utilizzate, ma sono state utilizzate di
recente".
il suo contenuto viene liberato automaticamente quando la memoria
libera scende sotto una soglia minima, e lo spazio spostato nella
seconda (
http://developer.apple.com/library/mac/#documentation/
Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html)
ora, io mi aspetterei quindi che ad un certo punto la dimensione di
memoria inattiva cali e quella libera aumenti. o al massimo (a parita'
di "carico"), cali la prima e aumenti la memoria attiva (l'inattiva
viene liberata ma subito assegnata)
invece...
la situazione piu' comune di uso del mio mac (MacBookPro5,5) e' avere
tra i tre e i quattro browser differenti aperti (firefox, webkit,
chrome e flock), insieme a netbeans e la shell. spesso succede che al
refresh di una pagina sui browser o alla modifica di un file su
netbeans il sistema si blocca: unico segno di vita il movimento del
mouse, tutto il resto rimane appeso e c'e' da attendere un bel po' di
secondi prima che torni disponibile.
se controllo lo stato della memoria, su 4gb qualche centinaio di mega
sono wired, oltre il giga e' inattivo, e pochi mega (tra i 20 e 70)
liberi. i blocchi si verificano sempre quando la quantita' di memoria
libera e' a questa soglia minima.
se forzo la svuotamento della memoria inattiva (comando purge, da
shell, disponibile con xcode installato), alcune operazioni rallentano
(soprattutto il lancio di applicazioni appena chiuse), secondo appunto
la logica di gestione dell'inattiva. ma non si verificano blocchi.
il dubbio, quindi, e' che la memoria inattiva influisca sulla
responsivita' di certe operazioni ma non di altre, e che 30mb di
memoria libera, indipendentemente dalle dimensioni della prima, creino
problemi.
le cose che vorrei capire sono due:
1. e' normale che l'inattiva ci metta tanto a svuotarsi? noto che in
linea di massima continua a crescere, invece di diminuire o rimanere
stabile (bilanciando il contenuto in ingresso con quello svuotato),
anche questo e' "corretto"? da quanto ho capito quello che passa per
l'inattiva viene paginato su disco, se il disco e' lento il ricorso
all'inattiva potrebbe per assurdo avere performance negative, e' una
considerazione valida?
2. come si fa a capire se il collo di bottiglia sta sulla ram o sul
disco (intendo in ogni caso relativamente alla gestione della
memoria)? io credo che il problema si verifichi quando il sistema si
trova a dover "insistere" sulla memoria inattiva, che richiede piu'
operazioni disco rispetto alla libera, e da li' il blocco.
in generale, preferisco aspettare un po' di piu' all'apertura di un
programma, che vedere la macchina bloccata, quindi sto prendendo
l'abitudine di lanciare il purge quando inizio a notare le prime
instabilita' ;)

 instabilita' ;)
IMHO hai problemi da qualche altra parte, non e' sicuramente la memoria
inattiva che ti fa i blocchi.
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 pi� utilizzata, non so i sistemi posteriori
fino a tiger non venivano cancellati i swapfiles (in /var/vm) se non
quando non c'era loggato nessuno (o ad un poweroff).
Da Leopard in poi la cosa viene gestita meglio.
Ma la memoria inattiva non c'entra niente con gli swapfiles.


 inattiva che ti fa i blocchi.
dalla solita pagina:
<<A memory access fault occurs when code tries to access data at a
virtual address that is not mapped to physical memory.>>
che porta a questo:
<<The active list contains pages that are currently mapped into memory
and have been recently accessed.
The inactive list contains pages that are currently resident in
physical memory but have not been accessed recently.>>
che differenza c'e' tra mappata e residente?
direi cmq che il problema sta qui:
<<Disk thrashing can occur when the system spends a disproportionate
amount of time handling page faults and reading and writing pages,
rather than executing code for a program.
Paging of any kind, and disk thrashing in particular, affects
performance negatively because it forces the system to spend a lot of
time reading and writing to disk. Reading a page in from the backing
store takes a significant amount of time and is much slower than
reading directly from RAM. If the system has to write a page to disk
before it can read another page from disk, the performance impact is
even worse.>>
"incolpo" la sproporzione tra inattiva e libera perche' nei casi di
blocco che ho sperimentato presumo che non venga sfruttata la prima,
ma sia necessaria della libera. se ce ne fosse a sufficienza le
operazioni di paging dovrebbero essere minori rispetto a dover
svuotare l'inattiva. da qui il disk trashing maggiore.

 svuotare l'inattiva. da qui il disk trashing maggiore.
Ascolta, cercati un qualche sito in italiano dove ti si spiega come
funziona la memoria sotto UNIX (magari con qualche disegno), poi ne
riparliamo.


 incolpi, ma sbagli.
mi fiderei anche, devo ancora decidere se di te o della documentazione
ufficiale apple. fatemi sapere se venite ad un compromesso

 ufficiale apple. fatemi sapere se venite ad un compromesso
io e la doc ufficiale diciamo la stessa cosa. Sei tu che la interpreti
come fa comodo a te.


 come fa comodo a te.
<<When the number of pages on the free list falls below a threshold
(determined by the size of physical memory), the pager attempts to
balance the queues. It does this by pulling pages from the inactive
list.>>
<<la memoria inattiva (e funziona cosi su tutti i sistemi *nix),
viene
liberata quando un programma ha bisogno memoria e non ce n'e'
abbastanza
di libera. non prima.>>
per essere precisi, eh :1
a me non fa comodo nulla, semplicemente mi interessa capire da cosa e'
procurato tutto il disk trashing che sperimento (e possibilmente
risolvere il problema)
e per capirlo indico il fatto che avviene quasi esclusivamente in
condizioni di sproporzione tra memoria libera e memoria inattiva
(rapporto di almeno 1:10 a sfavore della prima). quindi molto
banalmente inizierei a cercare da li'. se mi continui a ripetere che
il problema e' altrove senza specificare dove non e' che vada molto
lontano.
o, per rigirarla, se il problema non e' l'inattiva, qual e'?
la mia ipotesi (forse non mi sono espresso in maniera abbastanza
chiara) e' che il problema nasca dal collo di bottiglia dell'accesso
al disco che si verifica in alcune condizioni che riguardano "lo
stato" della memoria inattiva in relazione al resto della memoria. se
e' un problema addossare qualsiasi responsabilita' all'inattiva rigiro
la frase: le condizioni riguardano lo stato della memoria libera
rispetto al resto ;)

 rispetto al resto ;)
ma sei sicuro che il computer faccia disk thrashing? i valori di pagein
e pageout come sono (specialmente quelli di pageout)?
lo puoi vedere con il top.
E cmq se comincia a swappare come un matto (e di solito il finder in
questo caso ti mostra la beach ball) la soluzione e' una sola: aumentare
la RAM.


 la RAM.
la mostrasse solo il finder la beach ball!
btw, snow leopard chiede 1GB di memoria, ne ho 4 ;)

 btw, snow leopard chiede 1GB di memoria, ne ho 4 ;)
e' il finder che gestisce il puntatore, e' lui che ti mostra la beach
ball, anche se hai il focus su un'altra applicazione.
si, ma se hai 4 browser, netbeans e altro attivi i 3 GB restanti
finiscono in fretta.
Ciao Jack