Паузы в работе программы вызываемые GC

[Губанов Сергей Юрьевич]

Во время сборки мусора работа программы останавливается. Длительность паузы зависит от количества объектов и от объёма занимаемой памяти. Я измерил эту зависимость и построил графики, они там: Паузы в работе программы вызываемые сборщиком мусора .Net 3.5 Длительность паузы может достигать 20 секунд если программой занято 8 Гб памяти и использовано более 100 миллионов объектов.

Можно обсудить границу применимости программ со сборщиком мусора в области мягкого реального времени. Например, мне на работе нужно чтобы время реакции программы не превышало 5 секунд. Мы пишем логику управления телефонной станцией. Пока программа занимает 1-2 гигабайта памяти (100'000 телефонов) -- всё нормально, а вот что делать если хочется 1'000'000 телефонов (> 5 гигабайтов) -- не очень понятно. В принципе ещё есть запас по рефакторингу, но он не бесконечный и рано или поздно мы всё таки упрёмся в непрошибаемую стену "мусорной паузы". Как её прошибать?

[Peter Almazov]

Я так понимаю, что 100 миллионов объектов - это НЕ мусорные объекты?

[DIzer]

В принципе ещё есть запас по рефакторингу, но он не бесконечный и рано или поздно мы всё таки упрёмся в непрошибаемую стену "мусорной паузы". Как её прошибать?

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

[Губанов Сергей Юрьевич]

Я так понимаю, что 100 миллионов объектов - это НЕ мусорные объекты?

Да, это живые объекты.

Кстати, мусора у меня не очень много поскольку практически все объекты после "смерти" кэшируются для повторного использования (не кэширую объекты string и редко используемые). Но как бы ни было мало мусора, рано или поздно сборщик мусора всё равно полезет в третье поколение и вызовет паузу в работе программы.

провоцировать стандартный мусоросборник на уборку

А что это даёт? Возможно это как-то отсрочивает сборку в третьем поколении, но не ликвидирует же её вовсе. Хочется чтобы программа вообще-вообще-совсем-никогда не "подвисала" более чем на 5 секунд (даже ценой некоторой потери производительности).

[DIzer]

А что это даёт? Возможно это как-то отсрочивает сборку в третьем поколении, но не ликвидирует же её вовсе. Хочется чтобы программа вообще-вообще-совсем-никогда не "подвисала" более чем на 5 секунд (даже ценой некоторой потери производительности).

Это  и дает - сервис ДОЛЖЕН обеспечивать это свойство (период работы вашей системы с задержками не более 5 секунд).

[Губанов Сергей Юрьевич]

сервис ДОЛЖЕН обеспечивать это свойство

Я не понимаю. Как?

[DIzer]

сервис ДОЛЖЕН обеспечивать это свойство

Я не понимаю. Как?

Дробя все время штатной работы вашей системы на участки , перерыв  между которыми составляет не более 5 секунд (время работы мусорозборника).

[Peter Almazov]

Да ничего это не даст, ему же все равно потребуется пройтись по 100 000 000 объектов. А дробить-то просто - вызывай GC.Collect() хоть каждую секунду.

[Geniepro]

В таких задачах надо что-то типа такого использовать:
www.usenix.org/event/vm04/wips/goh.pdf
"A Real-Time Garbage Collector for Embedded Applications in CLI"

http://research.microsoft.com/apps/video/dl.aspx?id=103698

[DIzer]

Да ничего это не даст, ему же все равно потребуется пройтись по 100 000 000 объектов. А дробить-то просто - вызывай GC.Collect() хоть каждую секунду.

Это если она одна , а если их будет 10 (и в каждой по 100000) обьектов?

[vlad]

Можно обсудить границу применимости программ со сборщиком мусора в области мягкого реального времени. Например, мне на работе нужно чтобы время реакции программы не превышало 5 секунд. Мы пишем логику управления телефонной станцией. Пока программа занимает 1-2 гигабайта памяти (100'000 телефонов) -- всё нормально, а вот что делать если хочется 1'000'000 телефонов (> 5 гигабайтов) -- не очень понятно. В принципе ещё есть запас по рефакторингу, но он не бесконечный и рано или поздно мы всё таки упрёмся в непрошибаемую стену "мусорной паузы". Как её прошибать?

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

[Губанов Сергей Юрьевич]

Разделение на несколько процессов (каждый < 2 Гб) конечно решило бы проблему пауз GC, но это очень неудобно по бизнес логике. Удобно использовать одну структуру данных (на несколько гигабайтов).

[vlad]

Разделение на несколько процессов (каждый < 2 Гб) конечно решило бы проблему пауз GC, но это очень неудобно по бизнес логике. Удобно использовать одну структуру данных (на несколько гигабайтов).

Ну вот так иногда бывает, что особенности платформы оказывают влияние на архитектуру и прочую бизнес логику

[Peter Almazov]

Проблема-то общая для всех языков со сборкой мусора.

[Berserker]

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