Il y a clairement des manques dans les cgroups. Par exemple au niveau de la limitation de la mémoire:
Avec vserver, il y a moyen de limiter la mémoire en terme de mémoire virtuelle (mem + swap). C'est le kernel qui globalement, décidera si cela vaut le coup de swapper ou non. Et, si tu dépasses le quota, tu ne peux plus allouer de mémoire (logique non?)
Avec les cgroups, tu dois configurer une limite en terme de mémoire + une limite en terme de swap. Cela pose un premier problème, cela force à swapper, quand l'hôte à encore de la mémoire disponible ! De plus, et c'est là le plus drôle, l'allocation n'est pas bloquée. Donc un process essayant d'allouer plus que son quota va pouvoir allouer (dans le swap), mais va se faire killé par l'oomkiller. Donc, il va écrire dans le swap, puis le kernel va vider le swap. Imagines que cela arrive à un processus apache (+ mod_php), aussitôt killé, le master va chercher à le relancer. Cela fait une très jolie forkbomb qui en plus va faire plein d'aller et retour dans le swap et peut finir facilement par écrouler l'hôte. L'oom-killer de la version 2.6.37 devrait diminuer un peu le problème, mais ... avoir une vrai limite en terme de mémoire virtuelle, et des allocations bloquées quand le quota est dépassé serait un poil mieux.
Bref, les cgroups c'est pas encore ça. Vserver permet de les utiliser, mais, je suis en train de voir comment repasser sur l'ancien comportement, lui au moins ne faisait pas monter le load de la machine à 500.
[^] # Re: Manque de doc...
Posté par geb . En réponse au journal OpenVZ & LXC. Évalué à 3.
J'avais commencé à troller sur https://linuxfr.org/users/jyes/journaux/mauvaise-surprise-virtuelle%E2%80%A6 mais le journal commençant à mourir, je n'ai pas continué :)
Il y a clairement des manques dans les cgroups. Par exemple au niveau de la limitation de la mémoire:
Avec vserver, il y a moyen de limiter la mémoire en terme de mémoire virtuelle (mem + swap). C'est le kernel qui globalement, décidera si cela vaut le coup de swapper ou non. Et, si tu dépasses le quota, tu ne peux plus allouer de mémoire (logique non?)
Avec les cgroups, tu dois configurer une limite en terme de mémoire + une limite en terme de swap. Cela pose un premier problème, cela force à swapper, quand l'hôte à encore de la mémoire disponible ! De plus, et c'est là le plus drôle, l'allocation n'est pas bloquée. Donc un process essayant d'allouer plus que son quota va pouvoir allouer (dans le swap), mais va se faire killé par l'oomkiller. Donc, il va écrire dans le swap, puis le kernel va vider le swap. Imagines que cela arrive à un processus apache (+ mod_php), aussitôt killé, le master va chercher à le relancer. Cela fait une très jolie forkbomb qui en plus va faire plein d'aller et retour dans le swap et peut finir facilement par écrouler l'hôte. L'oom-killer de la version 2.6.37 devrait diminuer un peu le problème, mais ... avoir une vrai limite en terme de mémoire virtuelle, et des allocations bloquées quand le quota est dépassé serait un poil mieux.
Bref, les cgroups c'est pas encore ça. Vserver permet de les utiliser, mais, je suis en train de voir comment repasser sur l'ancien comportement, lui au moins ne faisait pas monter le load de la machine à 500.