Оценка требований к IO для пакетного использования

У нас есть приложение, которое периодически запрашивает базу данных SQL в течение дня. Есть периоды нулевой или только легкой активности, чередующиеся с индивидуальными запросами относительно больших объемов данных. Когда поступают эти запросы, основная цель состоит в быстрой доставке данных, а вторая задача - сделать это экономически эффективным. Из-за характера приложения весьма маловероятно, что данные / индексы будут кэшироваться в ОЗУ из предыдущего запроса (разные пользователи работают с разными частями данных).

Для системы, которая использует относительно устойчиво, я слышал эмпирическое правило, чтобы наблюдать за длиной очереди диска и сохранять это число относительно небольшим. Это в частности будет работать в AWS, где я видел практическое правило, что длина очереди диска 1 на 100 IOPS является разумной.

Как я могу оценить требования к IO для такой системы? Является ли длина очереди диска надежным показателем при работе с отдельными пакетными запросами? Есть ли другие метрики, которые я должен рассмотреть?

Основной показатель, который я всегда рассматривал для ввода-вывода в SQL Server, - это не количество операций ввода-вывода в секунду или длина очереди диска, а пропускная способность диска (с / чтений и с / записей). В целом, базы данных не о том, сколько операций вы можете выбросить на диск, а о том, как быстро эти операции завершаются. Общее эмпирическое правило - использовать менее 20 мс / операция (хотя чем ниже, тем лучше). Более подробно можно найти в этой статье .

Длина очереди диска является фиктивной статистикой и больше не актуальна. Проблема в том, что это значение измеряет очередь для одного диска, но теперь, когда мы живем в эпоху RAID, SAN и других распределенных хранилищ, нет способа правильно перевести это значение в значащее число. Отличной отправной точкой для определения показателей производительности является этот плакат от Quest / Dell, в котором вы найдете множество материалов и объяснений, почему они важны или нет. Вам не нужно использовать их все, но они являются началом.

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

Наконец, примечание по AWS: насколько мне известно, Amazon не гарантирует производительность ввода-вывода в AWS. В первую очередь это связано с тем, что хранилище является крупным общим ресурсом, и невозможно измерить шаблоны вас и ваших соседей в определенной области хранилища (см. Проблему Noisy Neighbor ).

Я рекомендую выделить как можно больше памяти. SQL Server будет выталкивать из памяти только то, что находится под давлением и в буферном пуле (на основе LRU-K). Таким образом, если ваш буферный пул может хранить большую часть базы данных в памяти, вы можете уменьшить некоторую пиковую производительность. Кроме того, рассмотрите тактику, которая может сохранять объекты кэша «теплыми». Наконец, следите за SQL 2014 и новой функцией Hekaton .