Я пытаюсь определить, является ли то, что я вижу, утечка памяти в моем встроенном приложении Debian Wheezy Mono-Sgen 2.10.8.1-8. Система имеет 512 МБ ОЗУ. Swap отключен. Я изучаю, чтобы попытаться понять, как Linux управляет памятью процесса, чтобы заключить, что то, что я вижу, на самом деле является утечкой памяти где-то в Моно-Сгене. Я уверен, что это не мое приложение, так как я профилировал его много раз после недель постоянного времени работы, и память GC всегда возвращается к базовой линии приложения. Никакие объекты не протекают с точки зрения моего приложения. Это не означает, что внутри Mono-Sgen не протекает, но я не определил это, и это может быть не так.Является ли это утечкой памяти в приложении Linux Mono?
Я попытался ограничить свою кучу Моно-Сгенера, поскольку по умолчанию моно для большой кучи составляет 512 МБ, и поскольку это все, что у меня есть в моей системе, я предположил, что мне нужно закрыть ее, чтобы предотвратить OOM от Linux. Моя конфигурация для Mono-Sgen ниже:
экспорта MONO_GC_PARAMS = главный = marksweep фиксированных, мейджор-кучного размер = 32m, детского размера = 4й, эвакуация порог = 75
Из моего понимания я нахожусь используя фиксированную крупную кучу с отметкой и разверткой с фиксированным размером 32 МБ, размер ящика по умолчанию размером 4 МБ и Mono-Sgen будет выполнять копировальную коллекцию на большой куче, если какой-либо из крупных кладок распределения кучи упадет ниже 75%, используемого для предотвращения фрагментации , Я столкнулся с дефолтом на 66%.
Мое устройство в настоящее время работает на протяжении более 6 дней с момента отключения питания, вызванного сбросом. Когда мое приложение сначала запускается, я жду около 10 минут, чтобы убедиться, что он полностью инициализирован, затем я сделаю мгновенный снимок файла/proc/PID/status, чтобы получить базовый уровень его использования в памяти. Сегодня я взял еще один магазин, чтобы увидеть, где я, и, как всегда, мой виртуальный резидент и данные для этого примера процесса Mono-Sgen снова выросли. Он еще не пробил отметки о высокой воде, которые произошли во время инициализации, но в прошлый раз я сделал это испытание. То, что я не смог сделать, и которое я пытаюсь сделать, - это позволить ему работать до такой степени, что он исчерпывает всю физическую память системы. Мне нужно знать, действительно ли это утечка памяти или если в какой-то момент Linux собирается вернуть некоторые из страниц, которые мой процесс выделил.
Одна вещь, которую я заметил, что даже знаю, что у меня нет свопа, размер резидентного моего Моно-Сгенского процесса всегда примерно на 30 МБ меньше, чем количество данных. Из того, что я понимаю, количество данных - это количество распределения кучи, размер резидента - это то, что на самом деле находится в физической памяти, виртуальный - это то, что было выделено, не обязательно используется.
Мое предположение заключается в том, что Linux просто является Linux и не тратит время или память, если это не нужно. Я предполагаю, что, поскольку система очень легко загружена, у Linux есть 0 памяти, чтобы сделать что-либо, чтобы восстановить память, и просто чтобы Mono-Sgen продолжал выделять и увеличивать кучу, и я надеюсь, что когда есть какое-то фактическое давление памяти, Linux идет для входа и возврата страниц, которые на самом деле не используются.
Я читал, что Linux не будет сокращать выделенный объем памяти процесса, когда на вызов вызывается свободная выделенная память. Я не понимаю, почему, если Linux не является Linux, он будет делать это только тогда, когда это необходимо. Но мой страх - это то, как долго мне нужно ждать, пока это не произойдет.
Является ли это утечкой памяти или Linux восстановит разницу между страницами между резидентным и размером данных этого процесса, когда давление в памяти начнет накачиваться? Я искал и читал все, что мог рассказать о предмете, и я не нахожу ответ, который я ищу, и действительно не хочу ждать месяц, чтобы узнать, сможет ли мое приложение отскочить из-за убийцы OOM. Я все равно :) Но я хотел бы знать это раньше.
Я изучил потенциальные утечки памяти с помощью Mono-Sgen 2.10.8.1-8, но для того, что я делаю (используя множество вызовов process.start() для родных Linux-приложений), большинство типов ошибок, которые могут причинить мне вред, в этом выпуске не указаны. Я попытался обновить версию Mono-Sgen Джесси (3.2.8, я думаю), но она рушилась на моей системе, поэтому я вернулся к стабильной версии Mono-Sgen 2.10.8.1-8 из более неизвестного страха.
Прилагаются многочисленные снимки стандартной информации о памяти, при этом основное внимание уделяется тому, что возвращается/proc/PID/status.
Любая информация будет оценена как всегда, и я надеюсь, что я просто не понимаю, как Linux восстанавливает память на слегка загруженной системе.
запустить его с Valgrind. Вы не разместили ничего, как достаточно информации для нас. –
Спасибо, я попробую, я не был уверен, что он доступен для армеля. – CCS