[gull] linux sur plateforme AMD64

Daniel Cordey dc at mjt.ch
Fri Jul 13 11:07:48 CEST 2007


> Christophe DONZELOT wrote:

> > ensuite la mémoire est grignotée par les accès au filesystem , un
> > simple "du -sh" suffit.
> > [root at gandalf /]# du -sh
> > 34G     .
> > [root at gandalf /]# free
> >             total       used       free     shared    buffers     cached
> > Mem:       8131552    3298964    4832588          0     983788     277176
> > -/+ buffers/cache:    2038000    6093552
> > Swap:      8388600          0    8388600
> > [root at gandalf /]#

Bon, mais la veritable question est :

	As-tu un probleme de performance ?

Il est vrai que le kernel a tendance a s'octroyer un gros paquet de memoire 
pour son BC, mais il a aussi la capacite a liberer une partie de cette 
memoire lorsque les process en on besoin pour des DATA/TEXT. Cette gestion 
est faite dynamiquement par le kernel. Ce serait un veritable probleme si cet 
espace n'etait pas liberer, obligeant les process a faire du swaping. Or, a 
partir du moment ou le kernel detecte un besoin de memoire, il va d'abord 
faire du menage dans les pages. Certaines pages vont etre simplement 
liberees, d'autres seront ecriotes sur le  disque puis liberees, etc. Dans 
cette procedure, le kernel va aussi essayer de "balancer" l'usage de la 
memoire du BC avec les besoins des process. Contrairement a certains anciens 
kernel UNIX, Linux gere ceci de maniere dynamque. Il n'y a donc pas de 
probleme de performances tant que l'on se trouve dans un usage "non 
transitoire" du systeme. Le pire etant un serveur de DB, utilise de maniere 
sporadique par des applications tres gourmandes en memoire. Cela ralenti le 
demarage de l'application, mais ce n'est normalement pas tres penalisant. Le 
seul defaut est l'incapacite a pouvoior fixer une limite basse pour le BC, 
qui eviterait de monopiliser de la memoire au detriment des process. Je n'ai 
pas trouve de parametre definissant cette valeur de limite basse (low-water 
mark)... 

Pour etre certain que ces 2GB utilises ne sont pas liberes, il faut donc 
lancer une grande quantite de process (compile de kernel..) en meme temps, 
afin de stresser la memoire pour les process. Normalement, on devrait voir la 
valeur du cache decendre progressivement jusqu'a une valeur determinee comme 
etant un bon compromis par le kernel. Si malgre cela, le systeme de cache 
utilise quand meme les 2GB et que le systeme swap des process, nous avons un 
reel probleme... :-(

dc




More information about the gull mailing list