У меня классическая битва между разработчиком и системным администратором, в которой я заявляю, что на диске общего сервера sql есть проблема ввода-вывода, в то время как системный администратор сообщает мне, что емкость вообще не достигнута.
Я смог указать на одну вещь: средняя длина очереди диска на сервере SQL очень велика. Средняя длина очереди составляет 5 и регулярно увеличивается до 10–15. Она никогда не достигает значения менее 2,5.
Системный администратор сказал мне, что это не проблема, потому что диск представляет собой полосу из 6 дисков, а длина очереди по определению плохая, если она больше, чем удвоенное количество шпинделей. Таким образом, его формула 6 * 2 = 12, что ниже среднего 5.
Его рассуждения верны? Можем ли мы просто смотреть на лазурный диск как на веретено? Постоянная средняя длина очереди мин. 5 не является показателем?
РЕДАКТИРОВАТЬ: Как оказалось, диски были огромным узким местом. После перемещения баз данных на отдельный сервер баз данных приложение снова работает без сбоев.
Довольно новичок в Azure, но вот мое предложение:
Чем больше дисков Azure вы охватите, тем выше будет ваша производительность, это правда. Однако я не уверен в уравнении. В любом случае, я думаю, вы лаете не на то дерево ...
Azure накладывает искусственные ограничения на такие показатели, как количество операций ввода-вывода в секунду и максимальное количество операций чтения / записи в секунду, поэтому длина очереди - это лишь одна из немногих метрик, на которые необходимо обратить внимание.
Этот вопрос по своей природе похож на ваш. В нем есть полезная ссылка на Статья о производительности Azure SQL, слишком. Если вы следуете рекомендациям Microsoft, это может помочь вам повысить производительность.
Я не уверен, что дальнейшее увеличение количества используемых дисков поможет. Из того, что я видел, рост не линейный. Вы можете ожидать, что IOPS для 6 дисков будет 3000 (6x500), но, вероятно, это больше похоже на 2000.
Переход на уровень DS (SSD) может быть единственным способом получить желаемую производительность от одной виртуальной машины. Вот краткое изложение ограничений экземпляра Azure: https://azure.microsoft.com/en-gb/documentation/articles/virtual-machines-size-specs/
Наконец, лучший способ улучшить производительность любого приложения - снизить зависимость от ввода-вывода. По возможности кешируйте. Вы можете попробовать экземпляр с большим объемом памяти.
Вы слишком много внимания уделяете одной метрике!
Диагностика узкого места для отдельного компонента редко заканчивается тем, что один счетчик дает полное объяснение.
Есть довольно много здорово гиды для использования perfmon для диагностики проблем с производительностью на SQL Server.
И к сожалению ваш админ мог Будьте правы, выбранный вами счетчик действительно зависит от используемого оборудования. Однако я не могу найти никакой документации, в которой говорится, что Azure основан на 6-дисковом рейде. Так что, возможно, сосредоточимся на других счетчиках?
Но в качестве последней рекомендации. Если бы вашим единственным показателем была Avg. Disk Queue Length, вероятно, ваш системный администратор прав.
Если вы уверены, что это проблема с диском, вы всегда можете попробовать создать места для хранения вещей.