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

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

Если вызывать через определённый интервал GC.Collect, время сборки мусора уменьшится и реакция будет обеспечена.

Максимальная продолжительность паузы зависит от количества живых объектов в последнем поколении (их надо все обойти) и занимаемого ими объёма памяти (если делать дефрагментацию), но не зависит от количества умерших объектов. Если вручную вызывать System.GC.Collect(), то мусора станет меньше, но количество живых объектов не изменится, а значит не изменится и продолжительность паузы.

[Peter Almazov]

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

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

В принципе ещё есть запас по рефакторингу

Сейчас обдумываю как для перманентного текста (телефонный номер, логин и прочие вечные текстовые идентификаторы) уйти от использования System.String. Так можно дёшево и сердито избавиться от большого количества объектов.

[valexey]

Между прочим, вот поэтому для, систем массового обслуживания, в том числе и class 5, принято таки использовать erlang.

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

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

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

PS. А вообще, для хренения таких вот больших объемов данных (особенно вечных) обычно используют какую-нибудь no-sql базу данных. В простейшем случае мнезию (mnesia) (для ерланга).

[alexus]

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

Кто бы мне пояснил... в чём радость от использования сборщиков мусора?..
К примеру, научили школяра/студента писать на oberon, где встроенный сборщик мусора. Устроился этот бывший школяр на работу программистом, а там на C++ пишут или на Delphi... И начались проблемы с протечками. Не лучше ли прививать культуру работы с памятью. Нет же в этом ничего заумного и трудного. Меня не напрягает для программ, где используется много объектов, расписывать карту памяти... это позволяет заблаговременно понять, что же и как, собственно, делается в программе... увидеть узкие места. Такие задачи никакой сборщик мусора за программиста не решит.
Другими словами, наличие сборщика мусора в среде разработки/языке я бы скорее оценил отрицательно... не говоря уже о тех проблемах (тормоза), которые поднял Сергей.

[valexey]

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

Кто бы мне пояснил... в чём радость от использования сборщиков мусора?..

Предлагаю про то, зачем же сборщик мусора вообще существует, продолжить тут: http://oberspace.dyndns.org/index.php/topic,175.0.html

[Geniepro]

Кто бы мне пояснил... в чём радость от использования сборщиков мусора?..
К примеру, научили школяра/студента писать на oberon, где встроенный сборщик мусора. Устроился этот бывший школяр на работу программистом, а там на C++ пишут или на Delphi... И начались проблемы с протечками. Не лучше ли прививать культуру работы с памятью. Нет же в этом ничего заумного и трудного. Меня не напрягает для программ, где используется много объектов, расписывать карту памяти... это позволяет заблаговременно понять, что же и как, собственно, делается в программе... увидеть узкие места. Такие задачи никакой сборщик мусора за программиста не решит.
Другими словами, наличие сборщика мусора в среде разработки/языке я бы скорее оценил отрицательно... не говоря уже о тех проблемах (тормоза), которые поднял Сергей.

Для большинства задач сборщик мусора просто упрощает жизнь -- меньше головной боли, больше времени думать о задаче.
Вы ведь наверняка не расписываете цикл WHILE через машинные команды jmp и прочих branch. Используете привычную синтаксическую конструкцию, сахар.
Так и сборщик мусора тоже сахар, правда не синтаксический...

Ну, а такие экстремальные ситуации, как у Сергея, требуют нестандартных подходов...

[alexus]

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

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

Вы ведь наверняка не расписываете цикл WHILE через машинные команды jmp и прочих branch. Используете привычную синтаксическую конструкцию, сахар.

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

Ну, а такие экстремальные ситуации, как у Сергея, требуют нестандартных подходов...

Не такие уж это экстремальные ситуации... Когда программа анализирует производство, то имеем "матрицу" N * M (где M - количество операций, а M - количество партий). Для среднего по объёмам заказного производства имеем ту же, что и у Сергея, размерность. И число таких задач довольно велико, хотя они ещё далеки от того, чтобы стать массовыми.

