[gull] linux sur plateforme AMD64

Marc SCHAEFER schaefer at alphanet.ch
Fri Jul 13 11:19:47 CEST 2007


On Fri, Jul 13, 2007 at 10:03:19AM +0200, Jean-Eric Cuendet (ML1) wrote:
> > donzelot at gandalf:~$ free
> >              total       used       free     shared    buffers     cached
> > Mem:       8131552    3815576    4315976          0    1000908     607056
> > -/+ buffers/cache:    2207612    5923940
> > Swap:      8388600          0    8388600
> 
> Est-ce que qqun peut expliquer ces chiffres?
> Si on fait : buffers + cached on arrive a 2Gb cached c'est le cache disk,
> mais buffers c'est quoi?)

free est la mémoire gaspillée (totalement inutilisée par le système),
mais qui peut être allouée immédiatement par tout processus, voire même
des interruptions kernel, atomiquement.

buffers ce sont les pages dans le cache d'écriture; propres ou non
(propres == déjà écrites sur le disque-dur). Elles ne peuvent être
jetées par le système que si elles sont propres, ou si on les écrit
d'abord.

cached ce sont les pages dans le cache en lecture seulement. Elles
peuvent être jetées par le système sans aucune procédure particulière en
cas de besoin en mémoire.

D'après ce qui est ci-dessus, on considère que potentiellement
le buffer & cached sont "réalisables" à court ou moyen terme.
Donc used diminue d'autant et free augmente d'autant
(la 2e ligne de chiffres indiques les valeurs potentielles: elles ne
sont pas allouables p.ex. par une interruption, mais par un processus 
en user-space, voire une routine du kernel dans un contexte de tâche,
moyennantr ).

   il y a 7.8 GB de mémoire allouable dans la machine
      (le reste est le kernel, des allocations "en dur",
       évt. le partage avec la RAM vidéo si le chip vidéo
       est bon marché, etc)

   il y a en ce moment 3.6 GB utilisé par les applications et le
   système (hors kernel, allocations de base; inclus buffers/cache)

   il y a 4.1 GB de mémoire totalement gaspillée

   il y a près d'un GB de cache écriture

   il y a un demi-GB de cache en lecture.

On a donc bien:

   7.8 == 3.6 + 4.1
 
> Il reste donc bien 2Gb d'utilisé, mais par quoi?

Comme l'a dit Daniel, certainement le inode cache (un simple find / >
/dev/null suffit à l'alimenter). Comme la machine dispose d'énormément
de mémoire, il ne sera jamais rendu.

> Et c'est quoi ça:   -/+ buffers/cache:    2207612    5923940

décrit comme "deuxième-ligne" ci-dessus.

L'argument de base est que Linux (le kernel) a été conçu dès le départ
assez différemment des UNIX classiques (chez qui le buffer-cache était
de taille *fixe* choisi à la compilation/configuration du système).

Linux considère que la mémoire gaspillée (libre) est très inutile et
serait mieux utilisée pour augmenter les performances du système.
Et c'est ce qu'il fait!

Donc par défaut, on peut considérer qu'un système qui a 8 GB de mémoire
mais n'en utilise réellement que la moitié pour les applications *en ce
moment* mérite tout à fait une optimisation de performance via un cache
disque de 2 GB ou plus.  Le jour où les applications utiliseront plus de
mémoire, le ratio s'inversera automatiquement.

Il est d'ailleurs possible que le swap soit actif bien avant que la
mémoire gaspillée soit à zéro, pour les mêmes raisons. Un swap actif
peut cependant cacher d'autres problèmes: il est recommandé d'utiliser
vmstat(8) (*) (p.ex. `vmstat 5') pour regarder si le swap est actif
(colonnes so et si).  Un système a le droit d'avoir du swap *utilisé*,
mais s'il est *actif*, cela dénote souvent un problème.

Il est *possible* de modifier tous ces paramètres, notamment via
/proc/sys/vm, mais c'est peu documenté (très peu dans proc(5)), mais
je ne vois pas, dans le cas général, l'intérêt.

Il y a une référence assez complète (même si peut-être un peu
spécifique):

   http://www.dba-oracle.com/t_tuning_linux_kernel_2_6_oracle.htm

qui détaille notamment les paramètres de /proc/sys/vm

(*) autres outils: sar, vsar, atop




More information about the gull mailing list