# ram tutta occupata [unsolved ]

## manang

salve, ho il mio sistema che usa più ram di windows vista

mi spiego meglio

col tempo X alloca memoria, fino a quando non occupa anche lo swap

ho gli ultimi driver ati  e l'ultimo kernel 

sapete se c'è risposta?

il problema è che mettere il driver più vecchio è più macchinoso perchè non è compatibile con il kernel 2.6.25(a meno di fare lunghe e noiose modifiche)

salve

angelo mantellini

----------

## darkmanPPT

Sembrerebbe un problema di deallocazione di memoria.

Siccome non credo che X abbia questi problemi, io propenderei per i driver ATI

uhm...

prova a cambiare driver (magari la versione esattamente precedente) e vedere se la cosa si risolve...  :Rolling Eyes: 

se hai gli ati-drivers-8.493

prova ati-drivers-8.476

dovrebbero sempre andare sul tuo kernel, no?

----------

## manang

no, non si installano sul kernel.

mio fratello (comio ) mi ha detto di un memory leak di ati e compiz.

quindi siccome non ho ho compiz installato, sicuramente è un problema di ati

vabè, mi arrangio, ciao e grazie

----------

## Peach

 *manang wrote:*   

> no, non si installano sul kernel.
> 
> mio fratello (comio ) mi ha detto di un memory leak di ati e compiz.
> 
> quindi siccome non ho ho compiz installato, sicuramente è un problema di ati
> ...

 

se pensi sia questa l'unica (non) soluzione, aggiorna il titolo del primo post con un "[unsolved]" e magari aggiungici pure "colpa di ati"  :Razz: 

----------

## .:deadhead:.

potresti provare i drivers open per ATI, magari la situazione migliora, anche se a discapito del 3d.

----------

## devilheart

mi succede la stessa cosa con i driver nvidia però. il problema è iniziato a manifestarsi quando ho abbassato il valore di swappiness a 20. ora l'ho rimesso al valore di default (60), vediamo se si risolve

----------

## Kernel78

 *devilheart wrote:*   

> mi succede la stessa cosa con i driver nvidia però. il problema è iniziato a manifestarsi quando ho abbassato il valore di swappiness a 20. ora l'ho rimesso al valore di default (60), vediamo se si risolve

 

beh, abbassando la swappiness aumenti la tendenza ad usare la ram invece della swap quindi è ovvio che ti risultasse più memoria usata ...

----------

## devilheart

 *Kernel78 wrote:*   

>  *devilheart wrote:*   mi succede la stessa cosa con i driver nvidia però. il problema è iniziato a manifestarsi quando ho abbassato il valore di swappiness a 20. ora l'ho rimesso al valore di default (60), vediamo se si risolve 
> 
> beh, abbassando la swappiness aumenti la tendenza ad usare la ram invece della swap quindi è ovvio che ti risultasse più memoria usata ...

 si ma non è normale un aumento così rapido senza aprire altre finestre e anche dopo aver rimesso il parametro al valore di default

----------

## Kernel78

 *devilheart wrote:*   

>  *Kernel78 wrote:*    *devilheart wrote:*   mi succede la stessa cosa con i driver nvidia però. il problema è iniziato a manifestarsi quando ho abbassato il valore di swappiness a 20. ora l'ho rimesso al valore di default (60), vediamo se si risolve 
> 
> beh, abbassando la swappiness aumenti la tendenza ad usare la ram invece della swap quindi è ovvio che ti risultasse più memoria usata ... si ma non è normale un aumento così rapido senza aprire altre finestre e anche dopo aver rimesso il parametro al valore di default

 

Non sono un esperto del kernel e tu non hai dato dati oggettivi da valutare ma se la swap contiene dei dati e tu modifichi la swappiness io mi aspetto proprio che l'occupazione della ram aumenti rapidamente perchè il sistema si adatta spostando parte della swap in memoria ...

Magari se tu fornissi dati più accurati sarebbe possibile fare un'analisi meno spannometrica della tua situazione ...

----------

## comio

 *Kernel78 wrote:*   

