Отладка и диагностика проблем с блокировкой в ​​.NET

Question

Я смотрю на проблемы производительности большой системы C # / .NET 3.5, которая демонстрирует снижение производительности, поскольку число пользователей, делающих запросы, масштабируется до 40-50 различных пользовательских запросов в секунду.

Длительность запроса значительно увеличивается, в то время как загрузка ЦП и В / В, похоже, остается примерно одинаковой. Это заставляет меня думать, что у нас могут быть проблемы с тем, как общие объекты в нашей системе, которые защищены с помощью операторов c # lock() {...}, могут влиять на производительность одновременного доступа. В частности, я подозреваю, что некоторая степень блокировки блокировок происходит на часто используемых общих данных, которые защищены критическими разделами (потому что они предназначены для чтения / записи).

Есть ли у кого-нибудь предложения о том, как на самом деле диагностировать, является ли проблема с блокировкой? .. или если конкуренция за блокировку любого рода способствует длительному времени запроса?

Answer 1

Конвои блокировки вообще сложно отлаживать. Ваш путь к коду имеет последовательные операторы блокировки напрямую или в ветвях?

Счетчик производительности Total # Contentions дает базовую оценку конкуренции в приложении.

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

Также ознакомьтесь с Windows Performance Tools . Я считаю, что они чрезвычайно полезны, так как вы можете отследить множество проблем низкого уровня, таких как ненормальное переключение контекста.

Answer 2

Хорошее место для начала - взглянуть на счетчики производительности Lock and Thread . Интересно, что именно вы блокируете в своем веб-приложении? Блокировка в большинстве приложений ASP.NET не распространена.

Answer 3

Я не могу дать глубокое представление о диагностике, но если вы найдете доказательства, подтверждающие ваше предположение, тогда вас может заинтересовать System.Threading.ReaderWriterLockSlim, который допускает одновременные чтения, но предотвращает одновременные записи.