Что может привести к линейному росту приложения в использовании оперативной памяти? - PullRequest
2 голосов
/ 31 января 2012

Положение
Я создал монстра. Applikentstein - убийца оперативной памяти, и у меня до сих пор не может быть кристально чистого понимания того, как и почему он, очевидно, так мошенничал по замыслу. По сути, это вычислительное приложение, которое запускает тестовые комбинации для N сценариев. Каждый тест проводится в отдельном выделенном потоке и включает чтение больших двоичных данных, их обработку и перенос результатов в БД. Сначала данные помещаются в буферизованные очереди во время их чтения (~ 100 МБ) и снимаются с потока в процессе обработки. Куски данных отслеживаются в массивах во время обработки. Что касается потоков, у меня есть очередь рабочих буферов с N рабочими, каждый раз, когда кто-то заканчивает работу и умирает, новая запускается через очередь.

Ниже описывается, что происходит, если я запускаю слишком много потоков («слишком много» в зависимости от системной памяти)
Проблема состоит в том, что наклон использования ОЗУ не сглаживается в какой-то момент, он просто увеличивается и снова падает, а затем время от времени падает (несколько потоков завершается, GC выполняет свою служебную работу), но как только запускаются новые потоки, он отскакивает назад, все выше и выше с течением времени (вероятно, протекает здесь)

enter image description here

Со временем я задал этот вопрос, , что один, и этот другой. Сейчас время, когда я чувствую, чем больше я узнаю об этом, тем меньше я ДЕЙСТВИТЕЛЬНО понимаю. (Вздох)

Вопросы
Теперь я хотел бы получить четкие объяснения / ресурсы о том, как точно управляет памятью в .Net.
Я знаю, что есть много литературы / статей в блогах на эту широкую тему. Но тема настолько велика, что я действительно не знаю, с чего начать, не теряя себя (и драгоценного времени моей компании). Я хочу сохранять целенаправленность и объективность.

Второй , «Наклон» возник, когда я попытался смоделировать / воспроизвести крутой склон выше (созданный «естественным образом» монстром RAM'osaurus) в лабораторных условиях, чтобы изолировать это поведение и найти лекарство от него (т. е. контролировать память, используемую процессом, и ограничить ее до X% от общей памяти, остановив создание любого нового потока).
Почему было так трудно воспроизвести в лабораторных условиях (с некоторым многопоточным циклом, потребляющим память) то, что моя мошенническая программа, кажется, все-таки делает так легко (опуская ОЗУ на колени в диспетчере задач)? Казалось, что GC регулярно очищает вещи в прототипе, в то время как мое приложение, похоже, хранит много ссылок в RAM. Как так ?

A Третье о том, как работает кэширование: почему Firefox использует до 1 Гб памяти и использует кеш, а мое приложение просто уносит ОЗУ? Возможно ли, что данные интенсивно / часто используются запущенными потоками, чтобы они никогда не кэшировались?

Гусеницы и отведения
Я уже использовал профилировщик VS и определил несколько узких мест (сортировка больших массивов), использовал GCRoot и консоль WinDBG. Каждый раз, когда я обнаруживал дальнейшие утечки и исправлял некоторые из них (более или менее, например, отсутствие подписок на события и т. Д.)

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

1 Ответ

2 голосов
/ 31 января 2012

Не столько ответ, сколько наблюдение:

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

В первую очередь, они будут отслеживать каждую утечку памяти.Который, вы начали, но я предлагаю вам просто продолжать идти.

Одна заметка, касающаяся Firefox и «кеша».Вы говорите о файле подкачки Windows;Windows контролирует это.Он имеет свои собственные правила в отношении того, когда данные выгружаются на диск, чтобы освободить оперативную память.Я полагаю, что это красная сельдь, и вы не хотите идти по этому пути.Одна из причин, по которой данные переносятся на диск - это отсутствие использования.С Firefox и другими приложениями это довольно часто;из вашего описания ваше программное обеспечение не ведет себя так.

Я бы посмотрел на то, насколько напряжены ваши циклы, и дали ли вы даже .NET-среде возможность выполнить очистку.Похоже, что это вызывает проблему при использовании, так что это, вероятно, нормально.

В любом случае, я не совсем понимаю, в чем проблема.Вы упоминаете, что график является результатом запуска слишком большого количества потоков. Хорошо, это ожидаемо.Каждый поток, который вы запускаете, будет использовать ресурсы;запуск большого количества из них по своей природе потребует большого количества ресурсов ... В какой-то момент система не сможет запустить больше, и это приведет к сбою.

Некоторые проблемы, влияющие на вашу лабораторию по сравнению с производственными системами: разные уровни исправлений windows / .net / etc, разные операционные системы (например, 2008 vs 2008 R2 сильно отличается), разные конфигурации ЦП и / или памяти.С тем, что вы дали, на самом деле ничего не сказано.

Чтобы воспроизвести событие, вам необходимо иметь точно соответствующее оборудование и программное обеспечение.Тогда вам понадобятся идентичные входные данные.Если какой-либо из них выключен, вы могли бы быть в состоянии приблизиться.Первое, что нужно сделать, это убедиться, что все загруженные и входные данные идентичны.Это легко контролировать.Затем начните играть.


Небольшое обновление.Я прочитал некоторые из перечисленных вами вопросов.

Чтобы определить оптимальное количество потоков для вашей системы, вы должны выполнить профили на целевом аппаратном / программном обеспечении.Желательно на самой системе.Это займет значительное количество руки, чтобы добраться до этой точки.Единственный способ автоматизировать это - иметь сторожевой таймер, который проверяет, как все работает, и увеличивает потоки или уменьшает их в зависимости от частоты отказов.Примерно так, как некоторые компьютеры-энтузиасты теперь могут автоматически разгоняться: продолжайте нагревать, пока все не растает;затем отключите 1 бит.

Конечно, вы все равно можете столкнуться с проблемами, если какой-то процент потоков выйдет за пределы того, что вы обычно разрешаете, ИЛИ, если какой-либо другой программный продукт запускается и забирает ресурсы.


tldr ;Вы должны вручную настроить это на машине, на которой это будет жить.Будьте готовы к частой перестройке.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...