Почему запросы SQL Server не используют более 7 МБ / с дискового ввода-вывода

У меня есть SSD, который, используя тест IOmeter, показывает производительность более 200 МБ / с. Однако, когда я запускаю любой запрос SQL с локальной машины, монитор ресурсов Windows никогда не показывает дисковый ввод-вывод выше 7 МБ / с. Это верно даже для запросов, выполнение которых занимает более 2 минут. Что может быть узким местом в том, что он использует только 7 МБ / с от SSD?

Я бегу:

Windows Server 2012 Standard
SQL server 2008 r2
Intel i7 3820
32 ГБ оперативной памяти
Сандиск SSD

sql-server sql-server-2008-r2 hardware

— Дин МакГрегор
источник

возможно, данные уже находятся в оперативной памяти и доступ к диску не требуется?

— 13

@DeanMacGregor - Как вы потребляете результаты? Если в SSMS, что если вы попробуете опцию, чтобы отменить результаты. Это что-то меняет? Также вы можете попытаться просмотреть во sys.dm_os_waiting_tasksвремя выполнения запроса, чтобы увидеть, есть ли другие типы ожидания, с которыми он сталкивается.

— Мартин Смит

Это 200 МБ / с для чтения с произвольным доступом (случайное чтение для блоков 4 КБ)? Я думаю, это то, что обычно делает база данных. Записывает ли запрос на диск (временный файл, временный набор результатов или таблицу)?

@DeanMacGregor - Таким образом, чтобы исключить это из уравнения, вы можете присвоить результат скалярным переменным (пример запроса). DECLARE @Name VARCHAR(10), @High int; SELECT @Name=name, @High = high FROM master..spt_values, Таким образом, никакие результаты не отправляются обратно клиенту, но план и IO останутся прежними.

— Мартин Смит

Предположим, что вы интерпретируете ASYNC_NETWORK_IO ожидает, что означает, что проблема связана с сетью? Это (как правило) нет. Скорее всего, @MartinSmith (дважды) предположил, что SSMS или приложение, которое вы используете, не потребляют результаты так быстро, как их обслуживает SQL. Следуйте одному из предложенных способов исключения потребления строк, и вы получите истинную (r) картину максимальной пропускной способности ввода-вывода.

— Марк Стори-Смит

Из цепочки комментариев, похоже, вы интерпретируете, ASYNC_NETWORK_IOчто означает, что проблема связана с сетью. Это (как правило) нет.

Как @martinSmith намекнул (дважды), наиболее вероятным объяснением этого является SSMS или приложение, которое вы используете, не получая результаты так быстро, как их обслуживает SQL Server. Выполните любой из предложенных способов, чтобы удалить потребление строк из вашего измерения, и вы получите истинную (r) картину максимальной пропускной способности ввода-вывода:

На тот случай, если вы этого еще не сделали, вам, очевидно, нужно DBCC DROPCLEANBUFFERSубедиться, что данные действительно читаются с диска, а не из кеша буфера. Применяются обычные предупреждения «только на тесте, не делайте этого в активной живой среде» и т. Д.

Оттачивая пару других ваших комментариев:

Хотя при выполнении запроса, который возвращает 9 миллионов строк, загрузка ЦП останется на уровне 13%, а 9% - на sqlserver ... разве он не вернет результаты быстрее, чем за 3 минуты, если все данные будут в ОЗУ?

Что именно мы здесь тестируем, как и почему? Если ваш запрос на 9 миллионов строк отличается от a, SELECT * FROM dbo.SomeTableто в игру вступают 1001 фактор, кроме простой пропускной способности ввода-вывода.

Ваш Intel I7-3820 является 4-ядерным процессором. Если ваш тестовый запрос не генерирует параллельный план, я был бы удивлен, если бы вы могли получить более 20% загрузки ЦП из системы.

3 минуты, чтобы вернуть 9 миллионов строк, очень подозрительно и говорят о том, что мы не получаем полной картины того, что вы тестируете. Я предполагаю, что это случай неоптимального (непараллельного) плана запроса, заполненного множеством операторов вложенного цикла, тянущих миллионы строк, то есть не одну таблицу SELECTдля проверки потребления ввода-вывода.

Я предлагаю:

SELECT *проверить только IO через SQL Server.
Новый вопрос с планом выполнения вашего запроса, если вы хотите разобраться, почему он не насыщает ввод-вывод.

— Марк Стори-Смит
источник

На самом деле это просто выбрать * из dbo.sometable. Извините, я не упомянул это раньше; Я имел в виду, что могу выполнить этот запрос с любой таблицы. Происхождение моего вопроса состояло в том, что я заметил, что количество операций ввода-вывода на моем диске было намного меньше, чем я ожидал, даже от простого запроса «предоставь мне много данных». Моя главная проблема заключалась в том, что, если дисковый ввод-вывод настолько низок, можно улучшить производительность, если устранить коренную причину низкого дискового ввода-вывода.

— Дин МакГрегор