Je comprends bien l’intérêt, ce qui me gène, c’est la prédictibilité.
C’est un peu comme la stratégie d’allocation mémoire de Linux.
man malloc
« BOGUES
Par défaut, Linux suit une stratégie d'allocation optimiste. Ceci signifie que lorsque malloc () renvoie une valeur non-NULL, il n'y a aucune garantie que la mémoire soit véritablement disponible. C'est vraiment un bogue craignos. Dans le cas où le système manque de mémoire, un ou plusieurs processus seront tués par l'infâme exterminateur de gestion mémoire. Dans le cas où Linux est utilisé dans des circonstances où il n'est pas souhaitable de perdre soudainement des processus lancés aléatoirement, et si de plus la version du noyau est suffisamment récente, on peut désactiver ce comportement en utilisant une commande du style : # echo 2 > /proc/sys/vm/overcommit_memory Voir également les fichiers vm/overcommit-accounting et sysctl/vm.txt dans le répertoire de la documentation du noyau. »
J’ai eu le problème en entreprise, où sur un serveur de session avec 16Go de RAM, les éditeurs de code, session était killé aléatoirement. L’admin n’a jamais voulu faire la manip décrite.
[^] # Re: Ça à l’air bien...
Posté par Anthony Jaguenaud . En réponse au journal Enlarge your ZFS pool. Évalué à 5.
C’est un peu comme la stratégie d’allocation mémoire de Linux.
man malloc
« BOGUES
Par défaut, Linux suit une stratégie d'allocation optimiste. Ceci signifie que lorsque malloc () renvoie une valeur non-NULL, il n'y a aucune garantie que la mémoire soit véritablement disponible. C'est vraiment un bogue craignos. Dans le cas où le système manque de mémoire, un ou plusieurs processus seront tués par l'infâme exterminateur de gestion mémoire. Dans le cas où Linux est utilisé dans des circonstances où il n'est pas souhaitable de perdre soudainement des processus lancés aléatoirement, et si de plus la version du noyau est suffisamment récente, on peut désactiver ce comportement en utilisant une commande du style : # echo 2 > /proc/sys/vm/overcommit_memory Voir également les fichiers vm/overcommit-accounting et sysctl/vm.txt dans le répertoire de la documentation du noyau. »
J’ai eu le problème en entreprise, où sur un serveur de session avec 16Go de RAM, les éditeurs de code, session était killé aléatoirement. L’admin n’a jamais voulu faire la manip décrite.
Ce que j’aime pas c’est le côté loto des choses.