При выполнении двухъядерного ЦП попробуйте установку GCServer = "верный" в app/web.config.

В моем случае это делает приблизительно 10% исходного GC, и приложение чувствует себя намного более мгновенным.

Чтобы это произошел, использование памяти должно быть очень последовательным и для процесса и для системы также. Сборка "мусора" инициирована любым из этих событий:

• Бюджет поколения 0 полон
• GC.Collect () называют
• CLR хочет к свободной памяти
• Завершение работы AppDomain
• Завершение работы CLR

Вероятные кандидаты в Вашем случае являются, вероятно, регулярным набором (т.е. из-за выделения), или синхронизированное Собираются ().

Править: Просто для уточнения о выделениях. Выделение регулярных объектов всегда происходит в поколении 0 (исключением являются большие объекты 85 000 байтов или больше, которые выделяются на "куче" для больших объектов). Экземпляры только перемещены в поколение 1 и 2, когда они переживают набор. Нет никаких прямых выделений в поколении 1 и 2.

Кроме того, набор поколения 2 (также известный как полное собираются) выполняется, когда поколение 0 / 1 набор не освобождает достаточную память (или когда полное собирается, явно требуется).

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

При интенсивном создании большого количества объектов, которые должны быть живыми все одновременно, то Вы, вероятно, переполняете молодого раздела, и некоторые объекты должны быть скопированы в старшее поколение. Это вызывает полные наборы чаще, поскольку более старая "куча" заполняется. Вероятно, необходимо найти способ выделить меньше объектов в этом случае, если нет способ запросить, чтобы большей молодой "куче" понравилось существует с JVM Sun.

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

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

Я предполагаю, что Вы используете.NET также. Я не уверен, какие инструменты Вы используете, но я - огромный поклонник профилировщика Муравьев Красного Логического элемента. Я использую его на работе. Это может определить, какие объекты являются hogging ресурсами. После того как Вы сужаете его, надо надеяться, можно найти незаконный код и свободный ресурсы правильно.

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

Сообщите нам, как это идет.

Я предполагаю, что это для .NET.

GC собирается, когда он хочет базироваться на его алгоритме. Можно предложить, чтобы сборщик "мусора" собрался, но он ничего не может на самом деле сделать.

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

Примечание: Кроме того, удостоверьтесь, что Вы очищаете ссылки правильно. Значение отсоединения событий, Очищая ссылки между объектами. Это поможет GC в собранных объектах, которые больше не находятся в объеме.

Сбор 2-го поколения, происходящий как часы, предполагает, что либо метод GC.Collect вызывается как часы, либо выделение памяти похоже на часовой механизм.

Случайность, которую вы ожидаете увидеть в мусоре сбор данных вряд ли произойдет, если выделения или вызовы GC.Collect не являются действительно случайными.

Учитывая, что ваше серверное приложение находится под такой высокой нагрузкой, и вы создаете новые объекты во время обработки, я бы серьезно рассмотрел возможность рефакторинга кода, чтобы посмотрите, можно ли создать меньше новых объектов во время обработки, например, используя пулы объектов.

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

Since you are running on a Server, I am assuming it is a multicore machine as well. If this is the case, then you get Server GC flavor by default, so you don't need to set anything in your config file.

The fact that you are getting Gen2 collection every 100 second is a factor of your allocation pattern and object lifetime pattern. Если ваш шаблон распределения согласован, вы получите согласованные сборщики мусора, вы можете проверить это поведение, посмотрев в разделе Счетчики производительности памяти CLR .Net в разделе perfmon

. Вам нужно будет отслеживать следующие метрики

1. Коллекции Gen0

2. Gen 1 Коллекции

3. Коллекции 2-го поколения

4. Выделенные байты в секунду

5. Байты во всех кучах.

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

Чтобы избежать этого, вам нужно будет проверить

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

Надеюсь, это поможет. Спасибо

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

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

Я настоятельно рекомендую профилировать потребление памяти вашим приложением.

Я не понимаю, что вызывает «сбор данных второго поколения каждые 100 секунд», очень редко можно увидеть реальную систему, которая что-либо делает с таким циклом «работы часов».

Если у вас высокая нагрузка на память и используется много объектов, то да: GC будет занят ... если он попадает в поколение 2, то похоже, что у вас много средних / длинных -жизненные объекты, торчащие вокруг ... Вероятно, вы создаете больше объектов, чем может поместиться в молодой куче за раз, или у вас утечка памяти.

Если у вас нет утечки, вы проверили с помощью профилировщика памяти ? Я также предполагаю, что вы не создаете много ненужного мусора (например, string1 + = string2 внутри цикла).

Я могу придумать две вещи, которые могут помочь.

Ограничивая количество запросов (потоков), обрабатываемых Asp.net одновременно, вы можете ограничить количество живых объектов, а также ускорить обработку одного запроса, чтобы объект не оставался живым так долго. (Вы получаете много переключателей контактов потоков?)

