SpayniX Web Portal

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Основы анализа производительности SQL Server

E-mail Печать PDF
(0 Голосов)

В любом севере, работающем под управлением ОС Windows (да наверное и не только Windows), есть компоненты от которых зависит его (сервера) производительность. Такими компонентами являются:

  • процессоры;
  • память;
  • диски;
  • сеть.

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

При отыскании причин низкой производительности (особенно современных дорогостоящих систем) всегда встают вопросы:

  • Действительно ли система перегружена по одной из компонент и поэтому работает не так как это ожидается?
  • Действительно ли система подошла к своему пределу производительности для текущей нагрузки, или можно что-либо "подкрутить", исправить ситуацию и система еще будет работать долго, и не потребует огромных капиталовложений?

Обнаружить, что система перегружена по любой из вышеперечисленных компонент не сложно. Для этого можно воспользоваться Task Manager-ом или Performance Monitor-ом и сравнить текущие значения с пороговыми (а они широко опубликованы в Интернете) и вы получите желаемый результат.

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

 

И так. Общий алгоритм анализа производительности и ответа на оба вопроса приведен ниже.

Измерить базовые счетчики для каждой компоненты (подсистемы) сервера и сравнить их показания с пороговыми значениями,

  • если показатели подошли (или превысили пороговые), то приступить к анализу SQL Server с целью определения подсистем SQL Server "съевших" вычислительные мощности сервера.
  • если показатели не превышают пороговые, то быстрее всего проблема медленной работы SQL Server лежит в области неоптимальности самого SQL Server и в этом случае вам, быстрее всего, потребуется подробный анализ SQL Server с помощью SQL Profiler Trace, DMV, DBCC и пр.

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

Далее мы последовательно начнем рассмотрение основ анализа производительности SQL Server, компонента за компонентой. Первые четыре статью будут описывать основы анализа (отыскание корневой проблемы (Root Cost Analysis)). Цель такого анализа - выйти на основной (корневой) источник проблемы.

Перегрузка процессоров

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

