Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали: S>>А так основные сценарии это когда начинается critical path в коде, или чувствительный к latency код, когда прерывания нашего кода крайне нежелательно (stop the world), перед этими участками кода и делают gc. У Клеппмана очень круто про это написано буквально на пару страниц. S>А можно ссылочку на Клеппмана?
У меня англ. издание, глава 8, раздел Process Pauses, стр. 295 — 299. Там вперемешку со всяким прочим. Скорее пару абзацев,
а не пару страниц. На худой край -- страница.
Здравствуйте, Sharov, Вы писали:
Ага, нашёл.
Я просто удивился — как так, Клеппман мало того, что в распределёнке шарит, так ещё и C#-гуру! S>У меня англ. издание, глава 8, раздел Process Pauses, стр. 295 — 299. Там вперемешку со всяким прочим. Скорее пару абзацев, S>а не пару страниц. На худой край -- страница.
Ну, если честно, у Клеппмана написано не просто "делайте GC перед критичным участком" — там написано
An emerging idea is to treat GC pauses like brief planned outages of a node, and to let other nodes handle requests from clients while one node is collecting its garbage.
If the runtime can warn the application that a node soon requires a GC pause, the application can stop sending new requests to that node, wait for it to finish processing outstanding requests, and then perform the GC while no requests are in progress.
This trick hides GC pauses from clients and reduces the high percentiles of response time [70, 71]. Some latency-sensitive financial trading systems [72] use this approach.
То есть надо сначала всем сказать "падажжы", потом дождаться окончания реквестов, и только потом делать GC. А потом рапортовать "я всё, засылайте запросы".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали: S>Ага, нашёл. S>Я просто удивился — как так, Клеппман мало того, что в распределёнке шарит, так ещё и C#-гуру!
Скорее ява.
S>>У меня англ. издание, глава 8, раздел Process Pauses, стр. 295 — 299. Там вперемешку со всяким прочим. Скорее пару абзацев, S>>а не пару страниц. На худой край -- страница. S>Ну, если честно, у Клеппмана написано не просто "делайте GC перед критичным участком" — там написано
Я не очень точно выразился, видимо, ибо написал это не в контексте Клепмана. Сам я это вычитал где-то еще (скорее всего хабр),
просто у Клепмана описаны возможные косяки с gc в распределенных приложениях. Плюс он дает рекомендации по паттернам
выделения памяти и gc -- создавать short-lived objects и чаще дергать gc, задержки будут меньше. Либо как процитировано ниже
-- в полный уход, по типу падения.
S>
S>An emerging idea is to treat GC pauses like brief planned outages of a node, and to let other nodes handle requests from clients while one node is collecting its garbage.
S>If the runtime can warn the application that a node soon requires a GC pause, the application can stop sending new requests to that node, wait for it to finish processing outstanding requests, and then perform the GC while no requests are in progress.
S>This trick hides GC pauses from clients and reduces the high percentiles of response time [70, 71]. Some latency-sensitive financial trading systems [72] use this approach.
S>То есть надо сначала всем сказать "падажжы", потом дождаться окончания реквестов, и только потом делать GC. А потом рапортовать "я всё, засылайте запросы".
Суть не столько вмешиваться, сколько понимать какого влияние сборки мусора на ваш код и влияние вашего кода на сборку мусора.
Для примера Task и ValueTask. Не нужно использовать классы, там где проще обойтись структурой.
Яркий пример Падение производительности при повторной сортировке массива объектов
Суть была в том, что элементы старших поколений в том алгоритме сборки мусора считались неизменяемыми (не учавствуют в сборке мусора ) и при изменении ссылок на объекты велся отдельный подсчет (изменения в их ссылках нужно регистрировать.).
Со временем алгоритмы меняются
Большинство изменений в .Net идет к уменьшению копирования и преобразований. Благодаря ref struct появились не только Span<T> , но и ReadOnlySpan, Utf8JsonReader итд
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Glas, Вы писали:
G>Всем привет.
G>Недавно проходил несколько собеседований на .NET и частенько спрашивают про работу GC. G>Стало интересно, как часто вы вмешиваетесь в его работу и по каким причинам?
Все highload проекты(эдак десятки, если не сотни тысяч RPS), реализуемые на .NET Core-требуют глубокого понимания механизмов работы GC и умения этим пользоваться.
Здравствуйте, HFTMan, Вы писали:
HFT>Здравствуйте, Glas, Вы писали:
G>>Всем привет.
G>>Недавно проходил несколько собеседований на .NET и частенько спрашивают про работу GC. G>>Стало интересно, как часто вы вмешиваетесь в его работу и по каким причинам? HFT>Все highload проекты(эдак десятки, если не сотни тысяч RPS), реализуемые на .NET Core-требуют глубокого понимания механизмов работы GC и умения этим пользоваться.
Но обычно то пишут опердень, а спрашивают будто что-то серьезное
G>Всем привет.
G>Недавно проходил несколько собеседований на .NET и частенько спрашивают про работу GC. G>Стало интересно, как часто вы вмешиваетесь в его работу и по каким причинам?
осенью 2016 на собеседованиях в СПб на вопросы по GC я отвечал,
что у сборщика мусора выявлена новая недокументированная функциональность — возможность проверять подготовленность соискателей на собеседованиях
тогда этого ответа почти хватало
сейчас я думаю дятлов на собеседующих позициях ещё прибавилось, так что придётся подробно отвечать
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, HFTMan, Вы писали:
HFT>>Здравствуйте, Glas, Вы писали:
G>>>Всем привет.
G>>>Недавно проходил несколько собеседований на .NET и частенько спрашивают про работу GC. G>>>Стало интересно, как часто вы вмешиваетесь в его работу и по каким причинам? HFT>>Все highload проекты(эдак десятки, если не сотни тысяч RPS), реализуемые на .NET Core-требуют глубокого понимания механизмов работы GC и умения этим пользоваться.
KP>Но обычно то пишут опердень, а спрашивают будто что-то серьезное
Когда я собеседовал на тему работы GC-нужда действительно заставляла знать потроха GC.
