Newsgroup: it.comp.os.linux.sys
Titolo: Problema di memoria (kernel 2.6 ?)

Salve a tutti...
vi scrivo per proporvi quello che a me sembra un
comportamento decisamente strano che ho rilevato
su alcuni sistemi Linux che ho provato di recente.
Non mi dispiacerebbe conoscere la vostra opinione
a riguardo (e magari anche qualche idea per una
soluzione...).
Il problema è questo: recentemente lavorando su
dei sistemi Linux con Kernel 2.6.x ho notato che
se l'utente "root" (la cosa non accade se a
scrivere su disco è un utente non privilegiato) 
effettua un'intensiva scrittura su disco la memoria
di sistema tende a riempirsi completamente (e questo
dovrebbe essere normale perchè viene utilizzata
come cache) e poi non viene più rilasciata
neanche dopo la chiusura del processo che ha
effettuato le scritture. La memoria di sistema
rimane piena e successivamente se un processo
istanzia memoria il sistema risponde swappando.
Sembrerebbe un leak a livello Kernel. La cosa
ancora più particolare è che il sistema rimane
poi in questo stato per sempre a meno che non
si cancellino i file che il processo ha creato.
Alcuni dettagli sui sistemi su cui ho osservato
il problema:
HW Sistema A:
2 x Intel Xeon CPU E5320 1.86GHz Processor
Intel Server Board S5000VSA
8 GByte RAM
Disks: Samsung-SP1614C Segate-ST3750640NS
HW Sistema B:
Intel Pentium 4 CPU 3.00 GHz Processor
1GByte RAM
Disk: Samsung-SP0411N
Sul sistema A il problema si è verificato con i
seguenti sistemi:
CentOS 4.5
CentOS 4.6
CentOS 5.1
CentOS 5.1 + Kernel 2.6.23.14 from 
kernel.org
Sul sistema B il problema si è verificato con
Fedora Core 2.
Tutte le scritture su disco avvenivano su
partizioni ext3.
Provando sul sistema A con CentOS 3.9 (quindi
con un kernel 2.4.x) il problema non si verifica.
Sono veramente curioso di sapere cosa ne pensate
voi che avete una conoscenza di Linux sicuramente
molto superiore alla mia. Sinceramente io non
riesco a spiegarmi cosa succede. Naturalmente
posso immaginare che per dare una risposta saranno
necessari altri dettagli relativi alle prove
effettuate... non c'è problema, basta chidere... 8-)
Saluti a tutti...
Andrea

 si cancellino i file che il processo ha creato.
A me più che un memory leak sembrerebbe un utilizzo scorretto di tmpfs ;-)
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 effettuate... non c'è problema, basta chidere... 8-)
Se già sapevi che le informazioni riportate sono insufficienti, perchè 
non le hai fornite subito?
Se scrivevi quali comandi hai impartito credo che sarebbe stato di 
maggior aiuto per aiutarti :)
In attesa di tue notizie salutoti.

maggior aiuto per aiutarti :)
Scusami... siccome avevo già scritto un messaggio abbastanza lungo
e brancolavo un po' nel buio non volevo tediarvi con altre
informazioni che magari erano completamente inutili a chiarire il
problema... preferivo che foste voi a dirmi cosa vi serviva...
Comunque ecco il semplicissimo programmino che ho usato per i test:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <fcntl.h>
#include <ctype.h>
#include <errno.h>
#include <unistd.h>
 
int main(void)
{
    #define DIR_OUT     ("./data/")
 
    #define KILOBYTE    (1024)
    #define MEGABYTE    (KILOBYTE*KILOBYTE)
 
    #define DIM_FILE    (50)                    // Espresso in megabyte
    #define NUM_FILE    (500)
 
    char    nomefile[KILOBYTE];
    char    buffer[MEGABYTE];
    int     progressivo;
    int     cmega=0, cfile=0;
    FILE    *pFile;
 
    for (cfile=0; cfile<NUM_FILE; cfile++)
    {
        sprintf(nomefile,"%sfiletest500m%d.bin",DIR_OUT,cfile);
        pFile=fopen(nomefile,"w");
        for (cmega=0; cmega<DIM_FILE; cmega++)
        {
            fwrite(buffer,1,MEGABYTE,pFile);
            //fflush(pFile);
        }
        fclose(pFile);
        printf("*");
        fflush(stdout);
    }
    printf("\n");
}
Facendolo girare due volte di seguito sul sistema A con CentOS 4.5 i386,
4.6 x86_64 e 5.1 x86_64 ho sempre ottenuto uno utilizzo dello swap.
Saluti e ancora grazie per le vostre risposte...
Andrea

 pioveva?!? 8-)
Ho fatto girare quel codice, limitando il numero di files creati (non 
era disponibile abbastanza spazio su disco) ma non si è mai evidenziato 
il problema da te segnalato, nessun uso dello swap, nè lanciando il 
codice per due volte consecutive nè lanciandone due istanze contemporanee.
Ti consiglio di installare una lampada per acquari marini, di quelle che 
cercano di riprodurre la luce solare :)
Ciao

 cercano di riprodurre la luce solare :)
Potrebbe essere una buona idea... magari aiuta ;)
Grazie, ciao
Andrea

 2. Quanto hai scritto su disco? 
10 GB
Ciao.

 4.6 x86_64 e 5.1 x86_64 ho sempre ottenuto uno utilizzo dello swap.
