2016-08-19 5 views
2

Я использую CentOS 7, и я запускаю приложение C++. Недавно я переключился на более новую версию библиотеки, которую приложение использовало для различных функций API MySQL C. Но после интеграции новой библиотеки я увидел огромное увеличение использования памяти в программе, то есть приложение выйдет из строя, если его осталось работать больше дня или двух. Точно так же происходит, что использование памяти для приложения начинает увеличиваться до того момента, когда одно приложение использует 74,9% общей памяти системы, а затем оно принудительно отключается системой.Проверка всех видов использования памяти во время выполнения приложения C++

Есть ли способ отслеживать использование памяти для всего приложения, включая статические переменные. Я уже пробовал инструмент valgrind Massif.

Может ли кто-нибудь сказать мне, какие могут быть возможные причины увеличения использования памяти или какие-либо инструменты, которые могут дать мне глубокое понимание того, как выделяется память (как статическая, так и динамическая). Есть ли какой-нибудь инструмент, который может рассказать нам о распределении памяти для приложения C++, работающего в среде Linux?

Заранее благодарен!

+2

Valgrind должен быть правильным инструментом для анализа этой проблемы, которая, по-видимому, является классической утечкой памяти. –

+0

@ Torbjörn, я также проверил с valgrind, а разница в распределении памяти в разделе HEAP SUMMARY, который появляется для выполнения приложения, составляет около 1 ГБ для продолжительности работы около 10 минут. – Abhinav

+0

Вы также можете переопределить глобальный новый оператор и удалить операторы. Я сделал это раньше, чтобы сохранить кеш с выделенными ячейками памяти, которые еще не удалены. Затем отдельный поток, который печатает эту информацию каждые несколько минут. – Dennis

ответ

1

Статическая память выделяется при запуске программы. Вы видите рост памяти или увеличение загрузки?

Так как требуется «день или два, чтобы потерпеть крах», проблема, скорее всего, утечка памяти или неограниченный рост структуры данных. Valgrind должен быть в состоянии помочь с обоими. Если valgrind показывает большую утечку с параметром --leak-check-full, вы, скорее всего, найдете проблему.

Чтобы проверить неограниченный рост, поставьте упреждающее _exit() в программе в точке, где вы подозреваете, что куча выросла. Например, поместите таймер в основной цикл и запустите программу _exit через 10 минут. Если valgrind показывает большую «в использовании при выходе», то у вас, вероятно, будет неограниченный рост структуры данных, но не утечка. Massif может помочь проследить это. Ms_print предоставляет детали распределения с помощью стека функций.

Если вы обнаружили ошибку, попробуйте вернуться к старой версии вашей библиотеки. Если проблема исчезнет, ​​проверьте и убедитесь, что вы правильно используете API в новой версии. Если у вас нет исходного кода, вы немного застряли в исправлении.

Если вы хотите пройти лишнюю милю, вы можете написать совместное использование библиотеки для malloc/free, чтобы увидеть, что происходит. Вот хороший start. Linux имеет функциональность backtrace, которая может помочь в определении точного стека.

Наконец, если вы должны использовать стороннюю библиотеку и найти кучу, растущую без ограничения или утечки, вы можете использовать совместно используемый библиотечный интерполятор для прямого вызова free/delete. Это рискованная стратегия с непревзойденным качеством, но я использовал в производстве, чтобы хромать процесс.