Découvrez où la mémoire est consommée

Question

J'ai ce code d'application numérique relativement grand qui peut durer quelques jours et éventuellement cracher des nombres. Le tout est écrit en C++, en utilisant un tas de bibliothèques tierces, et compilé en utilisant GCC 4.6. Le code utilise des pointeurs partagés partout.

Malheureusement, avec le temps, la consommation de mémoire du code augmente jusqu'à ce que toute la mémoire (partagée) soit épuisée, puis tombe en panne. Algorithmiquement, le code ne devrait pas accumuler de mémoire au fil du temps, donc il y aura un bug quelque part.

J'ai exécuté un petit exemple à travers le vérificateur de fuite de valgrind qui rapporte que tout devrait bien se passer. Ma pensée était que des pointeurs partagés pourraient involontairement être créés quelque part, empêchant des données inutiles d'être libérées le long du processus (mais c'est juste une estimation). À la fin de la journée, je suis à court d'idées sur la façon de déboguer une telle chose. Des idées?

Answer 1

Puisque vous avez déjà la suite d'outils valgrind disponible, je vous conseille d'utiliser l'outil massif.

Massif effectuera le suivi des origines d'allocation de mémoire et le rapport vous indiquera combien d'octets chaque site/fonction d'allocation a été créé. Cela vous aidera à comprendre d'où vient cette explosion de mémoire.

Answer 2

Même si vous n'avez pas de fuite, vous pourriez être confronté à une fragmentation de la mémoire.

Si vous êtes sur Linux, je suggère d'essayer jemalloc allocator. Cela fonctionne très bien sur Linux. Il fonctionne sur de nombreuses architectures, je l'ai utilisé avec succès même sur zLinux (sur IBM zSeries mainframe). Il est vraiment facile à utiliser - vous ne devez même pas reconstruire votre application ou des bibliothèques, juste construire jemalloc et démarrer votre application avec LD_PRELOAD jeu comme celui-ci: LD_PRELOAD=/usr/lib/libjemalloc.so <app>

Answer 3

GNU libstdc par défaut ++ pour la mise en cache des allocations de mémoire liés à la STL, apparemment pour des raisons de vitesse microbenchmark. Cependant, l'effet réel a tendance à être assez négatif pour la vitesse et l'empreinte de la mémoire lors de l'utilisation d'allocateurs tels que tcmalloc et jemalloc. tcmalloc désactive ce comportement en définissant GLIBCPP_FORCE_NEW = 1 et GLIBCXX_FORCE_NEW = 1 dans l'environnement (pour libstdc++ versions 3.3 et 3.4, respectivement), mais je ne connais aucun autre allocateur qui le fait. Par conséquent, il est généralement recommandé de définir la variable d'environnement appropriée lors du lancement de votre application.