Мы будем следовать алгоритму приведенному в предыдущей статье (http://blogs.technet.com/b/sqlruteam/archive/2014/01/08/sql.aspx).

Посмотрим на загрузку процессоров системы. Для этого используем счетчик Processor:%Processor Time. Максимальные показатели этого счетчика определены на уровне 80...85%%.  Перегружены могут быть как все процессоры, так и только часть процессоров системы. В данной статье мы рассмотрим пример когда перегружены все процессоры, как более простой и общий случай. В дельнейшем мы рассмотрим также перегрузку нескольких процессоров.

Как видим из рисунка ниже в момент времени 1.40...1.52 перегружены все процессоры системы. Говоря строго счетчик Processor:%Processor Time = Processor:%User Time + Processor:%Privilege Time, т.е. это сумма времени работы процессора в режиме пользователя и в режиме ядра, но, поскольку это пока только основы, мы упростим это и будем считать, что процессор все свое время работает в режиме пользователя, т.е. все время обслуживает пользовательские процессы.

 ,

Как видно из рисунка приведенного ниже, среднее (суммарное) время загрузки процессоров в интересующий нас период времени составляет более 95%, что очень много.

Также видно, что перегружены все процессоры.

Далее нам предстоит решить задачу отыскания процесса, который "съел" все вычислительные мощности системы. Для этого посмотрим на счетчик Process(...): %Processor Time для каждого процесса. Данный счетчик отображает сумму времени, которое thread-ы, принадлежащие процессу, находятся на процессорах системы. Поэтому не удивляйтесь если увидите значение более 100%. В данном случае мы видим, что для процесса SQLSERVR среднее значение счетчика за указанный период времени около 1576. Если разделить этот показатель на 16 (количество процессоров в системе), то получим 98.5%. Таким образом мы нашли процесс "съевший" все ресурсы процессорной системы, это SQLSERVR.EXE.

Примечание: Исключить из анализа необходимо лишь процесс Idle, который показывает время нахождения Idle thread-ов на процессорах (реально это время простоя процессоров).

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

Как известно из практики эксплуатации SQL Server, процессорная система в наибольшей степени нагружается операциями:

  • Компиляции и рекомпиляции планов выполнения;
  • Операциями сортировки;
  • Операциями хеширования.


Примечание:  Мы предполагаем. что SQL Server используется по прямому предназначению, как сервер реляционной СУБД, а не выполняет сложные расчетные задачи.


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

  • Соотношение между SQL Compilations/sec и Batch Requests/sec
  • Соотношение между SQL ReCompilations/sec и SQL Compilations/sec
  • Соотношение между Workfiles Created/sec и Batch Requests/sec

 ,

Соотношение между SQL Compilations/sec и Batch Requests/sec составляет 0.93 т.е. почти 1, что в 10 раз более установленной нормы. Соотношение SQL Compilations/sec к Batch Requests/sec должно быть менее 10%, т.е. SQL Compilations/sec в данном случае должен быть не более 280.

Соотношение между SQL ReCompilations/sec и SQL Compilations/sec составляет 0.16%, что во много раз менее установленной нормы. Соотношение SQL ReCompilations/sec к SQL Compilations/sec  должно быть менее 10%, т.е. SQL ReCompilations/sec в данном случае должен быть не более 260, а он всего лишь 0.37.

Соотношение между Workfiles Created/sec и Batch Requests/sec. Что такое Workfile - это часть страниц файла данных выделенных для внутренних нужд SQL Server. Отличие Workfile от Worktable состоит в том, что Worktable содержит страницы файла связанные структурами метаданных (IAM) и зарегистрированными в системных таблицах, а Workfile это просто страницы файла данных не объединенные воедино метаданными (IAM). SQL Server активно использует Workfiles для выполнения операций хеширования и хранения промежуточных результатов хеширования (например Hash Backet-ов).

Большое количество создаваемых Workfiles может косвенно указывать на отсутствие индексов, которые может использовать SQL Server для выполнения операций соединения таблиц. В результате чего он вынужден  выполнять соединения таблиц через хеширование.

Норма на соотношение Workfiles Created/sec к Batch Requests/sec  соствляет не более 20%.

Как мы можем видеть в данном случае такой проблемы нет.

Как видно из приведенных выше рассуждений основной проблемой приводящей к перегрузке процессора является большое количество компиляций планов выполнения. В данном случае количество компиляций в 10 раз превосходит норму. Такая ситуация обычно складывается если приложение активно использует динамический TSQL код. Убедиться в том, что этот именно наш случай можно с помощью счетчиков Performance Monitor.

Для этого необходимо просмотреть состав процедурного кэша. Сделать это можно используя объект Plan Cache и счетчик Cache Pages. Данный счетчик измеряет количество 8-ми килобайтных страниц  выделенных под хранение различных типов планов выполнения. Типы планов отображаются через Instance, и могут быть:

  • Bound Trees (Результаты алгебраизации View, можно сказать, что это алгоритмы выборки данных из View)
  • Extended Storage procedures (Планы выполнения расширенных хранимых процедур)
  • Object Plans (Планы выполнения хранимых процедур, триггеров и некоторых видов функций)
  • SQL Plans (Планы выполнения динамического TSQL кода, сюда же попадают автопараметризованные запросы)
  • Temporary Tables & Tables Variables (Кэшированные метаданные по временным таблицам и табличным переменным).

Проанализировав показания этих счетчиков мы видим, что 80...90%% объема процедурного кэша составляет SQL Plans, что и приводит к перегрузке процессоров.

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

В любом случае, мы произвели Root Cost Analysis и корневая причина нами определена.

Наша следующая статья будет посвящена основам анализа проблем с памятью SQL Server.

Память (Memory Analysis)

Мы продолжаем цикл статей по анализу производительности SQL Server.

Ранее мы рассмотрели вопросы связанные с анализом проблем перегрузки процессоров (http://blogs.technet.com/b/sqlruteam/archive/2014/01/12/server.aspx). Также как и ранее, при анализе проблем с памятью, мы будем следовать алгоритму приведенному в предыдущей статье (http://blogs.technet.com/b/sqlruteam/archive/2014/01/08/sql.aspx).
Анализ проблем с памятью имеет некоторые особенности, поэтому мы его разобьем на несколько статей.

Перечень наиболее часто встречающихся проблем связанных с памятью:

  • SQL Server "съел" всю память (или очень много), что начало "угнетать" ОС и приложения работающие на ней.
  • Вы установили ограничения на память потребляемую SQL Server и ему стало не хватать выделенной памяти.
  • Какое-либо приложение потребило слишком много памяти и SQL Server-у стало не хватать выделенной памяти
  • "Перекос" в потреблении памяти каким-либо компонентом SQL Server, что стало причиной "угнетения" других компонентов SQL Server.

Первые три причины называются внешним "нажимом" на память и методика их анализа почти одинакова. Третья же причина называется "внутренним" нажимом на память и методики ее анализа совершенно другие.

Итак начнем рассмотрение первой причины - "SQL Server "съел" всю (или очень много) память, что начало угнетать ОС и приложения работающие на ней."

В качестве ограничения накладываемого на рассмотрение - в блоге мы будем рассматривать только 64-битовую версию SQL Server и ОС, поскольку 32-битовых остается все меньше и меньше.

Для начала надо установить факт, что ОС действительно не хватает памяти и эту память потребил SQL Server. Выполнить это можно посмотрев счетчик Memory: Available Bytes. Он показывает сколько памяти осталось у ОС для распределения приложениям и внутреннего использования. Возникает справедливый вопрос:"Каким образом приложение может потребить много памяти и угнетать ОС?". Причин тому может быть несколько:

  • Утечка памяти в приложении или драйвере, особенно утечка невыгружаемого пула.
  • Установка завышенного значения параметра "max server memory" в свойствах SQL Server и  права "Lock Pages in Memory" для учетной записи от которой работает SQL Server.

Во всех остальных случаях ОС способна сама решать вопросы распределения памяти на основе заложенных алгоритмов. (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366525(v=vs.85).aspxhttp://blogs.msdn.com/b/tims/archive/2010/10/28/pdc10-mysteries-of-windows-memory-management-revealed-part-one.aspx,http://blogs.technet.com/b/askperf/archive/2007/02/23/memory-management-101.aspx,http://msdn.microsoft.com/en-us/library/windows/hardware/gg463344.aspx).

У нас (Microsoft) есть принятая норма на остаток памяти который должен оставаться доступным для распределения ОС. Эта норма составляет 5% от объема установленного RAM, т.е. в свободном распределении у ОС должно остаться не менее 5% от общего объема RAM установленного на сервере. И как бы это число не казалось большим (особенно при больших объемах установленной памяти), лучше этого правила придерживаться. 
Что будет предпринимать ОС, когда приложения потребят слишком много оперативной памяти? При достижении порога Memory: Available Bytes в 100...50 MB Windows включит агрессивный сброс (trimming) рабочих наборов процессов, включая системные драйверы, что тут же приведет к резкому снижению производительности всех компонентов ОС. В данной статье мы не будем рассматривать эти вопросы, возможно мы рассмотрим их в будущем.

Каким образом рассчитать правильное значение "max server memory"?

Здесь есть два случая:

  • Некластеризованный SQL Server, либо кластеризованный SQL Server в режиме Актив/Пассив .
  • Кластеризованный SQL Server работающий в режиме Актив/Актив.

Расчет памяти для некластеризованного, либо кластеризованного SQL Server работающего в режиме Актив/Пассив .

  1. Остаток для ОС - 5%. В нашем случае это около 25 GB (500*5%).
  2. Память под ядро SQL Server (различные *.exe, *.dll, *ocx и пр. модули), SQL heap, CLR. Обычно это до 500 MB, хотя за счет CLR это может быть и больше.
  3. Пямять под кэши "Worker thread", рассчитываемая по формуле (512+(NumCpu-4)*16)*2 MB. В нашем случае это (512+(64-4)*16)* 2MB = 2944 MB (около 2.7 GB).
  4. Итого под "max server memory" остается:  500 - 25 - 0.5 - 2.7 = 471.2 GB. Т.е. размер Буферного пула (при таком значении "max server memory") может вырасти до 471 GB.
  5. Для версии SQL 2012 и далее "max server memory" включает в себя SQL heap и частично CLR.

Особенно актуален это расчет, если вы используете "Lock Pages In Memory" В этом случае завысив это число или оставив его по умолчанию (что обозначает - любой объем) вы можете поставить ОС в довольно неприятное положения, которое приведет к агрессивному триммированию рабочих наборов и, как следствие, резкому замедлению работы системы.

Расчет памяти для кластеризованный SQL Server в режиме Актив/Актив.

При расчете необходимо учитывать, что пункты 2, 3 и 4 должны быть удвоены, и при использовании права учетной записи SQL Server "Lock Pages In Memory", вам необходимо подобрать не только "max server memory", но и "min server memory", что бы в случае переката обоих SQL Server на один узел вы не забрали всю память у ОС.

В данном случае на сервере установлено 500 GB оперативной памяти и 5% должно быть около 25 GB. Каким бы большим не казалось это цисло, но чем больше на сервере процессоров и памяти, тем (как правило) более ресурсоемкие задачи он выполняет и для их решения ему требуются большие ресурсы.

Как видно из рисунка (в данном случае), остаток памяти на сервере составляет около 7 GB, что не соответствует нашим рекомендациям.

Далее нам необходимо понять, имеет ли SQL Server достаточный запас памяти, часть которого можно освободить в пользу ОС. Для ответа на этот ��опрос необходимо проанализировать счетчики производительности SQL Server.

Давайте сначала выясним сколько памяти потребил SQL Server. Для этого надо знать, использует или нет SQL Server право учетной записи SQL Server "Lock Page In Memory", Выяснить это можно из свойств учетной записи, а можно косвенно, через счетчики Performance Monitor. Дело в том, что если право учетной записи SQL Server "Lock Page In Memory" не установлено, то вся (или почти вся) используемая память будет частью рабочего набора процесса sqlservr.exe. Если же это право установлено, то при этом (скрыто) используется механизм AWE (Address Windows Extension) и основная память под Буферный пул будет размещена за пределами процесса sqlservr.exe.

Как видно из рисунка ниже, размер рабочего набора процесса составляет всего около 4 GB, что значительно меньше общего объема потребленной памяти.

Посмотрим, сколько всего памяти использует SQL Server. Он использует 500 857 024 (около 480 GB) для распределения на Буферный пул, Процедурный кэш, кэш Worker Thread и для некоторых не значительных потребителей. А отсюда можно сделать вывод, что в данном случае SQL Server использует "Lock Pages in Memory".

Далее приступим к поиску ответа на вопрос:"Можно ли отобрать часть памяти у SQL Server, не нанося ему вреда?"

Во первых, давайте проверим какое количество запросов обслуживается из Буферного пула (без выполнения физических чтений). Как мы видим из рисунка ниже по тексту около 100% (точнее 99,972%) запросов выполняются из буферного пула (при пороговом значении данного счетчика не менее 92%), что дает нам надежду на наличие избытка памяти у SQL Server.

Следующим счетчиком, который рекомендуется посмотреть является SQL Server: Page Life Expectancy. Он контролирует время жизни страниц в Буферном пуле. Пороговое значение 300 секунд. В данном случае мы видим среднее значение около 221000, что почти в 700 раз больше порогового. Это укрепляет нас в мысли, что ресурсы есть.

Окончательный ответ нам поможет дать счетчик SQL Server: Lazy Writes/sec, отображающий как часто срабатывает процесс Lazy Writer. Мы знаем, что это процесс активируется тогда, когда у SQL Server заняты около 75% выделенных буферов. Его задача выполнить фиксацию данных и очистить буферы. Для систем имеющих значительный запас памяти этот счетчик должен быть близок к нулю. Как мы видим это так.


Из всего вышесказанного можно сделать вывод: SQL Server имеет достаточный объем памяти и может "поделиться" ей с ОС. Отбирая память у SQL Server (уменьшая "max server memory") необходимо контролировать выше описанные счетчики и определить тот порог, ниже которого уменьшать объем памяти нельзя.

Диски (Disk analysis)

В предыдущих статьях мы рассмотрели примеры анализа производительности SQL Server связанные с проблемами с процессорами и памятью (http://blogs.technet.com/b/sqlruteam/archive/2014/01/08/sql.aspx,http://blogs.technet.com/b/sqlruteam/archive/2014/01/12/server.aspx,http://blogs.technet.com/b/sqlruteam/archive/2014/02/10/sql-server-memory-analysis.aspx).

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

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

  • операции чтение страниц с файла данных для загрузки их в Буферный пул;
  • операции записи данных в файл журнала транзакций при завершении (Commit)  транзакций;
  • операции записи страниц в файл данных для фиксации произведенных модификаций.

Операции чтение страниц с файла данных для загрузки их в Буферный пул

Несмотря на то, что SQLServer: Buffer Manager: %Buffer Cache Hit Ratio может составляет 98...99%%, однако существует вероятность, что необходимая вам для выполнения запроса строка окажется на диске, и потребуется две операции ввода - физическая (время выполнения которой может быть до десятков миллисекунд), и логическая (с временем выполнения несколько десятков нано...микросекунд). Как видно разница между микро и мили 1 000 раз, а нано и мили 1 000 000 раз!!! Отсюда становиться ясно, что даже при огромных размерах страничного кэша (Buffer Pool), достаточно одной строчки, чтобы испортить радужную картину. Конечно не все так ужасно, как я описал, поскольку существует и работает множество алгоритмов для минимизации данной проблемы, но реально, все же, это возможно и такие задержки действительно возникают.

Примечание: Вообще, строго говоря, счетчик SQLServer: Buffer Manager: %Buffer Cache Hit Ratio не может использоваться как индикатор недосттка памяти и показатель достаточности размера буферного пула, поскольку на выполнение операции ReadAhead данный счетчик никак не реагирует, хотя при этом считывается огромные объемы данных. Связано такое поведение с тем, что данный счётчик учитывает только чисто физические операции чтения выполнение которых инициировано процессором запросов для загрузки страниц необходимых для выполнения данного запроса, и он никак не учитывает операции ReadAhead, которые по объему загружаемых с диска данных могут в разы превышать эти операции.

У нас (MSFT) есть пороговые значение на латентность операции чтения с дисков для SQL Server. Эта латентность меряется счетчиком Physical Disk: Avg. Disk sec/Read и не должна превышать 15 мсек. Если вы видите время задержки более этой величины и продолжительное по времени, то это может обозначать наличие дисковой проблемы.

Примечание: Далее рекомендуется посмотреть какое количество операций физического чтения делает ваш SQL Server и присутствуют ли необходимые индексы. Поскольку построив необходимые индексы вы уменьшаете количество физических чтений и, тем самым, снижаете нагрузку на дисковую систему, и, как следствие, уменьшаете латентность дисковых операций. Показания счетчика BufferManager:Page Reads/sec, должны быть не более 90...100, а соотношение SQLServer:Access Method: Index Searches/sec и SQLServer:Access Method: Full Scans/sec должно быть около или более 1000.

Операции записи данных в файл журнала транзакций при завершении (Commit)  транзакций

SQL Server подобно другим современным СУБД использует механизм упреждающей записи при модификации данных. Суть механизма состоит в том, что модифицированная запись не может появиться в файле данных, до тех пор, пока модификации не будут отображены в журнале транзакций. Особенно критично это для операции Commit, которая является сигналом для СУБД, что данная модификация выполнена успешно и доведена до конца. По сути латентность выполнения транзакций напрямую зависит от задержек связанных с появлением Commit записи в журнале транзакций. Запись в журнал транзакций производится через специальный внутренний буфер (Log Buffer), размер которого управляется SQL Server-ом. Временные задержки, возникающие при этом можно оценить с помощью счетчика SQL Server:Databases: Log Flush Wait Time и SQL Server:Databases: Log Flush Waits/sec. Разделив SQL Server:Databases: Log Flush Wait Time на SQL Server:Databases: Log Flush Waits/sec, мы получим среднее время ожидания при записи данных в журнал транзакций в миллисекундах.

У нас (MSFT) есть пороговые значение на латентность операции записи на диск для SQL Server. Эта латентность меряется счетчиком Physical Disk: Avg. Disk sec/Write и не должна превышать 15 мсек. Реально она должна быть менее этой величины  (поскольку операция записи подтверждается при попадании данных в кэш записи контроллера диска) и составлять 3...4 мсек (для SAN) и 8...10 мсек (для локально присоединенных дисков). Если вы видите время задержки более этой величины и продолжительное по времени, то это может обозначать наличие дисковой проблемы.

Операции записи страниц в файл данных для фиксации произведенных модификаций

Выполнение данного вида записи, как правило, не приводит к проблеме, поскольку эти операции производятся специальными Redo thread-ами в асинхронном режиме. К проблемам может стать ситуации, когда:

  • производилась перестройка индексов и Redo thread-ы не успевают достаточно быстро записать модифицированные данные в файлы данных, отчего объекты с индексами не доступны.
  • Redo thread на зеркальной (AlwaysOn) базе не успевает записать данные в файлы данных, отчего зеркало (AlwaysOn) не переходит в работоспособное состояние.
  • Redo thread при восстановлении базы из резервной копии не успевает быстро записать данные в файлы данных, отчего база не переходит в работоспособное состояние.

Проблема с перестройкой индексов может быть решена путем выполнения Online Index Rebuilding.

Скорость работы REDO-thread зависит, в основном, от скорости работы дисковой подсистемы. Вы можете рассчитать какова текущая разница между данными, хранящимися в файле первично и вторичной реплик. Для этого вам необходимо Database Replica: Recovery Queue разделить наDatabase Replica: Redone Bytes/sec.

Ниже приведен пример одной из проблем заказчика, у которого возникали периодические проблемы с работой Log Shipping.

Итак начнем.

Сначала посмотрим на основные счетчики системы и начнем мы с дисков, поскольку алгоритм Log Shipping устроен таким образом, что при его работе активно используются именно диски.


Обратите внимание, что в некоторые моменты времени латентность дисковых операций составляет 91 секунду, что 6 000 раз более максимально допустимого значения для SQL Server (15 мсек).

Необходимо понять, что является причиной таких огромных задержек дисковых операций. Для этого попробуем проанализировать отдельно счетчики Avg. Disk sec/Read и Avg. Disk sec/Write. Как мы знаем латентность операций записи должна быть в несколько раз меньше латентности операции чтения, поскольку подтверждение операции записи приходит с кэш-контроллера, а чтения после переноса данных с физических носителей в буферы сервера.

Однако это не так, как видно из рисунка оба вида задержек почти однопорядковые. Отсюда мы можем сделать вывод, что перегружена вся дисковая система.
В данном случае мы имеем дело с локально присоединенными дисками (Local Attached Storage), в качестве которой используется PowerVault MD3000 Direct Attached Storage. Стойка состоит из 20-ти (10 000 rpm) дисков объединенных в RAID 10. Т.е. количество информационных дисков в данном случае 10. Исходя из расчетной скорости передачи одного диска: MAX 10 000/60 = 166 IOPS (при полностью последовательном чтении) и MIN 10 000/60/2 = 83 IOPS.(при полностью произвольном чтении) получаем среднюю скорость передачи таких дисков около 110...120 IOPS. Отсюда получаем производительность стойки из 10 дисков равную MAX 10х166 = 1660 IOPS и MIN 10х83 = 830 IOPS.
Давайте же посмотрим какое количество IOPS отправляется на стойку.

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

И это действительно так. Как видно из рисунка ниже очередь действительно есть.

В среднем она составляет 111, максимум 255. Очередь 111 превышает норму для локально присоединенных дисков в 5 раз (норма составляет не более чем 2 умножить на  количество информационных дисков, т.е. в данном случае очередь должна быть не более 20). Очередь же 255 указывает на полное блокирование контроллера дисковой стойки, и о его не способности обрабатывать такой поток данных. Очередь 255 говорит о том, что дисковый стек Windows полностью загружен IRP пакетами и они более не передаются на контроллер, поступление новых пакетов от приложения отвергается ОС.

Примечание: Анализ дисковых систем на основе очередей применим лишь для локально присоединенных систем и не может применяться для SAN (Storage Area Network), поскольку там не возможно определить количество дисков задействованных в операциях ввода/вывода.

Возникает справедливый вопрос: Неужели при таких задержках нет никаких записей в журналах? Да они есть.

Это строки из журнала Application

BackupDiskFile::CreateMedia: Backup device 'E:\backup_tmp\TransactionLogShipping\Приложение_службы_поиска_DB\Приложение_службы_поиска_DB_36993c336ce14e99a678fd3a52f4dd3f_20140305014550.trn' failed to create. Operating system error 1117(failed to retrieve text for this error. Reason: 15105).

Ошибка 1117 означает "Запрос не может быть выполнен из-за ошибки ввода/вывода." Данная ошибка являются индикатором того, что существует проблема с дисками.

Отсюда рекомендации заказчику: "Непременно и срочно заняться своей дисковой подсистемой".

Давайте выполним еще одно упражнение. Попробуем понять какой из процессов ОС "съедает" все ресурсы. Для этого мы воспользуемся счетчиком 

Как показал анализ счетчика Process(*):IO Data Bytes/sec наибольшее количество операций ввода/вывода порождает SQL Server. Более того, его активность по времени точно совпадает с дисковыми проблемами. Следовательно, можно предположить, что именно этот процесс и является основной причиной дисковых перегрузок.


Как видно из рисунка, в некоторые моменты времени количество операций ввода/выводе, генерируемое данным процессом достигает 455 000 000, что очень много даже для мощных дисковых систем.

Заключение.

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


Источник: blogs.technet.com

Обновлено 13.03.2016 00:10  
network monitoring tool


Поиск

Информация о профиле

Application afterLoad: 0.003 seconds, 0.52 MB
Application afterInitialise: 0.157 seconds, 3.13 MB
Application afterRoute: 0.182 seconds, 3.68 MB
Application afterDispatch: 0.444 seconds, 8.41 MB
Application afterRender: 0.823 seconds, 9.51 MB