Является ли GCLatencyMode.LowLatency хорошим выбором? - PullRequest
4 голосов
/ 16 июля 2009

У меня есть служба Windows C #, выступающая в роли сервера, служба хранит некоторые большие (> 8 ГБ) структуры данных в памяти и предоставляет клиентам методы поиска через удаленное взаимодействие.

Операция поиска в среднем выполняется <200 мс, и служба обрабатывает до 20 запросов / сек. </p>

Я замечаю некоторое серьезное снижение производительности (> 6000 мс) на регулярной основе в течение нескольких секунд

Мое лучшее предположение - то, что потоки сервера время от времени останавливаются сборкой мусора gen2.

Я подумываю о переходе с gc сервера на gc рабочей станции и включу в него свой метод поиска, чтобы предотвратить сборку GC во время запросов.

 static protected void DoLowLatencyAction(Action action)
    {
        GCLatencyMode oldMode = GCSettings.LatencyMode;
        try
        {
            GCSettings.LatencyMode = GCLatencyMode.LowLatency;
            // perform time-sensitive actions here
            action();
        }
        finally
        {
            GCSettings.LatencyMode = oldMode;
        }
    }

Это хорошая идея?

При каких условиях GC все равно будет выполняться внутри блока с низкой задержкой?

Примечание: я работаю на сервере x64 с 8 ядрами

Спасибо

Ответы [ 3 ]

9 голосов
/ 16 июля 2009

Раньше я не использовал GCLatencyMode, поэтому не могу прокомментировать, является ли его использование хорошей идеей или нет.

Однако, вы уверены , что используете GC-сервер? По умолчанию службы Windows используют рабочую станцию ​​GC.

У меня раньше была похожая проблема в службе Windows, и я настроил режим GC на сервере:

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

в файле сервиса app.config решил это.

Прочитайте этот пост из блога Тесс Феррандез для получения более подробной информации.

1 голос
/ 18 июля 2009

Я удивлен, что ваш метод поиска даже запускает сборщик мусора, если структура данных 8 ГБ является статической (не сильно изменяемой при добавлении или удалении из нее), и все, что вы делаете, - это поиск, тогда вам следует просто попытаться избежать выделения временные объекты в вашем методе поиска (если вы можете). Создание объектов - это то, что вызывает GC, и если у вас есть структура данных, которая редко модифицируется, то имеет смысл избегать GC все вместе (или задерживать это как можно больше).

GCSettings.LowLatency делает то, что он дает подсказку GC делать активные коллекции таким образом, чтобы мы могли избегать коллекций Gen2, пока установлен режим LowLatency. В качестве побочного эффекта это приводит к тому, что GC стремится собирать данные за пределами региона, в котором установлен режим LowLatency, и может привести к снижению производительности (в этом случае вы можете попробовать режим GC на сервере).

0 голосов
/ 24 сентября 2015

Это не похоже на отличную идею. В какой-то момент GC проигнорирует вашу подсказку и все равно выполнит сбор.

Я полагаю, что вы добьетесь гораздо большего успеха, если будете на самом деле профилировать и оптимизировать свой сервис. Запустите PerfView (бесплатный, замечательный инструмент Microsoft) на вашем сервере, пока он работает. Посмотрите, кому принадлежат проблемные объекты и сколько времени занимают определенные длительные события GC.

...