J'ai une question sur la mani=E8re dont se comporte un programme sous
Linux, en C++, quand on essaye d'allouer plus de m=E9moire que
disponible sur le syst=E8me. =C0 la base, l'op=E9rateur new lance dans ce
cas-l=E0 une exception et c'est =E0 moi de la rattraper et de la traiter,
tr=E8s bien.
Mais mon probl=E8me est de savoir si, par derri=E8re, le noyau essaye
d'allouer toute la m=E9moire avant de se rendre compte qu'il n'en a pas
assez de disponible, ou est-ce qu'il fait d'abord une v=E9rification
avant de se lancer l=E0-dedans ?
Dans le cas o=F9 la m=E9moire est sur de la RAM, =E7a ne change probablement
pas grand chose (en perception par l'utilisateur), mais si il y a du
swap, est-ce que le noyau va faire swapper tout ce qu'il peut pendant
une heure avant de se rendre compte qu'il lui manque 42 octets ?
Si c'est le cas, alors j'imagine que j'ai int=E9r=EAt =E0 impl=E9menter
quelques checks rapides sur la m=E9moire disponible avant de commencer =E0
allouer des blocs de 1 Go (=E7a m'arrive...), sinon mes utilisateurs
risquent de ne pas trop aimer devoir attendre longtemps, et swapper
tout les autres programmes, avant de s'entendre dire qu'il n'y a pas
assez de m=E9moire pour faire ce qu'ils veulent ! Et dans ce cas-l=E0
encore, y'a-t-il une mani=E8re plus ou moins "standard" de v=E9rifier "=E0
la main" la m=E9moire disponible ?
Et accessoirement, j'imagine que diff=E9rents OS peuvent se comporter
diff=E9remment de ce point de vue, donc est-ce pareil pour SunOS ?
IRIX ? (les deux autres syst=E8mes que je suis susceptible d'utiliser)
Jean-Louis Liagre wrote in message <45db27ee$0$3885$:
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le l'overcommit a 2 et je laisse la config par defaut (50%). Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de RAM !!!, qui sont inutilisables ...
Si je te comprends bien, tu te plains que si tu mets des valeurs fantaisistes pour la taille du swap et les sysctl, le système fonctionne de manière sous-optimale ? Je dois dire que ça ne me surprend pas.
Jean-Louis Liagre wrote in message
<45db27ee$0$3885$426a74cc@news.free.fr>:
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le
l'overcommit a 2 et je laisse la config par defaut (50%).
Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les
allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de
RAM !!!, qui sont inutilisables ...
Si je te comprends bien, tu te plains que si tu mets des valeurs
fantaisistes pour la taille du swap et les sysctl, le système fonctionne de
manière sous-optimale ? Je dois dire que ça ne me surprend pas.
Jean-Louis Liagre wrote in message <45db27ee$0$3885$:
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le l'overcommit a 2 et je laisse la config par defaut (50%). Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de RAM !!!, qui sont inutilisables ...
Si je te comprends bien, tu te plains que si tu mets des valeurs fantaisistes pour la taille du swap et les sysctl, le système fonctionne de manière sous-optimale ? Je dois dire que ça ne me surprend pas.
Jean-Louis Liagre
Nicolas George wrote:
Jean-Louis Liagre wrote in message <45d8c514$0$3286$:
C'est une interprétation plausible, mais qui ne correspond pas à ce qui est écrit ici:
The total address space commit for the system is not permitted to exceed swap + a configurable percentage (default is 50) of physical RAM.
Il n'est pas fait ici allusion a un espace *disponible* de swap ou de RAM. J'en déduis donc qu'il s'agit de la taille totale du swap plus la moitié de la RAM installée. Il est en effet écrit "Physical RAM", pas "Available RAM".
Linux a l'habitude de ne pas _du tout_ comptabiliser la mémoire utilisée directement par le coeur du noyau (la plus grande partie étant la table des pages). C'est comme ça. Par exemple, dans /proc/meminfo, MemTotal ne la prend pas en compte. Dans ces conditions, il est absolument évident pour quiconque un peu au courant que la mention « physical RAM » doit s'interpréter à cette aune, et simplement par opposition à swap.
J'admet que ca puisse etre le cas mais ca ne resout pas le probleme.
Linux n'est pas capable de gerer lui-meme la limite exacte de l'overcommit et impose un tuning plus ou mois approximatif si l'on souhaite eviter l'OOM killer.
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le l'overcommit a 2 et je laisse la config par defaut (50%). Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de RAM !!!, qui sont inutilisables ...
Nicolas George wrote:
Jean-Louis Liagre wrote in message
<45d8c514$0$3286$426a74cc@news.free.fr>:
C'est une interprétation plausible, mais qui ne correspond pas à ce qui
est écrit ici:
The total address space commit for the system is not permitted to exceed
swap + a configurable percentage (default is 50) of physical RAM.
Il n'est pas fait ici allusion a un espace *disponible* de swap ou de
RAM. J'en déduis donc qu'il s'agit de la taille totale du swap plus la
moitié de la RAM installée. Il est en effet écrit "Physical RAM", pas
"Available RAM".
Linux a l'habitude de ne pas _du tout_ comptabiliser la mémoire utilisée
directement par le coeur du noyau (la plus grande partie étant la table des
pages). C'est comme ça. Par exemple, dans /proc/meminfo, MemTotal ne la
prend pas en compte. Dans ces conditions, il est absolument évident pour
quiconque un peu au courant que la mention « physical RAM » doit
s'interpréter à cette aune, et simplement par opposition à swap.
J'admet que ca puisse etre le cas mais ca ne resout pas le probleme.
Linux n'est pas capable de gerer lui-meme la limite exacte de
l'overcommit et impose un tuning plus ou mois approximatif si l'on
souhaite eviter l'OOM killer.
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le
l'overcommit a 2 et je laisse la config par defaut (50%).
Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les
allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de
RAM !!!, qui sont inutilisables ...
Jean-Louis Liagre wrote in message <45d8c514$0$3286$:
C'est une interprétation plausible, mais qui ne correspond pas à ce qui est écrit ici:
The total address space commit for the system is not permitted to exceed swap + a configurable percentage (default is 50) of physical RAM.
Il n'est pas fait ici allusion a un espace *disponible* de swap ou de RAM. J'en déduis donc qu'il s'agit de la taille totale du swap plus la moitié de la RAM installée. Il est en effet écrit "Physical RAM", pas "Available RAM".
Linux a l'habitude de ne pas _du tout_ comptabiliser la mémoire utilisée directement par le coeur du noyau (la plus grande partie étant la table des pages). C'est comme ça. Par exemple, dans /proc/meminfo, MemTotal ne la prend pas en compte. Dans ces conditions, il est absolument évident pour quiconque un peu au courant que la mention « physical RAM » doit s'interpréter à cette aune, et simplement par opposition à swap.
J'admet que ca puisse etre le cas mais ca ne resout pas le probleme.
Linux n'est pas capable de gerer lui-meme la limite exacte de l'overcommit et impose un tuning plus ou mois approximatif si l'on souhaite eviter l'OOM killer.
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le l'overcommit a 2 et je laisse la config par defaut (50%). Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de RAM !!!, qui sont inutilisables ...
JKB
Le 21-02-2007, à propos de Re: Allouer plus de mémoire que disponible, Jean-Louis Liagre écrivait dans fr.comp.os.unix :
Nicolas George wrote:
Jean-Louis Liagre wrote in message <45db27ee$0$3885$:
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le l'overcommit a 2 et je laisse la config par defaut (50%). Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de RAM !!!, qui sont inutilisables ...
Par une allocation d'un processus, si j'ai bien compris.
Si je te comprends bien, tu te plains que si tu mets des valeurs fantaisistes pour la taille du swap et les sysctl, le système fonctionne de manière sous-optimale ? Je dois dire que ça ne me surprend pas.
La taille du swap me regarde, elle n'a rien de fantaisiste si la taille de la RAM est suffisante aux besoins des applications que je fait tourner.
Les sysctl ont leur valeurs par defaut et en effet, Linux fait preuve ici de beaucoup de fantaisie.
Par défaut, le paramètre en question est à 0 :
0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slighly more memory in this mode. This is the default.
Maintenant, si on positionne le truc à 2 et qu'on a une machine "normale", mettons mon U2 avec 2Go de mémoire et 4Go de swap, je peux par défaut faire une allocation de 5Go, ce qui n'est pas absurde (reste 1Go pour tout le reste, noyau, X et autres applications). Il est toujours possible de positionner vm.overcommit_ratio, mais je ne suis pas franchement sûr que ce soit une excellente idée.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 21-02-2007, à propos de
Re: Allouer plus de mémoire que disponible,
Jean-Louis Liagre écrivait dans fr.comp.os.unix :
Nicolas George wrote:
Jean-Louis Liagre wrote in message
<45db27ee$0$3885$426a74cc@news.free.fr>:
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le
l'overcommit a 2 et je laisse la config par defaut (50%).
Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les
allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de
RAM !!!, qui sont inutilisables ...
Par une allocation d'un processus, si j'ai bien compris.
Si je te comprends bien, tu te plains que si tu mets des valeurs
fantaisistes pour la taille du swap et les sysctl, le système fonctionne de
manière sous-optimale ? Je dois dire que ça ne me surprend pas.
La taille du swap me regarde, elle n'a rien de fantaisiste si la taille
de la RAM est suffisante aux besoins des applications que je fait tourner.
Les sysctl ont leur valeurs par defaut et en effet, Linux fait preuve
ici de beaucoup de fantaisie.
Par défaut, le paramètre en question est à 0 :
0 - Heuristic overcommit handling. Obvious overcommits of
address space are refused. Used for a typical system. It
ensures a seriously wild allocation fails while allowing
overcommit to reduce swap usage. root is allowed to
allocate slighly more memory in this mode. This is the
default.
Maintenant, si on positionne le truc à 2 et qu'on a une machine
"normale", mettons mon U2 avec 2Go de mémoire et 4Go de swap, je
peux par défaut faire une allocation de 5Go, ce qui n'est pas
absurde (reste 1Go pour tout le reste, noyau, X et autres
applications). Il est toujours possible de positionner
vm.overcommit_ratio, mais je ne suis pas franchement sûr que ce soit
une excellente idée.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 21-02-2007, à propos de Re: Allouer plus de mémoire que disponible, Jean-Louis Liagre écrivait dans fr.comp.os.unix :
Nicolas George wrote:
Jean-Louis Liagre wrote in message <45db27ee$0$3885$:
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le l'overcommit a 2 et je laisse la config par defaut (50%). Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de RAM !!!, qui sont inutilisables ...
Par une allocation d'un processus, si j'ai bien compris.
Si je te comprends bien, tu te plains que si tu mets des valeurs fantaisistes pour la taille du swap et les sysctl, le système fonctionne de manière sous-optimale ? Je dois dire que ça ne me surprend pas.
La taille du swap me regarde, elle n'a rien de fantaisiste si la taille de la RAM est suffisante aux besoins des applications que je fait tourner.
Les sysctl ont leur valeurs par defaut et en effet, Linux fait preuve ici de beaucoup de fantaisie.
Par défaut, le paramètre en question est à 0 :
0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slighly more memory in this mode. This is the default.
Maintenant, si on positionne le truc à 2 et qu'on a une machine "normale", mettons mon U2 avec 2Go de mémoire et 4Go de swap, je peux par défaut faire une allocation de 5Go, ce qui n'est pas absurde (reste 1Go pour tout le reste, noyau, X et autres applications). Il est toujours possible de positionner vm.overcommit_ratio, mais je ne suis pas franchement sûr que ce soit une excellente idée.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 21-02-2007, à propos de Re: Allouer plus de mémoire que disponible, Jean-Louis Liagre écrivait dans fr.comp.os.unix :
JKB wrote:
Le 21-02-2007, à propos de Re: Allouer plus de mémoire que disponible, Jean-Louis Liagre écrivait dans fr.comp.os.unix :
Nicolas George wrote:
Jean-Louis Liagre wrote in message <45db27ee$0$3885$:
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le l'overcommit a 2 et je laisse la config par defaut (50%). Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de RAM !!!, qui sont inutilisables ...
Par une allocation d'un processus, si j'ai bien compris.
Je comprend moi que ces 3 gigas de RAM seront inutilisables que que soit le nombre de processus et d'allocations faites.
Personnellement, je comprends "par allocation". Et cela semble confirmé par mes tests.
Si je te comprends bien, tu te plains que si tu mets des valeurs fantaisistes pour la taille du swap et les sysctl, le système fonctionne de manière sous-optimale ? Je dois dire que ça ne me surprend pas.
La taille du swap me regarde, elle n'a rien de fantaisiste si la taille de la RAM est suffisante aux besoins des applications que je fait tourner.
Les sysctl ont leur valeurs par defaut et en effet, Linux fait preuve ici de beaucoup de fantaisie.
Par défaut, le paramètre en question est à 0 :
0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slighly more memory in this mode. This is the default.
Maintenant, si on positionne le truc à 2 et qu'on a une machine "normale", mettons mon U2 avec 2Go de mémoire et 4Go de swap, je peux par défaut faire une allocation de 5Go, ce qui n'est pas absurde (reste 1Go pour tout le reste, noyau, X et autres applications).
Je ne suis pas d'accord avec le "et autres applications".
Pourquoi ?
Le 1 Go restant n'est utilisable que par le noyau ou des modules/drivers associes, pas par des applications.
Il est toujours possible de positionner vm.overcommit_ratio, mais je ne suis pas franchement sûr que ce soit une excellente idée.
C'est vrai, l'overcommit n'est pas a sa valeur par defaut.
Je ne sais pas ce que c'est qu'une machine "normale". Si une configuration est autorisee et qu'elle se justifie, je ne vois pas pourquoi on devrait la juger "anormale".
Ce que je reproche au parametre overcommit, c'est qu'il induit les utilisateurs en erreur car son libelle est trompeur.
Il permet c'est vrai de reduire le risque d'OOM killer, mais exige un parametrage tres fin pour etre sur que l'on ne tombe pas dans le probleme inverse, ce que mon exemple demontre. En fait, on ne sait pas trop si on a supprime le risque.
Dans la vraie vie, on est souvent bien content d'avoir un OOM killer. Cela évite généralement de rebooter sauvagement un serveur. Je ne l'ai vu à l'oeuvre que deus ou trois fois, mais le réseultat est assez bon. Dernier exemple : un stagiaire écrit du C avec un pied gauche et dans un algorithme de traitement alloue de la mémoire façon malloc(), chaque bloc alloué faisant quelque kilo. Le problème, c'est qu'il n'a jamais utilisé le free() correspondant. Sur une machine de calcul, il est d'assez bon ton que le système se démerde seul pour virer le gêneur, parce que dans le cas du reboot sauvage, les calculs qui tournaient depuis quinze jour sont perdus.
Voici aussi ce que je vois dans le code source:
#define OVERCOMMIT_NEVER 2
Le "NEVER" est clairement incorrect. (le STRICT de la doc est plus exact).
En definitive, je ne comprend pas pourquoi Linux oblige a effectuer un tuning quand on souhaite disposer de toute sa memoire virtuelle sans jamais overcommiter une allocation, alors qu'il a toute les billes pour effectuer ce controle tout seul.
Parce qu'il n'y a pas trente-six solutions. Soit on utilise un overcommit et un OOM killer (ou récupération des signaux gaçon segfault), soit on n'utilise pas d'overcommit et la gestion de la mémoire est clairement sous-optimale. Tout ceci est une histoire de compromis.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 21-02-2007, à propos de
Re: Allouer plus de mémoire que disponible,
Jean-Louis Liagre écrivait dans fr.comp.os.unix :
JKB wrote:
Le 21-02-2007, à propos de
Re: Allouer plus de mémoire que disponible,
Jean-Louis Liagre écrivait dans fr.comp.os.unix :
Nicolas George wrote:
Jean-Louis Liagre wrote in message
<45db27ee$0$3885$426a74cc@news.free.fr>:
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le
l'overcommit a 2 et je laisse la config par defaut (50%).
Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les
allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de
RAM !!!, qui sont inutilisables ...
Par une allocation d'un processus, si j'ai bien compris.
Je comprend moi que ces 3 gigas de RAM seront inutilisables que que soit
le nombre de processus et d'allocations faites.
Personnellement, je comprends "par allocation". Et cela semble
confirmé par mes tests.
Si je te comprends bien, tu te plains que si tu mets des valeurs
fantaisistes pour la taille du swap et les sysctl, le système fonctionne de
manière sous-optimale ? Je dois dire que ça ne me surprend pas.
La taille du swap me regarde, elle n'a rien de fantaisiste si la taille
de la RAM est suffisante aux besoins des applications que je fait tourner.
Les sysctl ont leur valeurs par defaut et en effet, Linux fait preuve
ici de beaucoup de fantaisie.
Par défaut, le paramètre en question est à 0 :
0 - Heuristic overcommit handling. Obvious overcommits of
address space are refused. Used for a typical system. It
ensures a seriously wild allocation fails while allowing
overcommit to reduce swap usage. root is allowed to
allocate slighly more memory in this mode. This is the
default.
Maintenant, si on positionne le truc à 2 et qu'on a une machine
"normale", mettons mon U2 avec 2Go de mémoire et 4Go de swap, je
peux par défaut faire une allocation de 5Go, ce qui n'est pas
absurde (reste 1Go pour tout le reste, noyau, X et autres
applications).
Je ne suis pas d'accord avec le "et autres applications".
Pourquoi ?
Le 1 Go restant n'est utilisable que par le noyau ou des modules/drivers
associes, pas par des applications.
Il est toujours possible de positionner
vm.overcommit_ratio, mais je ne suis pas franchement sûr que ce soit
une excellente idée.
C'est vrai, l'overcommit n'est pas a sa valeur par defaut.
Je ne sais pas ce que c'est qu'une machine "normale". Si une
configuration est autorisee et qu'elle se justifie, je ne vois pas
pourquoi on devrait la juger "anormale".
Ce que je reproche au parametre overcommit, c'est qu'il induit les
utilisateurs en erreur car son libelle est trompeur.
Il permet c'est vrai de reduire le risque d'OOM killer, mais exige un
parametrage tres fin pour etre sur que l'on ne tombe pas dans le
probleme inverse, ce que mon exemple demontre. En fait, on ne sait pas
trop si on a supprime le risque.
Dans la vraie vie, on est souvent bien content d'avoir un OOM
killer. Cela évite généralement de rebooter sauvagement un serveur.
Je ne l'ai vu à l'oeuvre que deus ou trois fois, mais le réseultat
est assez bon. Dernier exemple : un stagiaire écrit du C avec un
pied gauche et dans un algorithme de traitement alloue de la mémoire
façon malloc(), chaque bloc alloué faisant quelque kilo. Le
problème, c'est qu'il n'a jamais utilisé le free() correspondant.
Sur une machine de calcul, il est d'assez bon ton que le système se
démerde seul pour virer le gêneur, parce que dans le cas du reboot
sauvage, les calculs qui tournaient depuis quinze jour sont perdus.
Voici aussi ce que je vois dans le code source:
#define OVERCOMMIT_NEVER 2
Le "NEVER" est clairement incorrect. (le STRICT de la doc est plus exact).
En definitive, je ne comprend pas pourquoi Linux oblige a effectuer un
tuning quand on souhaite disposer de toute sa memoire virtuelle sans
jamais overcommiter une allocation, alors qu'il a toute les billes pour
effectuer ce controle tout seul.
Parce qu'il n'y a pas trente-six solutions. Soit on utilise un
overcommit et un OOM killer (ou récupération des signaux gaçon
segfault), soit on n'utilise pas d'overcommit et la gestion de la
mémoire est clairement sous-optimale. Tout ceci est une histoire de
compromis.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 21-02-2007, à propos de Re: Allouer plus de mémoire que disponible, Jean-Louis Liagre écrivait dans fr.comp.os.unix :
JKB wrote:
Le 21-02-2007, à propos de Re: Allouer plus de mémoire que disponible, Jean-Louis Liagre écrivait dans fr.comp.os.unix :
Nicolas George wrote:
Jean-Louis Liagre wrote in message <45db27ee$0$3885$:
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le l'overcommit a 2 et je laisse la config par defaut (50%). Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de RAM !!!, qui sont inutilisables ...
Par une allocation d'un processus, si j'ai bien compris.
Je comprend moi que ces 3 gigas de RAM seront inutilisables que que soit le nombre de processus et d'allocations faites.
Personnellement, je comprends "par allocation". Et cela semble confirmé par mes tests.
Si je te comprends bien, tu te plains que si tu mets des valeurs fantaisistes pour la taille du swap et les sysctl, le système fonctionne de manière sous-optimale ? Je dois dire que ça ne me surprend pas.
La taille du swap me regarde, elle n'a rien de fantaisiste si la taille de la RAM est suffisante aux besoins des applications que je fait tourner.
Les sysctl ont leur valeurs par defaut et en effet, Linux fait preuve ici de beaucoup de fantaisie.
Par défaut, le paramètre en question est à 0 :
0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slighly more memory in this mode. This is the default.
Maintenant, si on positionne le truc à 2 et qu'on a une machine "normale", mettons mon U2 avec 2Go de mémoire et 4Go de swap, je peux par défaut faire une allocation de 5Go, ce qui n'est pas absurde (reste 1Go pour tout le reste, noyau, X et autres applications).
Je ne suis pas d'accord avec le "et autres applications".
Pourquoi ?
Le 1 Go restant n'est utilisable que par le noyau ou des modules/drivers associes, pas par des applications.
Il est toujours possible de positionner vm.overcommit_ratio, mais je ne suis pas franchement sûr que ce soit une excellente idée.
C'est vrai, l'overcommit n'est pas a sa valeur par defaut.
Je ne sais pas ce que c'est qu'une machine "normale". Si une configuration est autorisee et qu'elle se justifie, je ne vois pas pourquoi on devrait la juger "anormale".
Ce que je reproche au parametre overcommit, c'est qu'il induit les utilisateurs en erreur car son libelle est trompeur.
Il permet c'est vrai de reduire le risque d'OOM killer, mais exige un parametrage tres fin pour etre sur que l'on ne tombe pas dans le probleme inverse, ce que mon exemple demontre. En fait, on ne sait pas trop si on a supprime le risque.
Dans la vraie vie, on est souvent bien content d'avoir un OOM killer. Cela évite généralement de rebooter sauvagement un serveur. Je ne l'ai vu à l'oeuvre que deus ou trois fois, mais le réseultat est assez bon. Dernier exemple : un stagiaire écrit du C avec un pied gauche et dans un algorithme de traitement alloue de la mémoire façon malloc(), chaque bloc alloué faisant quelque kilo. Le problème, c'est qu'il n'a jamais utilisé le free() correspondant. Sur une machine de calcul, il est d'assez bon ton que le système se démerde seul pour virer le gêneur, parce que dans le cas du reboot sauvage, les calculs qui tournaient depuis quinze jour sont perdus.
Voici aussi ce que je vois dans le code source:
#define OVERCOMMIT_NEVER 2
Le "NEVER" est clairement incorrect. (le STRICT de la doc est plus exact).
En definitive, je ne comprend pas pourquoi Linux oblige a effectuer un tuning quand on souhaite disposer de toute sa memoire virtuelle sans jamais overcommiter une allocation, alors qu'il a toute les billes pour effectuer ce controle tout seul.
Parce qu'il n'y a pas trente-six solutions. Soit on utilise un overcommit et un OOM killer (ou récupération des signaux gaçon segfault), soit on n'utilise pas d'overcommit et la gestion de la mémoire est clairement sous-optimale. Tout ceci est une histoire de compromis.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Nicolas George
Jean-Louis Liagre wrote in message <45dc294f$0$3878$:
Ce que je reproche au parametre overcommit, c'est qu'il induit les utilisateurs en erreur car son libelle est trompeur.
Quelqu'un qui change des paramètres aussi pointus sans lire très attentivement la doc cherche les coups de toutes façons.
En definitive, je ne comprend pas pourquoi Linux oblige a effectuer un tuning quand on souhaite disposer de toute sa memoire virtuelle sans jamais overcommiter une allocation, alors qu'il a toute les billes pour effectuer ce controle tout seul.
Le réglage de la VM est quelque chose de complexe, qui dépend énormément des objectifs d'utilisation de la machine, des objectifs de fiabilité sur les différents aspects, etc. Par exemple, sans overcommit, un processus qui monopolise 51% de la mémoire virtuelle pour un gros calcul ne peut pas faire un simple fork+exec d'un shell avec tuyauterie (et faire de la tuyauterie avec vfork, c'est quand même très pénible), ce qui est quand même dommage.
Jean-Louis Liagre wrote in message
<45dc294f$0$3878$426a34cc@news.free.fr>:
Ce que je reproche au parametre overcommit, c'est qu'il induit les
utilisateurs en erreur car son libelle est trompeur.
Quelqu'un qui change des paramètres aussi pointus sans lire très
attentivement la doc cherche les coups de toutes façons.
En definitive, je ne comprend pas pourquoi Linux oblige a effectuer un
tuning quand on souhaite disposer de toute sa memoire virtuelle sans
jamais overcommiter une allocation, alors qu'il a toute les billes pour
effectuer ce controle tout seul.
Le réglage de la VM est quelque chose de complexe, qui dépend énormément des
objectifs d'utilisation de la machine, des objectifs de fiabilité sur les
différents aspects, etc. Par exemple, sans overcommit, un processus qui
monopolise 51% de la mémoire virtuelle pour un gros calcul ne peut pas faire
un simple fork+exec d'un shell avec tuyauterie (et faire de la tuyauterie
avec vfork, c'est quand même très pénible), ce qui est quand même dommage.
Jean-Louis Liagre wrote in message <45dc294f$0$3878$:
Ce que je reproche au parametre overcommit, c'est qu'il induit les utilisateurs en erreur car son libelle est trompeur.
Quelqu'un qui change des paramètres aussi pointus sans lire très attentivement la doc cherche les coups de toutes façons.
En definitive, je ne comprend pas pourquoi Linux oblige a effectuer un tuning quand on souhaite disposer de toute sa memoire virtuelle sans jamais overcommiter une allocation, alors qu'il a toute les billes pour effectuer ce controle tout seul.
Le réglage de la VM est quelque chose de complexe, qui dépend énormément des objectifs d'utilisation de la machine, des objectifs de fiabilité sur les différents aspects, etc. Par exemple, sans overcommit, un processus qui monopolise 51% de la mémoire virtuelle pour un gros calcul ne peut pas faire un simple fork+exec d'un shell avec tuyauterie (et faire de la tuyauterie avec vfork, c'est quand même très pénible), ce qui est quand même dommage.
Sébastien Monbrun aka TiChou
Dans le message <news:45dc7da6$0$7501$, *Jean-Louis Liagre* tapota sur f.c.o.unix :
Date: Wed, 21 Feb 2007 18:13:54 -0800 NNTP-Posting-Date: 21 Feb 2007 18:13:10 MET
Il était 18 h 13 quand vous avez posté, et non 3 h 13 du matin.
Mauvais fuseau horaire, changer de fuseau horaire.
-- Sébastien Monbrun aka TiChou
Dans le message <news:45dc7da6$0$7501$426a74cc@news.free.fr>,
*Jean-Louis Liagre* tapota sur f.c.o.unix :
Date: Wed, 21 Feb 2007 18:13:54 -0800
NNTP-Posting-Date: 21 Feb 2007 18:13:10 MET
Il était 18 h 13 quand vous avez posté, et non 3 h 13 du matin.
Mauvais fuseau horaire, changer de fuseau horaire.
Dans le message <news:45dc7da6$0$7501$, *Jean-Louis Liagre* tapota sur f.c.o.unix :
Date: Wed, 21 Feb 2007 18:13:54 -0800 NNTP-Posting-Date: 21 Feb 2007 18:13:10 MET
Il était 18 h 13 quand vous avez posté, et non 3 h 13 du matin.
Mauvais fuseau horaire, changer de fuseau horaire.
-- Sébastien Monbrun aka TiChou
Nicolas George
Jean-Louis Liagre wrote in message <45dc7da6$0$7501$:
Un malloc/new ou mmap qui plante, ca ne fait pas rebooter un serveur.
Si le sshd sur le serveur ne peut plus forker parce qu'un processus à la con, non critique, a alloué toute la mémoire, tu n'as pas trop d'autre choix que de rebooter de l'extérieur.
A supposer que non, rien ne garantit que le process a l'origine de la fuite soit precisement celui que va degager l'OOM Killer.
Rien ne le garantit, mais il y a de bonnes chances, ce qui est mieux que pas de chances du tout.
Je souhaite que le systeme avec lequel je travaille respecte les standards et la semantique Posix. En particulier, si mon code fait un malloc, je m'attend a ce que l'appel retourne null si le malloc n'est pas garanti.
POSIX ne garantit pas l'absence d'overcommit.
Jean-Louis Liagre wrote in message
<45dc7da6$0$7501$426a74cc@news.free.fr>:
Un malloc/new ou mmap qui plante, ca ne fait pas rebooter un serveur.
Si le sshd sur le serveur ne peut plus forker parce qu'un processus à la
con, non critique, a alloué toute la mémoire, tu n'as pas trop d'autre choix
que de rebooter de l'extérieur.
A supposer que non, rien ne garantit que le process a
l'origine de la fuite soit precisement celui que va degager l'OOM Killer.
Rien ne le garantit, mais il y a de bonnes chances, ce qui est mieux que pas
de chances du tout.
Je souhaite que le systeme avec lequel je travaille respecte les
standards et la semantique Posix.
En particulier, si mon code fait un malloc, je m'attend a ce que l'appel
retourne null si le malloc n'est pas garanti.
Jean-Louis Liagre wrote in message <45dc7da6$0$7501$:
Un malloc/new ou mmap qui plante, ca ne fait pas rebooter un serveur.
Si le sshd sur le serveur ne peut plus forker parce qu'un processus à la con, non critique, a alloué toute la mémoire, tu n'as pas trop d'autre choix que de rebooter de l'extérieur.
A supposer que non, rien ne garantit que le process a l'origine de la fuite soit precisement celui que va degager l'OOM Killer.
Rien ne le garantit, mais il y a de bonnes chances, ce qui est mieux que pas de chances du tout.
Je souhaite que le systeme avec lequel je travaille respecte les standards et la semantique Posix. En particulier, si mon code fait un malloc, je m'attend a ce que l'appel retourne null si le malloc n'est pas garanti.
POSIX ne garantit pas l'absence d'overcommit.
Jean-Louis Liagre
Nicolas George wrote:
Jean-Louis Liagre wrote in message <45db27ee$0$3885$:
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le l'overcommit a 2 et je laisse la config par defaut (50%). Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de RAM !!!, qui sont inutilisables ...
Si je te comprends bien, tu te plains que si tu mets des valeurs fantaisistes pour la taille du swap et les sysctl, le système fonctionne de manière sous-optimale ? Je dois dire que ça ne me surprend pas.
La taille du swap me regarde, elle n'a rien de fantaisiste si la taille de la RAM est suffisante aux besoins des applications que je fait tourner.
Les sysctl ont leur valeurs par defaut et en effet, Linux fait preuve ici de beaucoup de fantaisie.
Nicolas George wrote:
Jean-Louis Liagre wrote in message
<45db27ee$0$3885$426a74cc@news.free.fr>:
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le
l'overcommit a 2 et je laisse la config par defaut (50%).
Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les
allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de
RAM !!!, qui sont inutilisables ...
Si je te comprends bien, tu te plains que si tu mets des valeurs
fantaisistes pour la taille du swap et les sysctl, le système fonctionne de
manière sous-optimale ? Je dois dire que ça ne me surprend pas.
La taille du swap me regarde, elle n'a rien de fantaisiste si la taille
de la RAM est suffisante aux besoins des applications que je fait tourner.
Les sysctl ont leur valeurs par defaut et en effet, Linux fait preuve
ici de beaucoup de fantaisie.
Jean-Louis Liagre wrote in message <45db27ee$0$3885$:
Admettons que j'ai 8 Go de RAM et 1 Go de swap. Je positionne le l'overcommit a 2 et je laisse la config par defaut (50%). Mon hardware + noyau utilisent 128Mo, l'O/S va donc refuser les allocations au dela de "1Go + (8Go-128Mo)*50%" soit 4.94 Go.
J'ai donc plus de 4 Gigas de memoire virtuelle, dont plus de 3 gigas de RAM !!!, qui sont inutilisables ...
Si je te comprends bien, tu te plains que si tu mets des valeurs fantaisistes pour la taille du swap et les sysctl, le système fonctionne de manière sous-optimale ? Je dois dire que ça ne me surprend pas.
La taille du swap me regarde, elle n'a rien de fantaisiste si la taille de la RAM est suffisante aux besoins des applications que je fait tourner.
Les sysctl ont leur valeurs par defaut et en effet, Linux fait preuve ici de beaucoup de fantaisie.
Jean-Louis Liagre
Sébastien Monbrun aka TiChou wrote:
Dans le message <news:45dc7da6$0$7501$, *Jean-Louis Liagre* tapota sur f.c.o.unix :
Date: Wed, 21 Feb 2007 18:13:54 -0800 NNTP-Posting-Date: 21 Feb 2007 18:13:10 MET
Il était 18 h 13 quand vous avez posté, et non 3 h 13 du matin.
Mauvais fuseau horaire, changer de fuseau horaire.
C'est fait, enfin j'espere.
Sébastien Monbrun aka TiChou wrote:
Dans le message <news:45dc7da6$0$7501$426a74cc@news.free.fr>,
*Jean-Louis Liagre* tapota sur f.c.o.unix :
Date: Wed, 21 Feb 2007 18:13:54 -0800
NNTP-Posting-Date: 21 Feb 2007 18:13:10 MET
Il était 18 h 13 quand vous avez posté, et non 3 h 13 du matin.
Mauvais fuseau horaire, changer de fuseau horaire.
