Comments 28
Меня (возможно и не только меня) уже на протяжении многих лет в разных проектах преследует спонтанно возникающий глюк у mssql: условно говоря раз в месяц/другой (но строгой периодичности нет) он беспричинно начинает грузить одно ядро процессора и почти перестает отвечать на запросы. Что я только ни делал… обрубал все сетевые коннекты, останавливал сайты, даже рестартовал инстанс- всё равно он сразу возвращался к тормозам. В логах и профайлере никаких признаков ддоса или циклических запросов выявить не могу. Чаще всего помогает ребут винды.
надеюсь, статья вам поможет
спасибо, буду рад )) Правда в моем случае я не уверен, что эти проблемы в прямой зависимости от запросов пользователей (ну или учетки движка сайта), ибо тогда оно по-любому отлавливалось бы профайлером.
Что касается нагрузки на диски — в первую очередь нужно выучить, что такое IOPS и как они связаны с пропускной способностью. И тогда внезапно может стать понятно, что, например, 50Мб/сек на 4K блоках со случайным доступом может быть совсем не мало, и высокая очередь — это никакие не проблемы с железом, а банально недостаточно производительная дисковая.
не смешивайте файлы ОС с файлами данных БД. Размещайте их на физически разных носителях чтобы система не конкурировала с СУБД за ввод-вывод.
А что, разве ОС сама по себе создает какую-то серьезную нагрузку на диски? Разве только при постоянном своппинге, но тогда не о разнесении нагрузки на разные диски думать надо, а совсем о другом. Предлагаю вам на досуге померять, что будет быстрее — ОС + СУБД на RAID-10 из 4-х дисков, или ОС и СУБД на отдельных зеркалах.
И т.д, и т.п.
Резюмируя — на самом деле нужна голова на плечах и минимальное понимание происходящих процессов. Тогда половина рекомендаций в таких статьях сразу окажутся капитанскими, а вторая половина — вредными.
надеюсь статья поспособствует тому, чтобы больше людей стали считать эти советы капитанскими.
Я не вижу, как это может произойти, если вы описываете волшебные пилюли вместо того, чтобы давать понимание. Для примера — ну нельзя понять, что в случае СУБД происходит с нагрузкой на диски, не оперируя понятием IOPS, а вы это даже мимоходом не упоминаете.
просто для меня лично удобнее прокачку оценивать в Мб/с, но тут кому как.
При одном постоянном типе нагрузки она, конечно, линейная. Но при этом оперировать скоростью чтения, а не иопсами, может только человек с некоторым опытом. Если начинать с азов, то нужно понимать, чем вообще скорости работы с дисками ограничиваются. А это совершенно разные параметры для случайных и последовательных операций.
Если понимать, что скорость случайного чтения ограничена средним временем поиска, то становится ясно, что, скажем, с 15К SAS HDD с паспортным средним временем поиска 3.3мс вы не снимете больше примерно 300 IOPS, что, например, на 4К блоках даст нам жалкие 1.2 Мбайт/сек. А для Enterprise SATA, которые сейчас весьма популярны, цифры уменьшаются еще вдвое. А, скажем, 50Мбайт/сек в таких условиях можно снять только с массива из минимум 40 15K SAS HDD, что в природе хоть и встречается, но отнюдь не у целевой аудитории вашей статьи.
Поэтому для оценки, насколько адекватно работает система в режиме случайного доступа, в перфмоне смотреть надо вовсе не скорость чтения, а количество операций в секунду (ну или уметь пересчитывать одно в другое).
А что, разве ОС сама по себе создает какую-то серьезную нагрузку на диски?
ОС может и не создает, но сам диск может оказаться совсем не производительным. Встречал случаи когда С: создан внутри виртуальной машины которая лежит на общей хранилке с кучей всего остального и производительность там совсем никакая.
В таком случае, вполне разумно файлы БД убрать с С:.
прошу не воспринимать раздел «советы» как руководство к действию, а лучше как «варианты на подумать».
надо будет в следующий раз в статье предупреждение указать :)
Разумеется, RAID10 быстрее RAID1 примерно в два раза будет. А ОС не даст такую же нагрузку, как СУБД.
Все честно. Вот есть у нас сервер с N дисками. Тормозит. Мы решаем вынести ОС на отдельное зеркало. Но откуда диски под него взять? При работе в рамках имеющегося оборудования, без апгрейда — только изъять из имеющегося массива. Вот и получаем в реальной жизни сравнение "N дисков, но вместе с ОС" против "N-2, но без ОС".
Если первое — Вам надо куда-то забэкапить данные, чтобы пересобрать один RAID10 на два RAID1.
Если второе — мы оперируем любым количеством дисков для соблюдения одинаковых условий — и там, и там RAID10.
Это не я решаю задачу. :) Это автор предлагает решать задачу тормозов дисковой подсистемы конкретного сервера путем разнесения ОС и СУБД на разные физические диски. И мои комментарии следует воспринимать исключительно в этом контексте, а не в контексте некоего абстрактного тестирования в лабораторных условиях.
docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html
А так всё перепробовал. и таймауты, и настройки различные…
Очередь желательно чтобы не превышала 1. Допустимы кратковременные всплески, если они быстро спадают. Всплески могут быть разным
Откуда такая информация? Даже для старых дисков говорили про 2N, где N — количество шпинделей.
Если интересно ознакомиться с темой глубже — вот неплохая статья (правда, трёхлетней давности): Управление глубиной очереди дисков для достижения лучшей производительности
Но. Если это write-ahead запись в LDF, то очередь 1 — это значит, что вы полностью упёрлись в производительность диска. Потому что тут: SQL кинул запись в журнал транзакций (очередь стала 1), подождал, получил ответ от ОС «я кончила» (очередь стала 0) и тут же кинул новую запись в журнал.
Так что если очередь 1, то уже нужно убедиться, что это не связано с однопоточным синхронным сценарием IO.
в первую очередь, обновите статистику и перестройте индексы
Статистика по-умолчанию обновляется сама,
а индексы перестраивать надо только те, которые имеют определенное количество страниц и уровень фрагментации. Перестройка индекса очищает кеш планов, что в некоторых случаях воспринимается как «волшебная помощь» именно от перестройки индекса, хотя дело-то в кеше планов.
Кроме того, так как ни слов «кеш планов», ни IOPS, в вашей статье нет, то рекомендовать ее кому-либо, в том числе новичкам, смысла я не вижу.
«скорость варьирует»->«скорость изменяется(варьируется)»
- Использовать протокол Shared Memory
- Изменить «шаг» роста для рабочих баз со стандартного 1 МБ на 100 МБ
- Убедиться, что план электропитания стоит «Высокая производительность». В случае виртуализованного сервера — и на гипервизоре
Кто-то скажет, что эти пункты о быстродействии, а не об анализе, но у меня и от статьи такое ощущение.
Анализ работы MS SQL Server, для тех кто видит его впервые