Поиск памяти, используемой с помощью файла ядра
Я анализирую проблему высокого потребления памяти в нашем программном обеспечении. У меня есть файл ядра, соответствующий этому высокому потреблению памяти (этот файл ядра создается путем уничтожения нашего приложения, которое генерирует файл ядра). Но я не могу просмотреть фактическое потребление памяти с помощью этого файла ядра. Я использовал Totalview и GDB … используя эти два, я не получаю снимок общего объема памяти, используемой моим процессом, и какая библиотека занимает всю память.
Это потребление памяти поражает нас в течение 10-20 дней, и поэтому я пытаюсь выяснить, что вызвало такое высокое потребление памяти.
Может ли valgrind помочь мне в анализе этого файла ядра?
Любой вклад / предложение высоко ценится.
Решение
@suresh,
Привет, я менеджер по продукту для TotalView в Rogue Wave Software.
Можете ли вы описать сценарий немного больше? Программа работает в течение долгого времени вместе с «нормальным потреблением памяти», а затем внезапно потребление памяти проходит через крышу? Или программа медленно и стабильно потребляет память до тех пор, пока не исчерпает доступные ресурсы?
Когда происходит сбой, происходит ли сбой, потому что у него буквально заканчивается память, или вы убиваете его, потому что он начал обмениваться и перестать отвечать?
В общем, я бы рекомендовал запустить его под MemoryScape (в TotalView или в автономной версии), и когда он начинает показывать неожиданное потребление памяти, вы хотите приостановить его и запустить отчет об утечке памяти. Вполне вероятно, что это будет указывать прямо на проблему.
Возможно, использование памяти не является «классической» утечкой, потому что у вас все еще есть указатели, ссылающиеся на данные, — но вы просто перераспределяете. В этом случае вы ничего не увидите в отчете об утечке, но, возможно, сможете определить, какое распределение «испортилось», наблюдая, какие распределения растут. Есть несколько способов сделать это.
-
Периодически делайте паузу и отмечайте, как распределяется использование кучи в отчете «Исходный код состояния кучи». Например, вы можете заметить, что количество выделений, связанных с конкретным файлом исходного кода, продолжает увеличиваться.
-
Если вы используете TotalView, вы можете использовать функциональность «set heap baseline», когда программа, кажется, ведет себя хорошо, а затем отфильтровать по этой базовой линии. Опять же, вы можете захотеть использовать отчет с исходным кодом (хотя графические отчеты или отчеты об обратном следе также поддерживают фильтрацию).
-
Или вы можете использовать функцию «экспорта данных из памяти», чтобы сохранить изображение «нормального» состояния кучи. Это создает двоичный файл состояния кучи. Затем позвольте программе работать, пока вы не попадете в состояние, в котором ваша программа потребляет много памяти. В этот момент вы приостанавливаете свое живое приложение, загружаете сохраненный файл данных кучи и вы можете сделать сравнение.
Вау, это становится длинным. Одна заключительная мысль. Вы сказали, что получаете основные файлы. Под отладчиком у вас должна быть возможность проверить работающую программу, прежде чем она будет очищена. Если этого не произойдет, дайте мне знать. Если вы действительно хотите работать с основными файлами (например, это происходит в производственной среде, и вы не хотите запускать там отладчик), сообщите нам об этом — существуют методы, с помощью которых мы можем применить приложение с помощью HIA и Затем вы сможете в автономном режиме анализировать состояние вашей кучи.
Удачи!
Крис Готбрат
Главный менеджер по продуктам для TotalView и ThreadSpotter, Rogue Wave Software
электронная почта: первая последний в roguewave. ком
Другие решения
Других решений пока нет …