Eh....


 Andrea
Ho fatto girare il tuo programmino su un sistema con 500MB di ram già 
attivo da parecchie ore e X con attive varie applicazioni (KDE, 
Acrobat, firefox thunderbird, monitor risorse e shell) in queste 
condizioni fra buffers, cache, ecc. tutta la memoria è occupata salvo 
poche centinaia di kB.  Facendo girare il tuo programma effettivamente 
vengono buttati nello swap 500k che poi rimangono sempre allocati. 
Facendolo girare più volte non cambia più e viene evidenziato dal 
fatto che con "vmstat 1" non si vedono né letture né scritture in 
swap.  Ad ogni termine del programma la ram dichiarata free arriva a 
150M probabilmente perché si è liberato di buffers/cache vecchia per 
far posto ai buffer/cache dei file nuovi.
In queste condizioni oltre a liberare i buffers/cache dei vecchi files 
è probabile che qualche parte di X o degli applicativi sia 
inutilizzata e venga swappata per far posto al programma ed a 
bufferizzare i file che genera.
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 Verifichi con un semplice cat /proc/mounts
Come ti dicevo purtroppo in questo momento non ho il sistema sottomano (ma
lo avrò di nuovo tra qualche giorno), però non credo ci sia bisogno di
verfiche, la partizione sulla quale scrivevo era montata su /data e creata
da me al momento dell'installazione del sistema operativo. Qualcosa di
simile:
[root@mysys root]# df -h
Filesystem         Dimens. Usati Disp. Uso% Montato su
/dev/sda3             131G  1.9G  123G   2% /
/dev/sda1             190M   14M  167M   8% /boot
/dev/sdb1             688G   31G  623G   5% /data
none                  3.8G     0  3.8G   0% /dev/shm
Qualche altra idea?
Grazie, ciao
Andrea

 man dd
Be', no dai, usare lo stesso codice che gli ha generato il problema mi 
sembra importante.
A questo proposito, a me si sono drizzati i capelli con un baco di 
qualche mese fa:
   int i=2;
   if( -10*abs (i-1) == 10*abs(i-1) )
     printf ("OMG,-10==10 in linux!\n");
   else
     printf ("nothing special here\n") ;
Ciao.
Ah, non so cosa significa UCCS.


Avrebbe dovuto bastare.
Comincio a pensare che si verfichi soltano in condizioni particolari... il
difficile sarà capire quali sono tali condizioni... sul sistema A non
avevo installato sostanzialmente niente... buh... sono disorientato...
al posto mio c'è qualcosa che provereste a fare per cercare di isolare il
problema?
Grazie, ciao
Andrea

 bufferizzare i file che genera.
Il comportamento che hai evidenziato tu a me sembra abbastanza normale. Il
problema è che io sono partito da una macchina con 8GByte di RAM di cui
più di 7GB liberi (nessun processo particolare attivo, in pratica girava
soltanto il demone sendmail, niente X, niente DB, niente serverweb, niente
di niente). Una prima esecuzione del codice riportato ha saturato la RAM
lasciando liberi circa 5MB (e fino a quì tutto ok), con una seconda
esecuzione ecco che il sistema è andato in swap. Questo non mi sembra
tanto normale.
Saluti
Andrea


Ma quanto ha messo in swap?


 Ma quanto ha messo in swap?
Se ricordo bene all'incirca 500kB... comunque io vedo come un'errore
l'uso dello swap quando in effetti ci sono più 7GB di RAM a
disposizione. La memoria allocata come buffer per la scrittura su disco
dovrebbe venir resa nuovamente disponibile una volta che la scrittura è
terminata e file sono stati chiusi (con fclose). Ho provato anche
ad utilizzare il comando sync una volta terminata la scrittura ma la
situazione non è cambiata... l'unico modo per liberare effettivamente la
memoria occupata dai buffer sembra essere quello di cancellare i file dal
filesystem.
Grazie, ciao
Andrea

 essere quello di cancellare i file dal filesystem.
Non può tenere in memoria copia dei file che non esistono. Cancellando 
un file vengono rilasciati i blocchi del disco che occupava e di 
conseguenza i blocchi di cache che occupavano.
PS il mio ragionamento è principalmente basato su come operavano i 
kernel 2.0.x che conoscevo meglio, ma penso che sia applicabile anche 
ai kernel più recenti.  Spero che se ho sbagliato qualche esperto 
possa correggermi.


 possa correggermi.
Per quanto ho potuto vedere io la cosa si verifica sul Kernel 2.6.x e non
sul 2.4.x... forse i test che ho fatto non si possono definire
scientifici al 100%, comunque ho provato su due HW diversi con Kernel
2.4.x (quello con 8GB di RAME e uno con 2GB) ed in entrambi i casi il
fenomeno non si è verificato...
Grazie, ciao...
Andrea

 situazione ad un sistema in cui vi è un'intensiva scrittura su disco?
/proc/sys/vm/*
/usr/src/linux/Documentation/sysctl/vm.txt


 /usr/src/linux/Documentation/sysctl/vm.txt
Ho cominciato a darci un'occhiata... chissà se riuscirò a trovare una
buona combinazione di parametri.
In ogni caso grazie a tutti, per lo meno adesso sono un po' meno
immerso nella nebbia.
Saluti,
Andrea