Имеет ли смысл оптимизировать запросы для меньшего давления ввода-вывода?

Question

У меня есть база данных (продукт) только для чтения, которая работает на своем собственном Sql Server 2008.

Я уже оптимизировал запросы, просматривая самые дорогие запросы в мониторе активности - отчет.Я заказал отчет по стоимости процессора.Теперь у меня примерно 50 запросов в секунду, и ни один запрос не длиннее 300 мс.

Время процессора в порядке (30%), а память используется только на 20% (из 64 ГБ).

Существует одна проблема: время на диске стабильно составляет 100% (я посмотрел на счетчик времени простоя и использовал диспетчер диагностики ideras SQL).Я вижу, что база данных product ведет себя иначе, чем база данных моего заказа, которая находится на другом компьютере и имеет таблицы меньшего размера: если я смотрю трассировку профилировщика, у меня есть запросы в product-db, которые показывают значение в столбце «read» выше, чем 50.000,В моем БД заказа эти значения никогда не превышают 1000. Запросы в product-db используют много выражений Common table, работают с большими таблицами (некоторые из них содержат около 5 миллионов записей).

Я не уверен, еслиЯ должен потратить время на оптимизацию запросов для производительности ввода-вывода или просто добавить сервер.Оптимизируя продолжительность запроса, я уже добавил недостающие индексы.Оптимизация ввода-вывода - это то, что обычно делается?

Answer 1

Короче да. Оптимизируйте для как CPU, так и IO.

Запросы с высокой загрузкой ЦП, как правило, выполняют ненужные сортировки в памяти, (иногда неэффективные) хэш-соединения или сложную логику.

Запросы с высоким IO (чтения страниц), как правило, выполняют полное сканирование таблицы или работают другими неэффективными способами.

9 из 10, одни и те же запросы будут находиться в верхней части списка, но если вы работали с высокой загрузкой процессора и все еще недовольны производительностью, то непременно работайте с процессорами с высокой IO следующий.

Answer 2

Всегда есть следующее узкое место.

они говорят.

Теперь, когда вы настроили использование ЦП, вполне естественно, что нагрузка ввода-вывода становится доминирующей. Ваша работа уже приемлема? Если да, то остановите, если нет, вам нужно оценить, сколько часов вам придется потратить на дальнейшую настройку, и если покупка другого сервера или более жестких дисков может быть дешевле.

Что касается настройки ввода / вывода, попробуйте посмотреть, чего вы можете достичь с помощью простых мер. Иногда вы можете обменять процессор на ввод-вывод и наоборот. Сжатие является примером для этого. Затем вы настроите тот компонент, который является вашим текущим узким местом.

Прежде чем вы попытаетесь ускорить ввод-вывод, попробуйте уменьшить количество сгенерированных операций ввода-вывода.

Answer 3

Посмотрите на очевидные улучшения производительности ввода-вывода для вашего запроса, но, что более важно, посмотрите, как вы можете улучшить производительность ввода-вывода на уровне сервера.

Если ваши другие ресурсы (процессор и память) не перегружены, вам, вероятно, не нужен новый сервер. Подумайте о добавлении SSD для журналов и временных файлов и / или подумайте, сможете ли вы по своему усмотрению разместить всю свою БД в массиве SSD.

Конечно, устранение узкого места дискового ввода-вывода может увеличить загрузку процессора, но если ваша производительность близка к приемлемой, это, вероятно, улучшит ситуацию до такой степени, что вы можете прекратить оптимизацию на данный момент.

Answer 4

Если вы не используете твердотельные накопители или оптимизированную БД SAN, то IO почти всегда является пределом для приложений баз данных.

Так что да, оптимизируйте, чтобы избавиться от него как можно больше.

Индексы таблиц - это первое, что нужно сделать.

Затем добавьте столько оперативной памяти, сколько возможно, до полного размера ваших файлов БД.

Затем разделите таблицы данных (если этоэто разумно), так что любые необходимые сканирования таблицы или индекса выполняются только на одном или двух разделах таблицы.

Тогда, я полагаю, вы либо покупаете большие машины с еще большим объемом ОЗУ и / или покупаете твердотельные накопители, либоSAN или SAN с твердотельными накопителями.

В качестве альтернативы вы перестраиваете все свое приложение базы данных, чтобы использовать что-то вроде NoSQL или шардинга базы данных, и реализуете все свои отношения, объединения, ограничения и т. Д. На среднем уровне интерфейса.