Вы когда-нибудь сталкивались с серьезной деградацией производительности в вашем веб-приложении? Вы могли предпринять все возможные меры, чтобы обеспечить достаточную производительность на всех уровнях вашего сервиса, но все равно столкнулись с медленным временем отклика и значительным количеством запросов, находящихся в очереди в системе. В этой статье мы рассмотрим реальный сценарий, в котором клиент столкнулся с подобными проблемами и как ему удалось выявить и устранить корневую причину проблемы.
Первичная диагностика
Первый шаг в устранении проблем с производительностью – выявление узких мест. В данном случае клиент использовал метод ожиданий и очередей, запрашивая системные представления, такие как sys.dm_os_wait_stats, sys.dm_exec_requests и sys.dm_exec_sessions. Анализ показал, что основными событиями ожидания были CXPACKET, ASYNC_NETWORK_IO и LCK_M_IX.
Изначально команда сосредоточилась на устранении простых исправлений, внесших изменения в конфигурацию, такие как настройка MAXDOP и порога стоимости. Они также сократили количество виртуальных журнальных файлов. Эти изменения привели к изменению профиля событий ожидания, при этом ASYNC_NETWORK_IO стал основным событием ожидания.
Глубже в проблему
Дальнейшее исследование показало, что событие ожидания ASYNC_NETWORK_IO возникает, когда приложение не может обрабатывать наборы результатов из базы данных достаточно быстро. Это привело команду к рассмотрению концепции RBAR, что означает “Row By Agonizing Row”. Это предполагает, что приложение может извлекать большой набор результатов и обрабатывать каждую строку по одной, не сообщая SQL Server, что оно получило набор результатов.
Хотя с точки зрения пропускной способности сети окружение казалось обеспеченным избыточными сетевыми интерфейсными картами 1 Гбит/с, команда решила провести дальнейшее исследование. Они использовали SQL Server Management Studio с функцией “Включить статистику клиента”, чтобы измерить время обработки клиента. К удивлению, они обнаружили, что время обработки клиента было значительным, даже вне сервера приложений.
Попадание в цель
Для выделения проблемы команда разбила конфигурацию сети и запустила тесты непосредственно на сервере. В конечном итоге они обнаружили, что проблема с производительностью вызвана проблемной сетевой картой или конфигурацией сетевой карты. Путем разбиения конфигурации команды удалось устранить проблему, и события ожидания ASYNC_NETWORK_IO исчезли.
Главный вывод из этого сценария – важность полагаться на эмпирические данные при устранении проблем с производительностью. Легко пропустить очевидное и быть введенным в заблуждение предположениями или стереотипами. Кроме того, решение сложных проблем часто требует навыков, выходящих за пределы базы данных. Хорошее понимание всей системы является ключевым для эффективного устранения проблем.
Заключение
Когда вы сталкиваетесь с деградацией производительности в вашей среде SQL Server, важно подходить к проблеме систематически. Используйте инструменты, такие как метод ожиданий и очередей, чтобы выявить основные события ожидания и сначала сосредоточиться на устранении простых исправлений. Проникнитесь в корневую причину, рассмотрев шаблоны проектирования приложений и анализируя время обработки на стороне клиента. Помните, что глубокое понимание системы является ключом к решению сложных проблем.
Ссылки:
- Снижение типа ожидания ASYNC_NETWORK_IO в SQL Server
- Мое любимое состояние ожидания: ASYNC_NETWORK_IO
- sys.dm_os_wait_stats (Transact-SQL)
- Выравнивание разделов диска: это все еще важно (DPA)
- Рекомендации и руководство по настройке параметра конфигурации max degree of parallelism в SQL Server
- Изоляция снимка в SQL Server