Donc, suite à ça,j'ai regardé à gauche à droite, mais j'ai pas la prétention de tout piger d'un coup, donc si je dit une connerie, faut le dire :).
Donc l'idée, est d'avoir un processus lancé par init, et ce processus, via un appel système, devient un "init local". Comme ça veut rien dire, j'explique. par init local, j'entends un processus en charge de recevoir les signaux des orphans, tout comme init, et qui chope les zombies pour les tuer, ce qui semble éviter les cgroups pour suivre les process, et ce qui permet de pousser le code en dehors du pid 1.
C'est une approche intéressante, mais ça veut pas dire une occupation doublé dans la table des processus ?
Genre si je lance 10 000 containers, je vais avoir 10 000 processus de supervision. C'est pas un souci en temps normal et pas un souci pour tout de suite ( voir même un souci pour jamais peut être ), mais si tu imagines 100 Mo par containers, ça va te faire 1T de ram pour 1000 ( ce qui est faisable ), donc on est pas loin du stade ou ça va AMHA poser souci ( genre vers les 10000/20000 ). Bien sur, avec un systéme comme ksm, et avec des containers plus petits, ça peut arriver vite.
Ensuite, peut être que c'est le cpu et les I/O qui vont tomber en premier donc je me fait des idées.
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 1.
Donc, suite à ça,j'ai regardé à gauche à droite, mais j'ai pas la prétention de tout piger d'un coup, donc si je dit une connerie, faut le dire :).
Donc l'idée, est d'avoir un processus lancé par init, et ce processus, via un appel système, devient un "init local". Comme ça veut rien dire, j'explique. par init local, j'entends un processus en charge de recevoir les signaux des orphans, tout comme init, et qui chope les zombies pour les tuer, ce qui semble éviter les cgroups pour suivre les process, et ce qui permet de pousser le code en dehors du pid 1.
C'est une approche intéressante, mais ça veut pas dire une occupation doublé dans la table des processus ?
Genre si je lance 10 000 containers, je vais avoir 10 000 processus de supervision. C'est pas un souci en temps normal et pas un souci pour tout de suite ( voir même un souci pour jamais peut être ), mais si tu imagines 100 Mo par containers, ça va te faire 1T de ram pour 1000 ( ce qui est faisable ), donc on est pas loin du stade ou ça va AMHA poser souci ( genre vers les 10000/20000 ). Bien sur, avec un systéme comme ksm, et avec des containers plus petits, ça peut arriver vite.
Ensuite, peut être que c'est le cpu et les I/O qui vont tomber en premier donc je me fait des idées.