Если вы сохраняете объект в кэше Asp.net и / или сеансе Asp.net. Вы можете попробовать использовать внепроцессное хранилище для этой информации о кэше, например, сеансовый сервер Asp.net, сторонний сеансовый сервер, memcache или недавно выпущенный кеш-сервер от Microsoft ( Velocity ). Может быть, лучше просто перечитать данные из базы данных, когда они вам понадобятся, чем хранить их в долгоживущем объекте.

В противном случае, сколько памяти вы используете? Не могли бы вы рассмотреть x64 и тонну памяти? Или веб-ферму ..

вы можете ограничить количество живых объектов, а также ускорить обработку одного запроса, чтобы не поддерживать объект в живых так долго. (Вы получаете много переключателей контактов потоков?)

Если вы сохраняете объект в кэше Asp.net и / или сеансе Asp.net. Вы можете попробовать использовать внепроцессное хранилище для этой информации о кэше, например, сеансовый сервер Asp.net, сторонний сеансовый сервер, memcache или недавно выпущенный кеш-сервер от Microsoft ( Velocity ). Может быть, лучше просто перечитать данные из базы данных, когда они вам понадобятся, чем хранить их в долгоживущем объекте.

В противном случае, сколько памяти вы используете? Не могли бы вы рассмотреть x64 и тонну памяти? Или веб-ферму ..

вы можете ограничить количество живых объектов, а также ускорить обработку одного запроса, чтобы не поддерживать объект в живых так долго. (Вы получаете много переключателей контактов потоков?)

Если вы сохраняете объект в кэше Asp.net и / или сеансе Asp.net. Вы можете попробовать использовать внепроцессное хранилище для этой информации о кэше, например, сеансовый сервер Asp.net, сторонний сеансовый сервер, memcache или недавно выпущенный кеш-сервер от Microsoft ( Velocity ). Может быть, лучше просто перечитать данные из базы данных, когда они вам понадобятся, чем хранить их в долгоживущем объекте.

В противном случае, сколько памяти вы используете? Не могли бы вы рассмотреть x64 и тонну памяти? Или веб-ферму ..

так что не поддерживать объект в живых так долго. (Вы получаете много переключателей контактов потоков?)

Если вы сохраняете объект в кэше Asp.net и / или сеансе Asp.net. Вы можете попробовать использовать внепроцессное хранилище для этой информации о кэше, например, сеансовый сервер Asp.net, сторонний сеансовый сервер, memcache или недавно выпущенный кеш-сервер от Microsoft ( Velocity ). Может быть, лучше просто перечитать данные из базы данных, когда они вам понадобятся, чем хранить их в долгоживущем объекте.

В противном случае, сколько памяти вы используете? Не могли бы вы рассмотреть x64 и тонну памяти? Или веб-ферму ..

так что не поддерживать объект в живых так долго. (Вы получаете много переключателей контактов потоков?)

Если вы сохраняете объект в кэше Asp.net и / или сеансе Asp.net. Вы можете попробовать использовать внепроцессное хранилище для этой информации о кэше, например, сеансовый сервер Asp.net, сторонний сеансовый сервер, memcache или недавно выпущенный кеш-сервер от Microsoft ( Velocity ). Может быть, лучше просто перечитать данные из базы данных, когда они вам понадобятся, чем хранить их в долгоживущем объекте.

В противном случае, сколько памяти вы используете? Не могли бы вы рассмотреть x64 и тонну памяти? Или веб-ферму ..

Вы можете попробовать использовать внепроцессное хранилище для этой информации о кэше, например, сеансовый сервер Asp.net, сторонний сеансовый сервер, memcache или недавно выпущенный кеш-сервер от Microsoft ( Velocity ). Может быть, лучше просто перечитать данные из базы данных, когда они вам понадобятся, чем хранить их в долгоживущем объекте.

В противном случае, сколько памяти вы используете? Не могли бы вы рассмотреть x64 и тонну памяти? Или веб-ферму ..

Вы можете попробовать использовать внепроцессное хранилище для этой информации о кэше, например, сеансовый сервер Asp.net, сторонний сеансовый сервер, memcache или недавно выпущенный кеш-сервер от Microsoft ( Velocity ). Может быть, лучше просто перечитать данные из базы данных, когда они вам понадобятся, чем хранить их в долгоживущем объекте.

В противном случае, сколько памяти вы используете? Не могли бы вы рассмотреть x64 и тонну памяти? Или веб-ферму ..

сколько памяти вы используете? Не могли бы вы рассмотреть x64 и тонну памяти? Или веб-ферму ..

сколько памяти вы используете? Не могли бы вы рассмотреть x64 и тонну памяти? Или веб-ферму ..

Может ли ваше приложение создавать огромный объект каждые 100 секунд, и поэтому сборщик мусора вынужден выполнять свою работу?

Я тоже видел эту 100-секундную частоту, это происходит не на всех производственных установках, но я видел это локально и на других установках.