Подтвердить что ты не робот

Можете ли вы воспроизвести эту 64-битную ошибку .NET 4 GC?

Обновление: Microsoft теперь воспроизвела ошибку и работает над исправлением.

Оценивая жизнеспособность платформы .NET для разработки программного обеспечения с малой задержкой, мы обнаружили серьезную ошибку в сборщике мусора .NET 4, который может зависеть от приложений в течение нескольких минут за раз.

На трех наших машинах следующая простая программа С# заставляет GC течь память до тех пор, пока не останется, и один малый цикл GC начнет работать, задерживая программу в течение нескольких минут (!), в то время как 11Gb кучи перерабатывается:

    static void Main(string[] args)
    {
        var q = new System.Collections.Generic.Queue<System.Object>();
        while (true)
        {
            q.Enqueue(0);
            if (q.Count > 1000000)
                q.Dequeue();
        }
    }

Вам нужно скомпилировать для x64 в 64-разрядной ОС Windows с .NET 4 и запустить с GC (по умолчанию) (с одновременной рабочей станцией), используя настройку по умолчанию (интерактивная).

Вот как выглядит диспетчер задач при запуске этой программы на этом компьютере:

alt text

Обратите внимание, что здесь утечка 11 Гб кучи, когда для этой программы требуется не более 100 Мб памяти.

Теперь мы собрали около десятка рецензий этой ошибки, написанных на F #, а также на С#, и, похоже, она связана с ошибкой в ​​барьете записи GC, когда большинство из gen0 выживает. Однако Microsoft пока не смогла воспроизвести его. Ты можешь? Если да, можете ли вы описать свою установку как можно точнее, поэтому мы можем попытаться сузить точно, какие условия необходимы для проявления этой ошибки.

4b9b3361

Ответ 1

Запуск кода в linqpad действительно приводит к огромному потреблению памяти при работе в 64-разрядной версии; работающий как 32-разрядный, отлично работает.

У меня есть окончательная установка Windows 7 x64 (исправлена ​​как обычно) с 8 ГБ основной памяти; VS.NET и другие инструменты разработчика установлены так, что могут быть какие-то странные отладчики-крючки, которые отсутствуют на пустой машине.

Странно, что они не перепрограммировали его. Вы уверены, что там нет какой-либо связи?

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

Ответ 2

Я не мог воспроизвести его. Я попробовал его на x64 с 4 гигабайтами ram & составлен как ЛЮБОЙ. Максимальное использование памяти было около 2,5 гигабайт. Максимальное время паузы GC составляло 1084 мс.

Вот результат моей статистики GC ETW. alt text

Вы также можете получить GC Events по времени alt text

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

В .NET 4.0 есть трассировка событий для Windows (ETW), которая предоставляет информацию отслеживания Framework. Вот один из них, относящийся к GC.

И для получения этой информации есть инструмент, который называется PerfView

Ниже приведены шаги по использованию инструмента для получения информации GC

  • Запустите cmd.exe в качестве администратора, это необходимо для сбора трассировки ETW.
  • Запустите приложение, которое вы хотите отслеживать.
  • Выполните команду "PerfMonitor.exe/process: 4180 start", где 4180 - это идентификатор процесса
  • Пусть приложение работает некоторое время
  • Затем выведите "PerfMonitor.exe stop"
  • Команда для получения отчета "PerfMonitor.exe GCTime". Это создаст отчет и откроет его в браузере с помощью статистики GC.

Ответ 3

Я написал об этом здесь и еще шесть человек, помимо меня и Eamon, подтвердили, что они также могут воспроизвести эту ошибку.

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