Tu comprends mal. Un des logiciels maisons faits a eu une fuite de mémoire. Réactiver l'overcommit, et ajouter les conditions à la fuite mémoire à fait freeze les systèmes. Déplacement obligatoire pour rebooter, à plusieurs centaines de kilomètres.
Quand l'overcommit était désactivé, ben, sql marchait pas, mais le prog avec fuite mémoire se serait fait tuer dès le 1er dépassement de capacité, ce qui aurait évité le freeze.
N'étant pas un dev kernel, ni mysql/mariadb, je n'ai sûrement pas toutes les clés en main, mais pour moi, allouer plus de mémoire qu'il n'y en a vraiment de dispo sur le système, c'est une mauvaise chose que ça réussisse. Et swapper sur des mémoires fragiles, c'est pas franchement pertinent non plus. Le choix de mysql était de base mal fait, mais voila, il a été fait avant que j'arrive, je n'ai pas eu mon mot a dire, alors j'ai fait avec de mon mieux.
Ah, j'oubliais, ces systèmes embarqués (aujourd'hui, un peu plus de 200) à plusieurs 10aines voires 100aines de km, sur lesquels on a la main via de la 2/3G (et ce, de façon aléatoire compte tenu de la captation de certains coins), ils utilisent runit pour gérer le moindre service, donc si l'un d'eux meurt, il est relancé à propre, ce qui réduit considérablement le problème. J'aurais pu utiliser systemd aussi, certes, ça serait revenu au même. J'aurai aussi pu utiliser les cgroups, il faudrait, même, mais voila, il faut le projet avance et je sais pas utiliser les cgroups.
SInon, ça a quoi de magique pour toi, l'overcommit? A quel moment tu trouves ça logique d'allouer des ressources inexistantes à un processus?
[^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données
Posté par freem . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 3. Dernière modification le 10 novembre 2019 à 02:30.
Tu comprends mal. Un des logiciels maisons faits a eu une fuite de mémoire. Réactiver l'overcommit, et ajouter les conditions à la fuite mémoire à fait freeze les systèmes. Déplacement obligatoire pour rebooter, à plusieurs centaines de kilomètres.
Quand l'overcommit était désactivé, ben, sql marchait pas, mais le prog avec fuite mémoire se serait fait tuer dès le 1er dépassement de capacité, ce qui aurait évité le freeze.
N'étant pas un dev kernel, ni mysql/mariadb, je n'ai sûrement pas toutes les clés en main, mais pour moi, allouer plus de mémoire qu'il n'y en a vraiment de dispo sur le système, c'est une mauvaise chose que ça réussisse. Et swapper sur des mémoires fragiles, c'est pas franchement pertinent non plus. Le choix de mysql était de base mal fait, mais voila, il a été fait avant que j'arrive, je n'ai pas eu mon mot a dire, alors j'ai fait avec de mon mieux.
Ah, j'oubliais, ces systèmes embarqués (aujourd'hui, un peu plus de 200) à plusieurs 10aines voires 100aines de km, sur lesquels on a la main via de la 2/3G (et ce, de façon aléatoire compte tenu de la captation de certains coins), ils utilisent runit pour gérer le moindre service, donc si l'un d'eux meurt, il est relancé à propre, ce qui réduit considérablement le problème. J'aurais pu utiliser systemd aussi, certes, ça serait revenu au même. J'aurai aussi pu utiliser les cgroups, il faudrait, même, mais voila, il faut le projet avance et je sais pas utiliser les cgroups.
SInon, ça a quoi de magique pour toi, l'overcommit? A quel moment tu trouves ça logique d'allouer des ressources inexistantes à un processus?