>  *devilheart wrote:*    *Kernel78 wrote:*    *devilheart wrote:*   mi succede la stessa cosa con i driver nvidia però. il problema è iniziato a manifestarsi quando ho abbassato il valore di swappiness a 20. ora l'ho rimesso al valore di default (60), vediamo se si risolve 
> 
> beh, abbassando la swappiness aumenti la tendenza ad usare la ram invece della swap quindi è ovvio che ti risultasse più memoria usata ... si ma non è normale un aumento così rapido senza aprire altre finestre e anche dopo aver rimesso il parametro al valore di default 
> 
> Non sono un esperto del kernel e tu non hai dato dati oggettivi da valutare ma se la swap contiene dei dati e tu modifichi la swappiness io mi aspetto proprio che l'occupazione della ram aumenti rapidamente perchè il sistema si adatta spostando parte della swap in memoria ...
> ...

 

è un memory leak in X/Ati...

ciao

luigi

----------

## Kernel78

 *comio wrote:*   

> 
> 
> è un memory leak in X/Ati...
> 
> 

 

Anche se devilheart ha nvidia ?

----------

## devilheart

 *Kernel78 wrote:*   

> Non sono un esperto del kernel e tu non hai dato dati oggettivi da valutare ma se la swap contiene dei dati e tu modifichi la swappiness io mi aspetto proprio che l'occupazione della ram aumenti rapidamente perchè il sistema si adatta spostando parte della swap in memoria ...
> 
> Magari se tu fornissi dati più accurati sarebbe possibile fare un'analisi meno spannometrica della tua situazione ...

 si ma io non ho usato il sistema. ieri sera ho fatto un esperimento. prima di uscire ho fatto il login, ho aperto un terminale e ho visto il processo X occupare circa 60 MiB di ram. stamattina era a più di  900. in 10 ore non è stato lancato nessun programma, non c'era attivo nessun programma che facesse un qualsiasi tipo di operazione (calcoli, i/o, screensavers) e né il mouse né la tastiera sono stati toccati. semplicemente più tempo passava e più ram si mangiava X

----------

## Kernel78

 *devilheart wrote:*   

> si ma io non ho usato il sistema. ieri sera ho fatto un esperimento. prima di uscire ho fatto il login, ho aperto un terminale e ho visto il processo X occupare circa 60 MiB di ram. stamattina era a più di  900. in 10 ore non è stato lancato nessun programma, non c'era attivo nessun programma che facesse un qualsiasi tipo di operazione (calcoli, i/o, screensavers) e né il mouse né la tastiera sono stati toccati. semplicemente più tempo passava e più ram si mangiava X

 

si ma questo ti eri ben guardato dal dirlo, anzi eri stato tu a dire che il problema aveva iniziato a presentarsi da quando avevi impostato la swappiness a 10. Io mi sono limitato a fare un ipotesi sui dati che ci avevi fornito ...

Non è che magari adesso salta fuori che hai tutto il sistema in ~ ?  :Wink: 

----------

## devilheart

 *Kernel78 wrote:*   

> si ma questo ti eri ben guardato dal dirlo, anzi eri stato tu a dire che il problema aveva iniziato a presentarsi da quando avevi impostato la swappiness a 10. Io mi sono limitato a fare un ipotesi sui dati che ci avevi fornito ...

 però ho detto che ho rimesso il parametro al valore di default e il problema è continuato

 *Quote:*   

> Non è che magari adesso salta fuori che hai tutto il sistema in ~ ? 

 ovvio e non intendo cambiare. comunque non può essere la causa. è da un bel pezzo che non tocco pacchetti importanti (toolchain, xorg, driver nvidia) e il problema è comparso da un paio di giorni

----------

## Kernel78

 *devilheart wrote:*   

>  *Quote:*   Non è che magari adesso salta fuori che hai tutto il sistema in ~ ?  ovvio e non intendo cambiare. comunque non può essere la causa. è da un bel pezzo che non tocco pacchetti importanti (toolchain, xorg, driver nvidia) e il problema è comparso da un paio di giorni

 

