Ram occupata in costante aumento [Risolto]

[micia]

Credo che si stiano facendo progressi per quanto riguarda entropy-updates, ecco qualche aggiornamento:
https://git.sabayon.org/entropy.git/commit/?id=75a48ee85f23c3f7f22f249ef408b1880d402d17

Per quanto riguarda gnome-shell, ho letto che la nuova versione di gobject-introspection mette fine a qualche bug che concerne la mancata deallocazione di memoria, la nuova versione è al momento in fase di testing e sarà disponibile a breve.

[jazzy]

Credo che si stiano facendo progressi per quanto riguarda entropy-updates, ecco qualche aggiornamento:
https://git.sabayon.org/entropy.git/commit/?id=75a48ee85f23c3f7f22f249ef408b1880d402d17

Per quanto riguarda gnome-shell, ho letto che la nuova versione di gobject-introspection mette fine a qualche bug che concerne la mancata deallocazione di memoria, la nuova versione è al momento in fase di testing e sarà disponibile a breve.

Molto bene, nel frattempo ho disattivato magneto e di conseguenza entropy-updates.
Chiedo: Si può applicare l'aggiornamento sopracitato? Vedo che è in git, se si come lo applico?

Complimenti per essere così attivi nel gestire le problematiche .

[Thema89]

Salve a tutti, pongo un problema che ho costantemente con Sabayon Gnome 64bit. Il mio PC (non recentissimo) con processore AMD Athlon(tm) 64 X2 Dual Core Processor 4000+, 2Gb di ram, 1Gb di swap è praticamente sempre acceso 24 su 24 e continua ad aumentare progessivamente l'occupazione di ram e poi anche di swap, in particolare "gnome-shell" e "entropy-updates". (...)
Chiedo, è normale? si può migliorare tale situazione? Dovrei optare per la versione 32bit?

Scusami se ti rispondo dopo tanto tempo, e anche esulando un pochino dal tema principale, ma vorrei dare un consiglio a molti che -come te e come me- utilizzano Sabayon su più macchine, comprese alcune meno "fornite" di RAM.

Per risponderti alle 3 domande, direi 3 si Si, è "pseudo-normale" (i programmi perfetti in ogni punto, specialmente quelli scritti in questi linguaggi, non esistono... inevitabilmente accade che in un utilizzo continuo rimangano dei RAM-leaks...); si, si può tentare di migliorare la situazione, e questo ci porta al terzo SI: optare per l'architettura 32bit.

Infatti, la differenza di base delle architetture a 32 ed a 64 bit si basa sulla lunghezza degli indirizzi di memoria (i secondi doppi rispetto ai primi). Questa "innovazione" (senza addentrarci troppo nel funzionamento effettivo dei due bus) comporta due "vantaggi" principali:

• garantisce, innanzitutto, la possibilità di ampliare la memoria massima allocabile fino a valori ipotetici dell'ordine dei 16 ExaByte ( circa 16 miliardi di GigaByte, cioè 16 milioni di TeraByte, una quantità talmente grande che è anche difficilmente immaginabile per il momento ) mentre nelle architetture x86 il limite è di 4 Gb
• In secondo luogo, solo su software specificamente ottimizzati, l'accesso alla memoria viene garantito con una velocità quasi doppia rispetto a quella di un architettura "standard" a 32bit, grazie alla sua maggiore allocazione in memoria e al "tipo di dialogo" instaurato fra CPU<->RAM

Tutte cose buone insomma sembrerebbe, ma nel caso di hardware un po' datato, possono nascere dei problemi di utilizzo della RAM proprio a causa della lunghezza degli indirizzi di memoria

In un sistema operativo x64 ogni singola applicazione 64bit occupa molto più spazio in memoria se paragonata alla sua corrispettiva versione a 32bit (i quali -tra l'altro- sono ancora molto più diffusi, e per girare regolarmente nelle piattaforme 64 il SO deve subire una sorta di "adattamento" al loro utilizzo)... ivi compresi dunque non solo software applicativi, ma anche quelli facenti parte del sistema operativo in sé per sé.

Concludendo in una frase sola: a mio modesto parere, se si utilizza una piattaforma con memoria inferiore o uguale a 2Gb, considerando anche la maggior stabilità in media della versione 32bit e la diffusione pressoché standardizzata di software ALMENO a 32bit, sarebbe logico optare per il 32-bit (o aumentare la ram disponibile, certo ) e -spazio sul disco permettendo- dedicare allo spazio di swap una grandezza 1:1 anzichè 0.5:1 (grande quanto la memoria fisica disponibile insomma, se hai 2 giga di ram -> 2 giga di swap, in modo da rendere disponibile anche l'ibernazione e non rischiare di saturare la swap in caso di forte utilizzo del computer, come nel caso di utilizzo come home-server o come "muletto" da tenere acceso 24h/24)

Spero di esserti stato d'aiuto, o perlomeno spero di non essere andato troppo offtopic

[jazzy]

Spero di esserti stato d'aiuto, o perlomeno spero di non essere andato troppo offtopic

Grazie per la risposta sei stato molto utile nei chiarimenti, nel frattempo ho completamente disinstallato "magneto" ed "entropy-updates-client" così mi sono tolto già un mattone sulla ram, gli aggiornamenti li controllo manualmente.
Credo che fino a che non aggiornerò il mio hardware proverò a passare al 32bit seguendo i tuoi consigli.

P.S.
C'è sempre molta confusione comunque sulle opinioni se utilizzare o meno sistemi operativi a 64bit, sui svantaggio o vantaggi. Ma credo che diverrà lo standard prossimo con l'utilizzo di hardware aggiornato più performante.

Grazie mille.

[micia]

Nell'ultima versione di entropy dovrebbe essere incorporata quella patch, per cui la sua occupazione non dovrebbe crescere più in maniera incontrollata, dovrebbe essere disponibile anche nei reporitorty settimanali.
È complesso dire quale fra i 64 bit e i 32 bit siano più indicati, la stabilità ormai non è più un termine di paragone, entrambi i sistemi sono alla pari, per quanto riguarda la memoria dipende dall'applicazione.
Senz'altro far girare un sistema a 32 bit su una architettura a 64 sfrutta in modo limitato il processore.

[jazzy]

Con gli ultimi aggiornamenti devo confermare che per quanto riguarda "entropy-updates-service" il problema è completamente risolto, siamo sotto i 30mb costanti, molto bene!
Per "gnome-shell" sicuramente bisogna aspettare i prossimi rilasci ufficiali degli sviluppatori Gnome credo, quindi per me i problemi risolvibili dal "Sabayon staff" è risolto. Grazie.