Оценка требований IOPS производственной системы SQL Server

Question

Мы работаем над приложением, которое будет обслуживать тысячи пользователей ежедневно (90% из них будут активны в рабочее время, используя систему постоянно в течение рабочего дня). Основная цель системы - запросить несколько баз данных и объединить информацию из баз данных в единый ответ для пользователя. В зависимости от пользовательского ввода, наша нагрузка может составлять около 500 запросов в секунду для системы с 1000 пользователей. 80% этих запросов являются запросами на чтение.

Теперь я провел профилирование с помощью инструмента SQL Server Profiler, и я получил в среднем ~ 300 логических чтений для запросов на чтение (я еще не беспокоился о запросах на запись). Это будет 150 000 логических чтений в секунду для 1 000 пользователей. Ожидается, что в полной производственной системе будет ~ 10 тыс. Пользователей.

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

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

РЕДАКТИРОВАТЬ: Основной набор данных только для чтения (куда пойдет большинство запросов) представляет собой пару гигабайт (порядка 4 гигабайт) на диске. Это, вероятно, значительно повлияет на логическое и физическое чтение. Любое понимание, как получить это соотношение?

Answer 1

Потребность в дисковом вводе / выводе сильно варьируется в зависимости от многих факторов, в том числе:

• Сколько данных уже находится в оперативной памяти
• Структура вашей схемы (индексы, ширина строки, типы данных, триггеры и т. Д.)
• Характер ваших запросов (объединения, несколько строк и ряд строк и т. Д.)
• Методология доступа к данным (ORM против набора, одна команда или пакетная обработка)
• Соотношение чтения и записи
• Состояние фрагментации диска (базы данных, таблицы, индекса)
• Использование твердотельных накопителей и вращающихся носителей

По этим причинам лучший способ оценить загрузку рабочего диска обычно заключается в создании небольшого прототипа и его сравнительном тестировании. Используйте копию производственных данных, если можете; в противном случае используйте инструмент генерации данных для создания БД такого же размера.

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

Измерение результатов с помощью счетчиков производительности Windows. Наиболее полезные статистические данные относятся к физическому диску: время на передачу, количество передач в секунду, глубина очереди и т. Д.

Затем вы можете применить некоторые эвристики (также известные как «опыт») к этим результатам и экстраполировать их на предварительную оценку требований к производственному вводу / выводу.

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

SET STATISTICS IO ON

Перед запуском тестового запроса очистите кэш ОЗУ:

CHECKPOINT
DBCC DROPCLEANBUFFERS

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

Сказав это, я бы рекомендовал не использовать только IOPS в качестве цели. Я понимаю, что поставщики SAN и ИТ-менеджеры, похоже, любят IOPS, но это очень вводящая в заблуждение мера производительности дисковой подсистемы. Например, при переходе от последовательного ввода-вывода к случайному может быть разница в доставляемых IOPS 40: 1.

Answer 2

Вы, конечно, не можете получить свои оценки из логических чтений. Этот счетчик на самом деле не так полезен, потому что часто неясно, насколько он физический, а также стоимость ЦП каждого из этих обращений неизвестна. Я не смотрю на это число вообще .

Вам необходимо собрать статистику виртуальных файлов, которая покажет вам физический ввод-вывод. Например: http://sqlserverio.com/2011/02/08/gather-virtual-file-statistics-using-t-sql-tsql2sday-15/

Google для "Виртуальный файл статистики SQL Server".

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

Если вы можете быть уверены, что ваш буферный пул всегда может принимать все горячие данные, которые вы можете использовать без чтения. Тогда вам нужно только масштабировать записи (например, с помощью SSD-накопителя).