Vérification de toutes les utilisations de la mémoire pendant l'exécution d'une application C++

Question

J'utilise CentOS 7 et j'utilise une application C++. Récemment, je suis passé à une version plus récente d'une bibliothèque que l'application utilisait pour diverses fonctions de l'API C de MySQL. Mais après l'intégration de la nouvelle bibliothèque, j'ai vu une augmentation énorme de l'utilisation de la mémoire du programme, c'est-à-dire que l'application se bloque si elle reste en fonctionnement pendant plus d'un jour ou deux. Précisément, ce qui se passe, c'est que l'utilisation de la mémoire pour l'application commence à augmenter jusqu'à un point où l'application seule utilise 74,9% de la mémoire totale du système, puis elle est arrêtée de force par le système.

Existe-t-il un moyen de suivre l'utilisation de la mémoire de l'ensemble de l'application, y compris les variables statiques. J'ai déjà essayé l'outil de valgrind Massif. Quelqu'un peut-il me dire quelles pourraient être les raisons possibles de l'utilisation accrue de la mémoire ou des outils qui peuvent me donner un aperçu de la façon dont la mémoire est allouée (à la fois statique et dynamique). Y at-il un outil qui peut nous parler de l'allocation de mémoire pour une application C++ fonctionnant dans un environnement Linux?

Merci d'avance!

Answer 1

La mémoire statique est allouée lorsque le programme démarre. Voyez-vous une croissance de la mémoire ou une augmentation de démarrage?

Comme il faut compter un jour ou deux pour tomber en panne, le problème est probablement une fuite de mémoire ou une croissance illimitée d'une structure de données. Valgrind devrait être capable d'aider avec les deux. Si valgrind montre une grosse fuite avec l'option --leak-check-full alors vous aurez probablement trouvé le problème.

Pour vérifier la croissance illimitée, placez un _exit() préemptif dans le programme à un point où vous pensez que le tas a augmenté. Par exemple, mettez une minuterie sur la boucle principale et exécutez le programme _exit après 10 minutes. Si le valgrind montre un grand 'en cours d'utilisation' à la sortie, alors vous avez probablement une croissance illimitée d'une structure de données mais pas une fuite. Massif peut aider à dépister cela. Ms_print donne des détails sur les allocations avec la pile de fonctions.

Si vous trouvez un problème, essayez de revenir à l'ancienne version de votre bibliothèque. Si le problème disparaît, vérifiez et assurez-vous que vous utilisez correctement l'API dans la nouvelle version. Si vous n'avez pas le code source, vous êtes un peu coincé en termes de correctif.

Si vous voulez faire un effort supplémentaire, vous pouvez écrire un interposeur de bibliothèque partagée pour malloc/free pour voir ce qui se passe. Voici un bon start. Linux a la fonctionnalité backtrace qui peut aider à déterminer la pile exacte. Enfin, si vous devez utiliser la bibliothèque tierce et constater que le tas croît sans limite ou sans fuite, vous pouvez utiliser l'interposeur de bibliothèque partagée pour appeler/supprimer directement. C'est une stratégie risquée et non recommandée, mais j'ai utilisé la production pour boiter un processus.