• [^] # Re: Volumétrie

    Posté par . En réponse au message MySQL - oom killer. Évalué à 1.

    Oui alors il y a :
    - 2 "grosses" bases de données qui génèrent 99.9% de la charge
    - une dizaine de petites DB's mais qui ne sont pas beaucoup sollicitées
    - la première base c'est l'applicatif ; 190 Go sur disque ; 603 tables
    - la deuxième base c'est les logs ; 259 Go sur disque ; 13 tables
    - moteur = InnoDB dans les deux cas

    Pour donner une information complémentaire, depuis le redémarrage de MySQL :
    - toute la journée je suis resté à 20% de mémoire environ (ps aux)
    - la nuit, pendant les sauvegardes, je suis monté à 75%
    - le lendemain (donc hier) ça a continué de monté jusqu'à 80%
    - cette nuit, on est retombé à 68%

    On aurait pu penser qu'il s'agissait d'un soucis avec mysqldump mais j'ai lancé la même sauvegarde sur un des slave : la mémoire utilisée n'a pas bougée.

    J'ai revérifié les traitements qui tournaient dans ces heures la : rien de spécial. Et surtout il n'y a aucune modification de code qui pourrait expliquer une telle consommation.

    J'ai suivi la piste d'une attaque sur des sites (même s'ils ne sont pas référencés etc) : rien à déclarer.

    Du coup je me pose plusieurs questions :
    - fuite mémoire de MySQL ?
    - problème dans le kernel (3.18.9 hardened - Gentoo) ?
    - ma configuration qui n'est pas bonne (d'après toutes les règles de calcul on a de la marge)
    - suite logique des briquage de samedi ?

    Malheureusement je ne trouve aucune information nul part :-/