[Peter Almazov]

Когда программа анализирует производство, то имеем "матрицу" N * M (где M - количество операций, а M - количество партий). Для среднего по объёмам заказного производства имеем ту же, что и у Сергея, размерность. И число таких задач довольно велико, хотя они ещё далеки от того, чтобы стать массовыми.

И что, программа не может подождать 10 сек?

[alexus]

Когда программа анализирует производство, то имеем "матрицу" N * M (где M - количество операций, а M - количество партий). Для среднего по объёмам заказного производства имеем ту же, что и у Сергея, размерность. И число таких задач довольно велико, хотя они ещё далеки от того, чтобы стать массовыми.

И что, программа не может подождать 10 сек?

А программа не ждёт... Ждут пользователи... результатов работы программы. У нас нет жёстких требований по времени, это не системы реального времени, ни системы массового обслуживания. Но по объёму данных примерный паритет с теми задачами, о которых говорил Сергей.

[Geniepro]

Вы ведь наверняка не расписываете цикл WHILE через машинные команды jmp и прочих branch. Используете привычную синтаксическую конструкцию, сахар.

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

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

Я в курсе, что у Вас была статья про ООП на ассемблере лет этак 20 назад, когда я ещё в школу ходил,
но почему-то думал, что Вы уже на дельфы перешли... ))

Ну, а такие экстремальные ситуации, как у Сергея, требуют нестандартных подходов...

Не такие уж это экстремальные ситуации... Когда программа анализирует производство, то имеем "матрицу" N * M (где M - количество операций, а M - количество партий). Для среднего по объёмам заказного производства имеем ту же, что и у Сергея, размерность. И число таких задач довольно велико, хотя они ещё далеки от того, чтобы стать массовыми.

Ну у Вас же там в этих экономических задачах разные методы оптимизации есть, так и тут тоже надо оптимизировать...

[Peter Almazov]

А программа не ждёт... Ждут пользователи... результатов работы программы. У нас нет жёстких требований по времени, это не системы реального времени, ни системы массового обслуживания. Но по объёму данных примерный паритет с теми задачами, о которых говорил Сергей.

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

[valexey]

А вот как решают эту проблему в Обероне (точнее, видимо, в Компонентном паскале):

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

Это возможно только при условии, что все компоненты не порождают при своей работе мусор.
"Идиллию" может обломать вот этот безобидный NEW, где-нибудь вызываемый раз в минуту, в модуле уважаемого Ивана Кузьмицкого, который он любезно опубликовал, а я, не проверив, использовал в своём нагруженном приложении

Это я не к тому, что Вы должны думать о высоконагруженной сфере.
Это я к тому, что применительно к выделению памяти тезис "сначала можно вообще не думать, потом померять - и оптимизировать" не совсем верен.
Потому что тут критерий качественный - не "сколько процентов даст этот NEW", а "переведёт ли этот NEW мою систему из класса способных работать без сборки мусора в класс обычных".

Если что, оригинал тут: http://forum.oberoncore.ru/viewtopic.php?p=70517#p70517

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

[trurl]

К примеру, научили школяра/студента писать на oberon, где встроенный сборщик мусора. Устроился этот бывший школяр на работу программистом, а там на C++ пишут или на Delphi... И начались проблемы с протечками.

Вероятность устоиться на работу, где пишут на C# или Java гораздо выше. 

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

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

Не только в реалтайме если речь о Блэкбоксе. В Блэкбоксе сборщик мусора не ранжирует объекты по поколениям, поэтому при большом количестве объектов он тормозит постоянно. Когда я сравнивал Блэкбокс с дотнетом, то обнаружил следующее. Допустим есть 5 миллионов фоновых объектов и 1000 объектов то и дело создаваемых и выбрасываемых в мусор. Дотнетная программа переместит 5М фоновых объектов в третье поколение и будет летать со скоростью света. А Блэкбокс вообще встанет колом, так как будет оббегать все 5'001'000 объектов каждый раз.

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