Re: [FRsAG] Out Of memory - linux ne libère pas le cache.
Le 29 septembre 2014 16:06, Aurélien <footplus@gmail.com> a écrit :
2014-09-29 15:53 GMT+02:00 adrien nayrat <adrien.nayrat.axess@gmail.com>:
La solution serait soit d'augmenter la RAM de la machine soit d'augmenter la swap même si elle ne sera jamais utilisée. On va revoir quelques check sur notre nagios! Merci pour vos retours
Mais pourquoi mettre du swap du coup, si tu ne l'utilise pas ? :)
Pour influer sur la du CommitLimit. En fait j'ai dis qu'elle ne sera jamais utilisée grâce à cette sur-allocation. La swap pourrait être utilisée si tous les process se mettaient à bouffer toute la mémoire qu'ils avaient demandé à l'allocation.
Pourquoi tu met du swap avec 20G de ram ? Vu le faible montant dudit swap, j'imagine qu'il n'est pas vraiment requis. Pourquoi ne pas virer le swap ? On 29/09/2014 16:12, adrien nayrat wrote:
Le 29 septembre 2014 16:06, Aurélien <footplus@gmail.com> a écrit :
2014-09-29 15:53 GMT+02:00 adrien nayrat <adrien.nayrat.axess@gmail.com>:
La solution serait soit d'augmenter la RAM de la machine soit d'augmenter la swap même si elle ne sera jamais utilisée. On va revoir quelques check sur notre nagios! Merci pour vos retours
Mais pourquoi mettre du swap du coup, si tu ne l'utilise pas ? :)
Pour influer sur la du CommitLimit. En fait j'ai dis qu'elle ne sera jamais utilisée grâce à cette sur-allocation. La swap pourrait être utilisée si tous les process se mettaient à bouffer toute la mémoire qu'ils avaient demandé à l'allocation. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
2014-09-29 16:15 GMT+02:00 <frsag@jack.fr.eu.org>:
Pourquoi tu met du swap avec 20G de ram ? Vu le faible montant dudit swap, j'imagine qu'il n'est pas vraiment requis.
Pourquoi ne pas virer le swap ?
+1. sur mes serveurs Oracle c'était 0 de swap (enfin si à l'install car Oracel check, mais après hop on vire). Même avec swapiness à 0 le swap st trop utilisé face au cache disque (or dans lecas d'une bdd on préfère que ce soit la base qui gère ça, pas trop le système).
Surtout qu'il faut se poser la question de voir ce qui se passe quand tu es déjà à jouer avec le swap pour une vraie raison (donc trop de conso, pas juste le cache qui ne veux pas rétrécir). Dans mon cas il valait mieux que ça explose gentiment (HA inside) plutôt qu'un ralentissement qui te fait perdre la main sur la machine. Jean
Entre le kernel 2.6.32 et 3.5 il y a eu beaucoup de modifications sur la façon de gérer le "swappiness" : http://www.percona.com/blog/2014/04/28/oom-relation-vm-swappiness0-new-kerne... notamment, avant 3.5, le "swappiness" n'est qu'une indication au kernel, mais il fait ce qu'il veut. Le 29 septembre 2014 16:37, nap <naparuba@gmail.com> a écrit :
2014-09-29 16:15 GMT+02:00 <frsag@jack.fr.eu.org>:
Pourquoi tu met du swap avec 20G de ram ? Vu le faible montant dudit swap, j'imagine qu'il n'est pas vraiment requis.
Pourquoi ne pas virer le swap ?
+1. sur mes serveurs Oracle c'était 0 de swap (enfin si à l'install car Oracel check, mais après hop on vire). Même avec swapiness à 0 le swap st trop utilisé face au cache disque (or dans lecas d'une bdd on préfère que ce soit la base qui gère ça, pas trop le système).
Surtout qu'il faut se poser la question de voir ce qui se passe quand tu es déjà à jouer avec le swap pour une vraie raison (donc trop de conso, pas juste le cache qui ne veux pas rétrécir). Dans mon cas il valait mieux que ça explose gentiment (HA inside) plutôt qu'un ralentissement qui te fait perdre la main sur la machine.
Jean
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 29 septembre 2014 16:37, nap <naparuba@gmail.com> a écrit :
2014-09-29 16:15 GMT+02:00 <frsag@jack.fr.eu.org>:
Pourquoi tu met du swap avec 20G de ram ? Vu le faible montant dudit swap, j'imagine qu'il n'est pas vraiment requis.
Pourquoi ne pas virer le swap ?
+1. sur mes serveurs Oracle c'était 0 de swap (enfin si à l'install car Oracel check, mais après hop on vire). Même avec swapiness à 0 le swap st trop utilisé face au cache disque (or dans lecas d'une bdd on préfère que ce soit la base qui gère ça, pas trop le système).
Surtout qu'il faut se poser la question de voir ce qui se passe quand tu es déjà à jouer avec le swap pour une vraie raison (donc trop de conso, pas juste le cache qui ne veux pas rétrécir). Dans mon cas il valait mieux que ça explose gentiment (HA inside) plutôt qu'un ralentissement qui te fait perdre la main sur la machine.
Jean
Qu'est-ce que tu avais comme valeur d'overcommit? Je comprends votre volonté de mettre un swap à 0. pour info on avait gardé un swap juste "au-cas-ou" mais le swap n'est absolument pas utilisé. Le free -m le confirme, on avait des "out of memory" alors qu'on avait 0 à l'utilisation du swap. 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. Pour info : With strict overcommit enabled on the system (mode 2 in 'vm.overcommit_memory'),allocations which would exceed the CommitLimit (detailed above) will not be permitted. The CommitLimit is calculated with the following formula: CommitLimit = ([total RAM pages] - [total huge TLB pages]) * overcommit_ratio / 100 + [total swap pages] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Document...
Désactiver complètement le swap est rarement une bonne idée, il est plus prudent d'en laisser un peu avec le swapiness très bas (ou à 0). Par contre, pour le soucis de ram utilisée, il faut également regarder du coté du NUMA interleaving si le serveur est multi-CPU en architecture NUMA, si l'interleaving n'est ni activé dans le bios, ni forcé au niveau applicatif avec numactl, un processus ne pourra pas utiliser à lui tout seul plus que la mémoire physique attenante à un CPU physique (RAM/nombre de CPU). Le 29/09/2014 16:57, adrien nayrat a écrit :
Le 29 septembre 2014 16:37, nap <naparuba@gmail.com> a écrit :
2014-09-29 16:15 GMT+02:00 <frsag@jack.fr.eu.org>:
Pourquoi tu met du swap avec 20G de ram ? Vu le faible montant dudit swap, j'imagine qu'il n'est pas vraiment requis.
Pourquoi ne pas virer le swap ? +1. sur mes serveurs Oracle c'était 0 de swap (enfin si à l'install car Oracel check, mais après hop on vire). Même avec swapiness à 0 le swap st trop utilisé face au cache disque (or dans lecas d'une bdd on préfère que ce soit la base qui gère ça, pas trop le système).
Surtout qu'il faut se poser la question de voir ce qui se passe quand tu es déjà à jouer avec le swap pour une vraie raison (donc trop de conso, pas juste le cache qui ne veux pas rétrécir). Dans mon cas il valait mieux que ça explose gentiment (HA inside) plutôt qu'un ralentissement qui te fait perdre la main sur la machine.
Jean Qu'est-ce que tu avais comme valeur d'overcommit?
Je comprends votre volonté de mettre un swap à 0. pour info on avait gardé un swap juste "au-cas-ou" mais le swap n'est absolument pas utilisé. Le free -m le confirme, on avait des "out of memory" alors qu'on avait 0 à l'utilisation du swap. 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.
Pour info : With strict overcommit enabled on the system (mode 2 in 'vm.overcommit_memory'),allocations which would exceed the CommitLimit (detailed above) will not be permitted.
The CommitLimit is calculated with the following formula: CommitLimit = ([total RAM pages] - [total huge TLB pages]) * overcommit_ratio / 100 + [total swap pages]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Document...
Merci pour cette information, toujours bon à savoir. Dans mon cas ça ne pouvait pas être ça, postgres est multiprocess ;) Le 29 septembre 2014 17:03, Jean Weisbuch <jean@plusquenet.net> a écrit :
Désactiver complètement le swap est rarement une bonne idée, il est plus prudent d'en laisser un peu avec le swapiness très bas (ou à 0).
Par contre, pour le soucis de ram utilisée, il faut également regarder du coté du NUMA interleaving si le serveur est multi-CPU en architecture NUMA, si l'interleaving n'est ni activé dans le bios, ni forcé au niveau applicatif avec numactl, un processus ne pourra pas utiliser à lui tout seul plus que la mémoire physique attenante à un CPU physique (RAM/nombre de CPU).
Le 29/09/2014 16:57, adrien nayrat a écrit :
Le 29 septembre 2014 16:37, nap <naparuba@gmail.com> a écrit :
2014-09-29 16:15 GMT+02:00 <frsag@jack.fr.eu.org>:
Pourquoi tu met du swap avec 20G de ram ? Vu le faible montant dudit swap, j'imagine qu'il n'est pas vraiment requis.
Pourquoi ne pas virer le swap ?
+1. sur mes serveurs Oracle c'était 0 de swap (enfin si à l'install car Oracel check, mais après hop on vire). Même avec swapiness à 0 le swap st trop utilisé face au cache disque (or dans lecas d'une bdd on préfère que ce soit la base qui gère ça, pas trop le système).
Surtout qu'il faut se poser la question de voir ce qui se passe quand tu es déjà à jouer avec le swap pour une vraie raison (donc trop de conso, pas juste le cache qui ne veux pas rétrécir). Dans mon cas il valait mieux que ça explose gentiment (HA inside) plutôt qu'un ralentissement qui te fait perdre la main sur la machine.
Jean
Qu'est-ce que tu avais comme valeur d'overcommit?
Je comprends votre volonté de mettre un swap à 0. pour info on avait gardé un swap juste "au-cas-ou" mais le swap n'est absolument pas utilisé. Le free -m le confirme, on avait des "out of memory" alors qu'on avait 0 à l'utilisation du swap. 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.
Pour info : With strict overcommit enabled on the system (mode 2 in 'vm.overcommit_memory'),allocations which would exceed the CommitLimit (detailed above) will not be permitted.
The CommitLimit is calculated with the following formula: CommitLimit = ([total RAM pages] - [total huge TLB pages]) * overcommit_ratio / 100 + [total swap pages]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Document...
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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. Y. 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...
participants (6)
-
adrien nayrat -
frsag＠jack.fr.eu.org -
Greg -
Jean Weisbuch -
nap -
Yves Rougy