Lungi da me spingerti a cambiare, i rispetto tutti, anche i masochisti. Semplicemente metto da parte ogni mio tentativo di aiutarti visto che hai deciso di usare una distribuzione "non stabile" per definizione.

Hai seguito la guida ? *Quote:*   

> La branca di test è esattamente ciò che significa: In fase di test. Se un pacchetto è in fase di test, significa che gli sviluppatori pensano che sia funzionante ma non ancora testato in maniera esauriente. Ci si potrebbe trovare ad essere i primi a scoprire un bug nel pacchetto, nel qual caso si dovrebbe aprire un bug su bugreport per farlo conoscere agli sviluppatori.
> 
> Si potrebbero comunque notare problemi di stabilità, gestione imperfetta dei pacchetti (per esempio dipendenze errate od omesse), aggiornamenti troppo frequenti (risultante in compilazioni multiple) o pacchetti corrotti. Se non si conosce come lavora Gentoo e come risolvere i problemi, si raccomanda di usare le branche stabili e testate. 

 

----------

## devilheart

 *Kernel78 wrote:*   

> Lungi da me spingerti a cambiare, i rispetto tutti, anche i masochisti. Semplicemente metto da parte ogni mio tentativo di aiutarti visto che hai deciso di usare una distribuzione "non stabile" per definizione.

 se nessuno prova la roba "non stabile" essa non diverrà mai stabile. detto questo aggiungo che i "pacchetti non stabili" hanno funzionato correttamente per moltissimo tempo e senza alcun problema; di conseguenza questo memory leak non può avere a che fare con il fatto che i pacchetti sono non stabili

----------

## Peach

 *devilheart wrote:*   

>  *Kernel78 wrote:*   Lungi da me spingerti a cambiare, i rispetto tutti, anche i masochisti. Semplicemente metto da parte ogni mio tentativo di aiutarti visto che hai deciso di usare una distribuzione "non stabile" per definizione. se nessuno prova la roba "non stabile" essa non diverrà mai stabile. detto questo aggiungo che i "pacchetti non stabili" hanno funzionato correttamente per moltissimo tempo e senza alcun problema; di conseguenza questo memory leak non può avere a che fare con il fatto che i pacchetti sono non stabili

 

guarda che se vuoi testare pacchetti la soluzione è sempre suggerita dal manuale che consiglia l'uso della smascheratura granulare (scusa il termine) che permette di smascherare singolarmente i pacchetti che si desidera tenere instabili. Concordo pienamente con quanto dice Kernel78, anzi questo approcio di marcare tutto il sistema unstable è stata più e più volte dibattuta risultando alla fine una inutile perdita di tempo per sviluppatori e utenti, non ti stupire insomma se qualcuno ti viene a dire "beh a sto punto installati debian unstable".

Si insomma sta di fatto che se l'helpdesk del forum gentoo si basa sul confronto delle configurazioni dei vari utenti è normale che il tuo sistema potrebbe avere acquisito il memory leak da qualche altra parte rispetto a quelle che normalmente e in maniera conosciuta affliggono gli altri utenti.

Considera anche che se tu dici che i "pacchetti non stabili hanno funzionato correttamente per moltissimo tempo senza alcun problema" non significa che sia vero per tutti e per sempre, ma è un'affermazione completamente soggettiva. E non mi pare nemmeno il caso di disquisire se sia vero o meno che i pacchetti stable sono unstable o che i pacchetti unstable sono stable. significa tempo perso e thread chiuso nel giro di poco tempo.

----------

## earcar

per caso usi compiz-fusion?

----------

## devilheart

a quanto pare non è un caso singolare

https://forums.gentoo.org/viewtopic-t-695954-highlight-xorg+memory+leak.html

https://bugs.gentoo.org/show_bug.cgi?id=225907

 *Peach wrote:*   

