Достижение лимита памяти замедляет приложение .Net

Question

У нас есть 64-битное приложение C # /. Net3.0, которое работает на 64-битном сервере Windows. Время от времени приложение может использовать большой объем доступной памяти. В некоторых случаях приложение перестает выделять дополнительную память и значительно замедляется (в 500+ раз медленнее). Когда я проверяю память в диспетчере задач, объем используемой памяти почти не изменяется. Приложение продолжает работать очень медленно и никогда не выдает исключение нехватки памяти. Есть идеи? Дайте мне знать, если нужно больше данных.

Answer 1

Вы можете попробовать включить режим сервера для сборщика мусора . По умолчанию все .NET-приложения работают в режиме рабочей станции, где GC пытается выполнить свою работу, сохраняя приложение работающим. Если вы включаете режим сервера, приложение временно останавливает приложение, чтобы освободить память (намного) быстрее, а также использует разные кучи для каждого процессора / ядра.

Большинство серверных приложений увидят улучшение производительности при использовании режима GC-сервера, особенно если они выделяют много памяти. Недостатком является то, что ваше приложение будет в основном зависать, когда оно начинает исчерпывать память (пока не закончится сборщик мусора).

^* Чтобы включить этот режим, введите в свой app.config или web.config следующее:

<configuration>
   <runtime>
      <gcServer enabled="true"/>
   </runtime>
</configuration>

Answer 2

В тот момент, когда вы достигнете предела физической памяти, ОС начнет пейджинг (то есть запись памяти на диск). Это действительно приведет к замедлению, которое вы видите.

Решения?

• Добавление дополнительной памяти - это поможет, пока вы не достигнете нового предела памяти
• Перепишите ваше приложение, чтобы использовать меньше памяти
• Выясните, есть ли у вас утечка памяти, и исправьте ее

Если проблема не в памяти, возможно, ваше приложение сильно загружает процессор? Видите ли вы процессор близко к 100%? Если это так, проверьте наличие больших коллекций, которые повторяются снова и снова.

Answer 3

В других ответах упоминается очень много хороших вещей. Тем не менее, я все равно собираюсь скинуть свои два пенса (или цента - в зависимости от того, откуда вы!).

Предполагая, что это действительно 64-битный процесс, как вы сказали, вот несколько направлений исследования ...

Какое использование памяти вы проверяете? Использование Mem или размер VMem? Размер VMem - это тот, который действительно имеет значение, так как он относится как к выгружаемой, так и к невыгружаемой памяти. Если два числа далеко не в порядке, то использование памяти действительно является причиной замедления.

Каково реальное использование памяти на всем сервере, когда все начинает замедляться? Относится ли замедление к другим приложениям? Если это так, то у вас может быть проблема с памятью ядра, которая может быть связана с огромным объемом доступа к диску и низкоуровневым использованием ресурсов (например, создать 20000 мьютексов или загрузить несколько тысяч битовых карт с помощью кода, использующего Win32 HBitmaps). Вы можете получить некоторую информацию об этом в диспетчере задач (хотя версия Windows 2003 более информативна, чем версия 2008).

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

Какова нагрузка на процессор приложения, когда оно работает на полную мощность? Это на самом деле так же, как когда происходит замедление? Если загрузка ЦП уменьшается по мере увеличения использования памяти, это означает, что для того, что он делает, требуется больше времени для загрузки ОС, а это, вероятно, создает слишком большую нагрузку на ОС. Если нет разницы в загрузке процессора, то я предполагаю, что внутренние структуры данных становятся настолько большими, что замедляют ваши алгоритмы.

Я бы, конечно, посмотрел на запуск Perfmon в приложении - начиная с некоторых .Net и собственных счетчиков памяти, попаданий и промахов кэша и длины очереди диска. Запускайте его на протяжении всего приложения от запуска до запуска, когда оно начинает работать как астматическая черепаха, и вы можете просто получить подсказку от этого.

Answer 4

Как и в 32-битных операционных системах Windows, существует ограничение в 2 ГБ на размер объекта, который вы можете создать при запуске 64-битного управляемого приложения в 64-битной операционной системе Windows. 1003 *

Исследование проблем с памятью (статья MSDN)

Answer 5

Пролистав остальные ответы, я бы сказал, что есть много хороших идей. Вот тот, который я не видел:

Получить профилировщик памяти, такой как SciTech's MemProfiler. Он скажет вам, что распределяется, чем, и покажет вам весь срез и кости.

Он также имеет видеоуроки на случай, если вы не знаете, как его использовать. В моем случае я обнаружил, что у меня есть IDisposable экземпляры, которые я не использовал (...)