Топ Вопросов о Памяти в .NET. Окончание 28-32
Предыдущие вопросы: 1-4, 5-8, 9-12, 13-16, 17-20, 21-24, 25-27
28. Что такое хвост распределения задержек (tail latency)?
Хвост распределения задержек - это небольшой процент ответов системы с наибольшим временем отклика. Обычно, рассматривая производительность, например, веб-приложения, нас интересует «среднее время отклика». Оно сообщает нам, каково время отклика для среднестатистического пользователя. Это может быть важным, но также и вводящим в заблуждение. Особенно, если распределение времени отклика является мультимодальным, т.е. когда существуют различные группы времён отклика (например, большинство - очень быстрые, но есть и другая группа очень медленных). Поэтому лучше измерять производительность, наблюдая гистограмму времени отклика, а также следить за хвостом распределения задержек.
Оптимизация хвоста распределения задержек важна, потому что даже если наше приложение работает достаточно хорошо, всё равно будут те несколько процентов пользователей, которые наблюдают действительно медленные ответы. Они могут разочароваться в нашем приложении и больше к нему не возвращаться.
В контексте GC хвост распределения задержек может возникать из-за случайных, но очень длинных пауз на сборку мусора.
29. В чём особенность метода Dispose?
Метод
Dispose - это контракт, представленный интерфейсом IDisposable. Реализуя его, мы явно говорим: «экземпляры этого типа владеют некоторыми ресурсами, которые требуют явной очистки путём вызова метода Dispose». Вот и всё! Что делает метод Dispose, полностью зависит от конкретного случая. Важно помнить, что он не имеет ничего общего с GC и управляемой памятью. Это просто метод, который нужно вызвать. Мы можем вызвать его неявно через using и проверить, вызывается ли он, с помощью анализаторов кода. Вызов его ни о чём не сообщает сборщику мусора и не «освобождает память» после объекта. Такой объект, как и любой другой объект .NET, будет обработан сборщиком мусора, когда сборщик мусора обнаружит, что он больше не используется.30. Можно ли добиться детерминированных пауз на сборку мусора?
Короткий ответ - нет. Мы можем повлиять на время паузы: всё, что снижает нагрузку на память (например, уменьшение количества аллокаций), скорее всего уменьшит время пауз. Некоторые настройки GC тоже могут влиять на них. Но нет гарантии, что время паузы будет детерминированным (например, всегда меньше X миллисекунд). На рынке есть другие сборщики мусора, особенно в мире JVM, которые предоставляют такие гарантии. В .NET их пока нет.
31. Где можно настроить режим GC: серверный или рабочей станции?
Мы можем изменить режим GC только перед запуском приложения, но не во время его выполнения. Для этой цели можно использовать как файл конфигурации, так и переменные среды. Выбор между конкурентным (фоновым) и неконкурентным режимами сборки мусора не зависит от того, работает ли текущий сборщик мусора в режиме рабочей станцией или сервера.
32. Можем ли мы заменить сборщик мусора в .NET?
Да, можем! Начиная с .NET Core 2.0, GC и среда выполнения были разделены. С помощью переменной среды
COMPlus_GCName вы можете указать динамическую библиотеку, которая реализует ваш собственный сборщик мусора, и она будет использоваться средой выполнения .NET Core или .NET 5 вместо библиотеки по умолчанию. Однако есть одна проблема: на рынке нет готовых пользовательских сборщиков мусора.Источник: https://dotnetmemoryexpert.com