> 
> 
> Considera anche che se tu dici che i "pacchetti non stabili hanno funzionato correttamente per moltissimo tempo senza alcun problema" non significa che sia vero per tutti e per sempre, ma è un'affermazione completamente soggettiva. E non mi pare nemmeno il caso di disquisire se sia vero o meno che i pacchetti stable sono unstable o che i pacchetti unstable sono stable. significa tempo perso e thread chiuso nel giro di poco tempo.

 quello che voglio dire è che se il leak dipende dal fatto che un pacchetto è non stabile allora il leak stesso deve manifestarsi sin dall'installazione del pacchetto stesso, non settimane dopo

 *Peach wrote:*   

> 
> 
> Si insomma sta di fatto che se l'helpdesk del forum gentoo si basa sul confronto delle configurazioni dei vari utenti è normale che il tuo sistema potrebbe avere acquisito il memory leak da qualche altra parte rispetto a quelle che normalmente e in maniera conosciuta affliggono gli altri utenti.

 allora mi toccherà aspettare che passi uno degli innumerevoli utenti che tiene tutto in ~arch

 *earcar wrote:*   

> per caso usi compiz-fusion?

 no

EDIT:

la sorgente del leak è in x11-libs/pixman. l'ultima versione non stabile corregge il problema

----------

## federico

Discutiamone invece, e chiudiamo il post qualora necessario, perche' tutte le volte c'e' qualche partecipante alle discussioni che si sente migliore di altri e etichetta utenti come masochisti, perditempo, controproducenti e via discorrendo.

Potrei dire a voi di utilizzare debian stabile, se tanto siete timorosi di utilizzare un prodotto nuovo.

----------

## .:deadhead:.

Fede cerca di essere razionale e svesti i panni del don chisciotte . Gioie e dolori, se scegli di usare un sistema TUTTO in ~ sono scelte personali che uno porta avanti, ci si aspetta, perchè ha sufficienti skill tecniche per aiutare e contribuire alla risoluzione dei problemi. Altrimenti buonsenso vuole che uno usi in ~ solo quei pacchetti di cui senti bisogno o di cui vuol velocizzare la stabilizzazione.

Una gentoo stabile dà la merda a debian, il concetto di stabile di gentoo è differente da archeologico.

Nel caso specifico, ad avere solo alcuni pacchetti in ~ si potrebbero fare delle congetture. Ma avendo tutto in ~ chi lo sa che magari non c'è qualche strana interazione tra pacchetti impensabili che crea il casotto?

----------

## federico

Abbiamo fatto questo discorso molte volte, ma da questo post sembra che questo forum di gentoo sia aperto alla discussione solo su ambiente non ~.

E' cosi davvero?

----------

## Kernel78

 *federico wrote:*   

> Abbiamo fatto questo discorso molte volte, ma da questo post sembra che questo forum di gentoo sia aperto alla discussione solo su ambiente non ~.
> 
> E' cosi davvero?

 

Certo che no, anche chi fa scelte che io ritengo estreme e che non condivido minimamente può venire qui a cercare aiuto ma proprio per la varietà di problemi a cui espone un'installazione ~ secondo me sarebbe quantomeno opportuno segnalare subito che la propria installazione differisce da quella "standard".

Diamine le linee guida richiederebbero:

 *Quote:*   

> In particolare gli utenti AMD64, PPC, SPARC, ... sono invitati a esplicitare chiaramente e subito l'architettura sulla quale incontrano per evitare che gli vengano dati inutili consigli che funzionerebbero solo su x86. 

  se non risulta chiaro che sarebbe cosa gradita esplicitare subito se si stia usando una ~ allora forse è meglio chiarirlo nelle linee guida.

Non so voi ma io tra moglie, figlia, lavoro, amici e hobby riesco a recuperare poco tempo per aiutare qui sul forum e non avendo la minima pratica di installazioni ~ preferisco astenermi, sia per non perdere tempo io a dare consigli inutili (es. "hai provato l'ultima versione instabile") e sia per non far perdere tempo a chi ha il problema.

@devilheart

sostenere che la colpa dei leak non fosse dei pacchetti instabili mi sembra quantomeno opinabile, se non è un pacchetto a causare il leak cosa sarebbe potuto essere ? una jpeg ?

Infatti era proprio uno dei dei pacchetti instabili ...

----------

