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.
Alors essaie déjà :
ulimit -v mémoire_max_en_Ko
À lancer depuis le shell avant la commande concernée (dans un script dédié, sinon les suivantes seront impactées aussi).
Pour plus de détails, man bash, puis taper /ulimit
(man ulimit concerne une version générale beaucoup plus limitée).
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.
J’ai vu le cas de logiciels (notamment un navigateur web pour lequel c’est flagrant, peut-être Midori, mais je ne suis pas sûr) qui allouent une quantité de mémoire très importante mais n’en utilisent réellement qu’un peu. Peut-être est-ce un préalable à une gestion interne de l’allocation mémoire qui permet de la simplifier.
Et swapper sur des mémoires fragiles, c'est pas franchement pertinent non plus.
Et en n’allouant pas de swap (une façon efficace de ne pas en utiliser), est-ce que MySQL fonctionne quand même ou pas ?
J’aurais tendance à penser que la taille mémoire totale (physique + swap) fixe une limite à l’overcommit, mais ça reste à voir...
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données
Posté par Arthur Accroc . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 3. Dernière modification le 11 novembre 2019 à 07:10.
Alors essaie déjà :
ulimit -v mémoire_max_en_Ko
À lancer depuis le shell avant la commande concernée (dans un script dédié, sinon les suivantes seront impactées aussi).
Pour plus de détails, man bash, puis taper /ulimit
(man ulimit concerne une version générale beaucoup plus limitée).
J’ai vu le cas de logiciels (notamment un navigateur web pour lequel c’est flagrant, peut-être Midori, mais je ne suis pas sûr) qui allouent une quantité de mémoire très importante mais n’en utilisent réellement qu’un peu. Peut-être est-ce un préalable à une gestion interne de l’allocation mémoire qui permet de la simplifier.
Et en n’allouant pas de swap (une façon efficace de ne pas en utiliser), est-ce que MySQL fonctionne quand même ou pas ?
J’aurais tendance à penser que la taille mémoire totale (physique + swap) fixe une limite à l’overcommit, mais ça reste à voir...
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone