Здравствуйте, Чистяков Влад (VladD2 ), Вы писали:
ЧВV>Уже много сказано слов о том, что такое GC, чем он хорош и как лучше его применять.
Спасибо, статья оказалась вполне "для меня", несмотря на наличие подробностей и деталей. Всё-таки не так-то и просто оказалось после Object Pascal вписать в мировозрение этот Сборщик мусора. Хотя, конечно, ничего нового и не было изобретено, но это видно после прочтения статьи.
Здравствуйте, Чистяков Влад (VladD2 ), Вы писали:
ЧВV>Аннотация: ЧВV>Уже много сказано слов о том, что такое GC, чем он хорош и как лучше его применять. Но, наверно, очень многим хочется знать, как устроен конкретный GC. Данная статья открывает некоторые подробности устройcтва GC в .NET Framework.
Есть разные способы учета ссылок из прошлых поколений. К сожалению, я не смог найти точную информацию о том, какой способ используется в .NET. Но по сути это и не важно. Важно понимать, что копирование ссылки на объект в поле другого объекта в .NET стоит дороже, нежели в неуправляемых языках. Это, можно сказать, плата за автоматическое управление памятью. В сумме со временем, затрачиваемым на уборку мусора, время, затрачиваемое на барьер записи, составляет основные затраты времени на управление памятью.
В .NET используется механизм защиты виртуальной памяти, а точнее функция GetWriteWatch (подробности на нее можно посмотреть в MSDN). То есть помечаются не отдельные ссылки на старое поколение, а страницы памяти, которые могут содержать эти ссылки.
Еще видел в блоге девелопера (но сейчас не могу найти), что в новых версиях .NET будет использоваться card marking (в Sun JVM он используется уже давно ). При помощи card marking'а так же отслеживается не точное положение ссылки, а "карта" (небольшой блок памяти, обычно 256-512 байт) в которой она находится. По сравнению с виртуальными страницами памяти имеем меньший оверхед по сканированию.
Здравствуйте, Cyberax, Вы писали:
C>Еще видел в блоге девелопера (но сейчас не могу найти), что в новых версиях .NET будет использоваться card marking (в Sun JVM он используется уже давно ). При помощи card marking'а так же отслеживается не точное положение ссылки, а "карта" (небольшой блок памяти, обычно 256-512 байт) в которой она находится. По сравнению с виртуальными страницами памяти имеем меньший оверхед по сканированию.
Отслеживание страниц — это и есть разновидность тарточной пометки. Так что вопрос только в размере блока.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Однако не могу согласиться со следующим утверждением:
...Многие противники GC, не находя аргументов, заявляют, что «GC не пригодно для задач реального времени». Сборщик мусора, реализованный в .NET, действительно непригоден для задач реального времени. Однако будем честными друг с другом – многие ли занимаются такими задачами?
При разработке служб Windows часто приходится решать задачи реального времени.
Здравствуйте, VladD2, Вы писали:
C>>Еще видел в блоге девелопера (но сейчас не могу найти), что в новых версиях .NET будет использоваться card marking (в Sun JVM он используется уже давно ). При помощи card marking'а так же отслеживается не точное положение ссылки, а "карта" (небольшой блок памяти, обычно 256-512 байт) в которой она находится. По сравнению с виртуальными страницами памяти имеем меньший оверхед по сканированию. VD>Отслеживание страниц — это и есть разновидность тарточной пометки. Так что вопрос только в размере блока.
Под "card marking" понимают именно явную пометку в таблице карт.
RB>При разработке служб Windows часто приходится решать задачи реального времени.
Поясните пожалуйста это утверждение. Каких конкретно служб. И еще надо учесть, что Windows — не ОС реального времени, поэтому говорить о задачах реального времени
сложно.
RB>>При разработке служб Windows часто приходится решать задачи реального времени. NC>Поясните пожалуйста это утверждение. Каких конкретно служб. И еще надо учесть, что Windows — не ОС реального времени, поэтому говорить о задачах реального времени NC>сложно.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Red Bird, Вы писали:
RB>>Например, чтение входящих сообщений (e-mail). WH>Гм... а зачем тут реальное время?
И не говори... Нафига ограниченное время реакции на письмо, если само письмо может идти неограниченно долго
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Red Bird, Вы писали:
RB>При разработке служб Windows часто приходится решать задачи реального времени.
Если не пользоваться определениями с базара, то весь Виндовс не пригоден для решения задач реального времени, так как вообще не обеспечивает хоть какого-то гарантированного времени отклика.
То что ты называшь "решать задачи реального времени" на самом деле не являются задачами реального времени. Это просто задачи требующие быстрого отлика в болшинстве случаев.
GC в .NET более чем пригоден для таких задач. Так на нем без проблем можно писать игры или серверы для игр. Да и для большинства задач обработки данных он пригоден. Единственное что нужно делать — это кэшировать входной поток данных. А вот писать программы интерактивно возаимодействующие с аппаратурой на Виндовс нельзя. По крайней мере критические (приводящие к аппоратным сбоям в случае если программа не успеет среагировать).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Red Bird, Вы писали:
RB>Например, чтение входящих сообщений (e-mail).
Даже задача вроде "Instant messenger" не является задачами реального времени. Она требует быстрой реакции программы в общем случае и не критична если программа иногда (например раз в 10 часов) задумается на пол секунды (огромное время по машинным меркам).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Чистяков Влад (VladD2 ), Вы писали:
ANS>Эта, Влад, RASDN же под .Net? А можно привести статистику работы GC с RSDN — размеры поколений, частота сборок, продолжительность пауз?
Можно, но смысла нет. Основное время отедает MS SQL (агреггирующие запросы). ЖЦ практически не влияет на работу. Сборка мусора нулевого поколения просходит раз 1-4 секунды. Раз в 10 секунд просходит сборка второго поколения. Где-то так же первого. Время проведенное в GC колеблится от 0.3% до 3%. В среднем меньше 1%.
MS SQL отжирает 1.6 гига из доступных 3-х. Дотнет 200-300 метров. Периодически поднимается долбаный Перл которым толи спамфильтр проверяется, то ли еще что. Так эта зараза отжирает памяти примерно столько же как основной процесс сайта.
Второе по значимости приложение на дотнете — NNTP-сервер с 17-го числа произвел 600 сборок мусора второго поколения. Время в GC менее 0.01%.
Короче, не влияет ЖЦ тут ни на что.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Можно, но смысла нет. Основное время отедает MS SQL (агреггирующие запросы). ЖЦ практически не влияет на работу. Сборка мусора нулевого поколения просходит раз 1-4 секунды. Раз в 10 секунд просходит сборка второго поколения. Где-то так же первого. Время проведенное в GC колеблится от 0.3% до 3%. В среднем меньше 1%.
А размеры поколений?
ЗЫ. У меня сложилось впечатление, что днём всё заметно медленнее работает. У тебя есть какая-то статистика?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>ЗЫ. У меня сложилось впечатление, что днём всё заметно медленнее работает. У тебя есть какая-то статистика?
Так по тому что днем приходит много народа.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
ANS>>ЗЫ. У меня сложилось впечатление, что днём всё заметно медленнее работает. У тебя есть какая-то статистика? WH>Так по тому что днем приходит много народа.
Мне это действительно интересно. Хотелось бы увидеть что-то дневное и ночное в числовом выражении. Ну, там среднее время отдачи страницы с одним /случайным/ сообщением, распределение по поколениям, процент простоя от GC.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>А размеры поколений?
ANS>ЗЫ. У меня сложилось впечатление, что днём всё заметно медленнее работает. У тебя есть какая-то статистика?
Все упирается в SQL-сервер. Есть некое число запросов которые могут пройти в секунду. Кокда пользователей много (с 10 до 16 и особенно с 11 до 14), то они просто выстраиваются в очеред и получаются тормоза.
В этом в основном виноват и движок сайта который не исползует агрегирование информации. Объем данных все время растет и количество пользователей тоже (хотя оно сдерживается скоростью сайта). Вот на сегодня движок и тормозит в часы пик.
В ближайшее время мы частично решим проблему банальным апгрэйдом железа.
Параллельно мы переписываем сайт. Процесс этот не быстр, так как все люди занятые, а объем работы и их сложность огромны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, WolfHound, Вы писали:
ANS>>>ЗЫ. У меня сложилось впечатление, что днём всё заметно медленнее работает. У тебя есть какая-то статистика? WH>>Так по тому что днем приходит много народа.
ANS>Мне это действительно интересно. Хотелось бы увидеть что-то дневное и ночное в числовом выражении. Ну, там среднее время отдачи страницы с одним /случайным/ сообщением, распределение по поколениям, процент простоя от GC.
На сейчас расклад такой.
Объем памяти (в гигах):
MS SQL 1.66
Сайт + Янус 0.3
Перл (паскуда) 0.2
Статистика памяти процесса сайта (процесс запущен 20.06.2006 в 19:01):
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ЧВV>Авторы: ЧВV> Чистяков Влад (VladD2 )
ЧВV>Аннотация: ЧВV>Уже много сказано слов о том, что такое GC, чем он хорош и как лучше его применять. Но, наверно, очень многим хочется знать, как устроен конкретный GC. Данная статья открывает некоторые подробности устройcтва GC в .NET Framework.
). При помощи card marking'а так же отслеживается не точное положение ссылки, а "карта" (небольшой блок памяти, обычно 256-512 байт) в которой она находится. По сравнению с виртуальными страницами памяти имеем меньший оверхед по сканированию.
