Я схожу с ума, пытаясь найти утечку памяти в одном из наших основных ящиков. Он работает под управлением CentOS, ядро 2.6.18, x86-64. Коробка (фактически виртуальная машина на Xen) отлично работает без проблем с тех пор, как была создана около 6 месяцев назад. Он был создан для замены старого физического бокса и был настроен таким же образом. Виртуальная машина - это веб-сервер, на котором работают только Tomcat и Apache. Он был прочным, без проблем и без утечек памяти.
Около двух недель назад у нас возникла проблема, когда два из четырех физических серверов в нашей установке Xen перезагружались (по какой-то причине). Через некоторое время мы вернулись к работе, и у нас не было много проблем (нам пришлось перезагрузить одну базу данных MySQL, которая пропустила некоторые записи во время репликации из-за сбоя).
С тех пор у нас были проблемы с памятью на этой виртуальной машине. У всех остальных виртуальных машин, которые у нас есть, не было проблем, только у этой. Использование памяти увеличивалось до 200 МБ / ч, пока коробка не закончилась. Он пережевывает своп, и убийца OOM начинает вызывать проблемы, пока мы не перезагрузим виртуальную машину.
Попробовав другие вещи (перезагрузка виртуальной машины, перезагрузка физического сервера, миграция виртуальной машины на другой физический сервер), я использовал RPM для проверки всех файлов на диске, чтобы попытаться найти повреждение. Я нашел несколько файлов в пакетах, которые я не уверен, что мы вообще использовали, поэтому я переустановил пакеты, чтобы они снова стали чистыми.
Это замедлило утечку, но она все еще существует. Сейчас утечка составляет 10-50 МБ / ч, но, похоже, она ускоряется ближе к концу. Вчера, когда сервер почти бездействовал, объем памяти увеличивался быстро, по какой-то причине увеличившись на 2,5 гигабайта менее чем за 12 часов.
Интересно, что после запуска rpm для проверки всего, но перед завершением процесса он захватил почти всю свободную физическую память, и после этого виртуальную машину пришлось перезагружать. Единственное изменение конфигурации, которое было внесено, - это увеличение памяти виртуальной машины с 2 ГБ до 4 ГБ, так что требуется больше времени, чтобы исчерпать память, и мы должны меньше перезагружать ее.
Я пробовал отслеживать память. Похоже, что мы теряем анонимные страницы, и, поскольку ящик на самом деле не использует свой диск, я не удивлен, что страницы, которые мы теряем, не поддерживаются диском. Tomcat / Java имеет 2 гигабайта виртуальной памяти и около 1 гигабайта резидентной (отведено до 1,5 гига). Как я уже сказал ранее, это конфигурация, которую он использовал в течение 6+ месяцев, и конфигурация, которую он использовал раньше, в течение многих лет до этого.
Наше программное обеспечение не обновлялось на коробке примерно за неделю до инцидента, так что это было не так. С тех пор мы его перестроили и обновили, но это не решило проблему.
Мы пробовали обновить все остальное в системе с помощью yum, но это не имело значения. Единственное программное обеспечение, установленное без yum, - это Java (которую я обновил) и наше программное обеспечение (которое я обновил).
Я написал небольшую программу для отслеживания общего виртуального размера, резидентного размера и размера сегмента данных для каждого процесса на виртуальной машине путем суммирования чисел в файловой системе / proc. После того, как он поработал в течение дня, вы могли увидеть, как виртуальный размер Apache подпрыгивает вверх и вниз с нагрузкой, но размер резидента практически не менялся. Java поднималась очень медленно, примерно до 50 МБ за весь день, и в соответствии с нашими ожиданиями. Но за это время мы потеряли 500+ МБ памяти. Top не показывает ничего, что использует больше памяти, чем Java. Моя программа обнаружила, что каждый процесс на сервере (за исключением Java и Apache) не изменился более чем на несколько килобайт за день.
По сути, что-то пожирает нашу память, но я совершенно не понимаю, что именно. Я могу предположить, что это ядро, но даже при высоком использовании памяти размер памяти ядра (список в / proc / vmstat, который я не припоминаю) составлял всего около 200 мегабайт.
На этом этапе мы готовы перестроить виртуальную машину с нуля. Думаю, это окончательный вывод.
Как отследить утечку памяти, когда происходит что-то подобное? Я никогда не видел такой утечки памяти (которая не отображается в верхней части), но мой опыт весьма ограничен. Может ли кто-нибудь предложить что-то, на что я могу взглянуть, или инструмент, который я могу использовать в подобных случаях?
Возможно ли, что виртуальная машина была взломана? Используются ли инструменты, которые вы используете для отслеживания списка процессов и памяти, с заведомо исправного носителя, доступного только для чтения? У вас может быть установлен руткит, который скрывает протекающие процессы.
У меня были проблемы с перезагрузкой xen, это было очень плохо на более поздних ядрах, и я обнаружил, что одна виртуальная машина, которую я переместил с перезагружающегося сервера на другой, тоже вызвала сбой, поэтому я понял, что это был один из гостей. Я использовал Citrix xen, который использовал ядро 2.6.18 и перестроил гостевую систему, и был как скала, но теперь перешел с Citrix на нормальное ядро xen 2.6.18 с перестроенным гостем, и все еще нормально. Позже у меня возникли проблемы с еще одним гостем xen, но он не отключил хост, но вызвал настолько серьезный сбой гостя, что я не мог войти в консоль и просто обновил все компоненты до нестабильной версии. как ни странно, теперь он действительно стабилен :)
У нас есть нечто подобное с Centos05 и таким же ядром. Оперативная память постоянно увеличивается, это необъяснимо. Мы думаем, что это может быть связано с какой-то установленной нами библиотекой / программой. У вас установлен Hdf5 и какая версия? На данный момент это наш главный подозреваемый. Openmpi / mpich2 был нашим первым подозреваемым, однако, похоже, это нормально. Хотя не уверен. Если я правильно помню, проблема также возникала с предыдущим ядром.