AngryErrorВ продолжение своего тернистого пути к матерому SQL-щику, еще 1 вопрос:
*предыстория*
Один из наших специалистов померял производительность дисковой подсистемы утилитой diskspd, и обнаружил, что при количестве потоков (threads), равным от 16 и выше - производительность снижается (что логично) до неприемлимого уровня (время отклика от 80 мс и выше).
Теперь он заявляет, что в связи с тем, что в нашей БД может работать от 20 до 30 человек одновременно + строются индексы + проходят бекапы логов, и т.д. - количество потоков в нашем случае может достигать 40-50 и более.
*предыстория закончена* Количество пользователей, операции, и потоки IO никак не связаны.

AngryErrorМне бы понять, в чем затык, для начала.Далее, непонятно, какой затык вы имели в виду? Жалобу пользователя?

AngryErrorИ сколько потоков оптимально выставить для теста, чтобы понять - беда со сторейджом или нет.

Сейчас ставлю тест 8КБ блоками в 32 потока (длина очереди - 16) без учета кешей системы на запись вот такие результаты:

thread | bytes | I/Os | MB/s | I/O per s | AvgLat | LatStdDev |
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
total: 786448384 | 96002 | 25.00 | 3199.98 | 168.717 | 321.889

Судя по мануалам к diskspd - отклик в 168 милисекунд это оч много.Чтобы понять - беда со сторейджом или нет, в тесте diskspd (или лучше использовать sqlio) нужно ставить правильные параметры. Сиквел разве так с дисками работает? "8КБ блоками в 32 потока (длина очереди - 16) без учета кешей системы на запись"

AngryErroralexeyvg,

Если я ничего не перепутал:

Механизм упреждающего чтения позволяет компоненту Database Engine считывать из одного файла до 64 последовательных страниц (512 КБ)

При работе с журналом транзакций поддерживается до 32-х запросов ввода-вывода для 64-разрядной редакции сервера, с предельным размером запроса 3840KB

Т.е. мне нужно тестировать на запись блоки в 32-потока по 3840КБ и чтение по 512 КБ ?
Автор: Александр Гладченко. SQL Server: Методика тестирования дисковой подсистемы

AngryErroralexeyvg,

К сожалению, в статье не совсем понял, в чем разница между потоками, которые указываются в параметре -t и реальными потоками в SQL-сервере.
Единственная зацепка - автор говорит, что нет смысла ставить больше потоков, чем установлено процессорных ядер.
Получается, SQL генерирует потоки, ориентируясь на кол-во ядер?Разумеется, если вы выполняете 10 запросов параллельно, то он не делает 10 потоков IO :-)

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

Там ещё есть про типичный размер блока данных, и это 64 кб, а не 8, как у вас. Странное число, почему 8? Бывает 512 байт последовательно, для логов, 64 кб (рандом или последовательно) для страниц данных, 512 кб для бакапов и упреждающих чтений, но никак не 8.

AngryErrorСейчас протестировал дисковую подсистему: (16 потоков, очередь запросов - 8, 50% чтения 50% записи, рандом, блоки по 8КБ) получается в среднем 30 мб/сек. Такое норма для RAID10-массива из 14 FC дисков?Да.

AngryErrorКак раз в той статье, что вы привели.
В таблице с характеристиками для основных типов нагрузки ввода – вывода SQL Server, Файлы данных OLTP системы: 8КБ
Его и тестировал :)В статьеВторой метрикой является производительность передачи данных, так называемый Traffic Throughput. Это основная метрика настоящей методики, поскольку большинству приложений баз данных характерны укрупнённые запросы (например, упреждающее чтение способно использовать запросы ввода-вывода в 64 и 128 КБ).
А 8 кб случайного доступа там конечно упоминается для OLTP, но это очень вырожденный случай. Типа террабйтная база, и выборка/апдэйт случайных коротких записей.

Типично будет последовательный доступ небольшими блоками для лога, + случайный либо последовательный доступ большими блоками для файлов данных.
Вот эти 2 нагрузки и тестируйте, отдельно на разные диски (ведь для этих файлов и будут разные диски, как рекомендовано?)

И ещё, обратите внимание на "Таблица 2. Характеристики для основных типов нагрузки ввода – вывода SQL Server", там всё это немного подробнее.

AngryErrorБыл бы очень признателен, если бы кто-нибудь сформировал примерную строку параметров для теста диска с данными и диска с логами.Ээээ, в конце статьи zip-архив с командным файлом :-)

AngryErrorА остальные параметры важны? Кол-во потоков, длина очереди, игнор буфера, размер тестируемого файла.Количество потоков для файла данных сделайте равным числу ядер, для лога - 1
размер файла - побольше, чтоб кэш не использовался
длинна очереди - лучше мерить с разными очередями, что бы увидеть пик пропускной способности и зависимость от глубины очереди.
Александр игнорирует буфер, что бы замерить именно чистую дисковую подсистему. Но этот подход многие считают неправильным.

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