2014-09-29 16:57 GMT+02:00 adrien nayrat <adrien.nayrat.axess@gmail.com>:

En désactivant la sur-allocation la machine est beaucoup plus stricte,
donc comme je l'avais proposé on peut augmenter la RAM ou augmenter la
swap pour jouer sur le CommitLimit . La swap ne serait utilisée
seulement si tous les process se mettaient à consommer toute la
mémoire qu'ils avaient alloué. sur notre serveur c'est loin d'être le
cas, à peine 50% de la RAM utilisée, le reste c'est du cache disque.

Ce que je comprends du système c'est qu'en désactivant l'overcommit, il refuse l'allocation mémoire pour un process si la mémoire n'est pas disponible et présente. Ça ne dit pas que ça réduit les caches dans ce cas, juste que la demande d'allocation est refusée.

De plus non, le swap ne sera pas utilisé si tous les process se mettent à consommer la RAM, le swap sera utilisé si la mémoire *disponible* vient à manquer (j'ai pas fait le calcul avec tes paramètres celà dit). Est si la mémoire est utilisée par un cache/buffer, elle n'est pas disponible. Donc tu peux avoir 50% de la RAM avec des caches/buffers, et des process qui swappent.

Je sais que ça a un peu changé récemment, mais c'est justement le swapiness qui permet d'équilibrer la mémoire disponible entre les process et les caches/buffers. Faudrait voir l'impact d'un swapiness de 0 dans ton cas. Maintenant, essayer mettre les caches à 0, c'est pas forcément une bonne idée.

Mais j'insiste, il ne faut pas considérer mémoire cached = mémoire dispo, ce n'est pas le cas, la mémoire n'est pas dispo car elle est allouée au cache.

PS: C'est ce que j'ai compris de la gestion de la mémoire sous Linux, mais je ne suis pas un kernel dev, je peux avoir mal compris...