Date: Wed, 21 Feb 2007 09:42:04 -0800
NNTP-Posting-Date: 21 Feb 2007 18:41:18 MET
C'est fait, enfin j'espere.
Non, raté.
Date: Wed, 21 Feb 2007 09:42:04 -0800
NNTP-Posting-Date: 21 Feb 2007 18:41:18 MET
C'est fait, enfin j'espere.
Non, raté.
Date: Wed, 21 Feb 2007 09:42:04 -0800
NNTP-Posting-Date: 21 Feb 2007 18:41:18 MET
C'est fait, enfin j'espere.
Non, raté.
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 :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.
Peux-tu en dire plus sur ces tests ?
Ma comprehension est qu'il s'agit d'une taille globale, sinon je ne vois
pas comment le noyau pourrait respecter le calcul indique dans la doc.
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 ?
Parce que ca violerait la regle que fait respecter le strict overcommit.
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.
Dans la vraie vie, c'est a dire une machine de production. Il me parait
inacceptable de laisser a l'O/S le soin de choisir quelle application il
va tuer pour faire de la place en memoire. Je veux bien qu'un programme
se plante si un malloc qu'il fait echoue, c'est tout.
Cela évite généralement de rebooter sauvagement un serveur.
Un malloc/new ou mmap qui plante, ca ne fait pas rebooter 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.
Une fuite memoire sera je l'espere detectee avant de mettre le code en
production. 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.
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.
Tu ne repond pas au probleme que je decris.
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. Solaris fait ca en
standard, Linux est incapable de me fournir une solution sans un tuning
qui de toute facon sera forcement imprecis.
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 :
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.
Peux-tu en dire plus sur ces tests ?
Ma comprehension est qu'il s'agit d'une taille globale, sinon je ne vois
pas comment le noyau pourrait respecter le calcul indique dans la doc.
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 ?
Parce que ca violerait la regle que fait respecter le strict overcommit.
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.
Dans la vraie vie, c'est a dire une machine de production. Il me parait
inacceptable de laisser a l'O/S le soin de choisir quelle application il
va tuer pour faire de la place en memoire. Je veux bien qu'un programme
se plante si un malloc qu'il fait echoue, c'est tout.
Cela évite généralement de rebooter sauvagement un serveur.
Un malloc/new ou mmap qui plante, ca ne fait pas rebooter 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.
Une fuite memoire sera je l'espere detectee avant de mettre le code en
production. 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.
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.
Tu ne repond pas au probleme que je decris.
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. Solaris fait ca en
standard, Linux est incapable de me fournir une solution sans un tuning
qui de toute facon sera forcement imprecis.
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 :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.
Peux-tu en dire plus sur ces tests ?
Ma comprehension est qu'il s'agit d'une taille globale, sinon je ne vois
pas comment le noyau pourrait respecter le calcul indique dans la doc.
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 ?
Parce que ca violerait la regle que fait respecter le strict overcommit.
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.
Dans la vraie vie, c'est a dire une machine de production. Il me parait
inacceptable de laisser a l'O/S le soin de choisir quelle application il
va tuer pour faire de la place en memoire. Je veux bien qu'un programme
se plante si un malloc qu'il fait echoue, c'est tout.
Cela évite généralement de rebooter sauvagement un serveur.
Un malloc/new ou mmap qui plante, ca ne fait pas rebooter 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.
Une fuite memoire sera je l'espere detectee avant de mettre le code en
production. 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.
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.
Tu ne repond pas au probleme que je decris.
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. Solaris fait ca en
standard, Linux est incapable de me fournir une solution sans un tuning
qui de toute facon sera forcement imprecis.
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.
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.
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.
C'est pour les 46 secondes d'avance que tu dis raté ? ;-)
C'est pour les 46 secondes d'avance que tu dis raté ? ;-)
C'est pour les 46 secondes d'avance que tu dis raté ? ;-)
Sébastien Monbrun aka TiChou wrote in message
:C'est pour les 46 secondes d'avance que tu dis raté ? ;-)
Non, pour le NNTP-Posting-Host qui, d'après whois, a de bonnes chances de se
trouver en Belgique.
Sébastien Monbrun aka TiChou wrote in message
<gniii.20070221191452@florizarre.tichou.org>:
C'est pour les 46 secondes d'avance que tu dis raté ? ;-)
Non, pour le NNTP-Posting-Host qui, d'après whois, a de bonnes chances de se
trouver en Belgique.
Sébastien Monbrun aka TiChou wrote in message
:C'est pour les 46 secondes d'avance que tu dis raté ? ;-)
Non, pour le NNTP-Posting-Host qui, d'après whois, a de bonnes chances de se
trouver en Belgique.
Non, pour le NNTP-Posting-Host qui, d'après whois, a de bonnes chances
de se trouver en Belgique.
C'est interdit ?
Non, pour le NNTP-Posting-Host qui, d'après whois, a de bonnes chances
de se trouver en Belgique.
C'est interdit ?
Non, pour le NNTP-Posting-Host qui, d'après whois, a de bonnes chances
de se trouver en Belgique.
C'est interdit ?
Non, mais Nicolas faisait juste remarquer que le fuseau n'était toujours pas
le bon.
Maintenant c'est ok.
Non, mais Nicolas faisait juste remarquer que le fuseau n'était toujours pas
le bon.
Maintenant c'est ok.
Non, mais Nicolas faisait juste remarquer que le fuseau n'était toujours pas
le bon.
Maintenant c'est ok.
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.
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.
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.
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. Solaris fait ca en
standard, Linux est incapable de me fournir une solution sans un tuning
qui de toute facon sera forcement imprecis.
On ne va pas parler de la gestion mémoire de SunOS. Je me suis tapé
toutes les version du bazar depuis la 4.1. Effectivement, il n'y a
pas (à ma connaissance) d'overcommit
, mais la gestion mémoire est
souvent complètement désastreuse. Au prix ou Sun vend sa mémoire, il
vaut mieux que le système l'utilise.
Exemple frappant : un serveur
en prod avec deux procs, Solaris 9 (à jour) et 2 Go de mémoire. Une
grosse application java tourne là dessus et la machine utilise aux
alentours de 1Go de mémoire. Le reste ne sert même pas à du cache
disque !...
Je préfère pour ma part avoir un système d'overcommit
comme celui de Linux, ce qui permet au moins de gérer efficacement
un cache disque en RAM.
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. Solaris fait ca en
standard, Linux est incapable de me fournir une solution sans un tuning
qui de toute facon sera forcement imprecis.
On ne va pas parler de la gestion mémoire de SunOS. Je me suis tapé
toutes les version du bazar depuis la 4.1. Effectivement, il n'y a
pas (à ma connaissance) d'overcommit
, mais la gestion mémoire est
souvent complètement désastreuse. Au prix ou Sun vend sa mémoire, il
vaut mieux que le système l'utilise.
Exemple frappant : un serveur
en prod avec deux procs, Solaris 9 (à jour) et 2 Go de mémoire. Une
grosse application java tourne là dessus et la machine utilise aux
alentours de 1Go de mémoire. Le reste ne sert même pas à du cache
disque !...
Je préfère pour ma part avoir un système d'overcommit
comme celui de Linux, ce qui permet au moins de gérer efficacement
un cache disque en RAM.
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. Solaris fait ca en
standard, Linux est incapable de me fournir une solution sans un tuning
qui de toute facon sera forcement imprecis.
On ne va pas parler de la gestion mémoire de SunOS. Je me suis tapé
toutes les version du bazar depuis la 4.1. Effectivement, il n'y a
pas (à ma connaissance) d'overcommit
, mais la gestion mémoire est
souvent complètement désastreuse. Au prix ou Sun vend sa mémoire, il
vaut mieux que le système l'utilise.
Exemple frappant : un serveur
en prod avec deux procs, Solaris 9 (à jour) et 2 Go de mémoire. Une
grosse application java tourne là dessus et la machine utilise aux
alentours de 1Go de mémoire. Le reste ne sert même pas à du cache
disque !...
Je préfère pour ma part avoir un système d'overcommit
comme celui de Linux, ce qui permet au moins de gérer efficacement
un cache disque en RAM.
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.
POSIX ne garantit pas l'absence d'overcommit.
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.
