Avg disk queue length

Краткое содержание:

Сбор и анализ информации по загруженности оборудования системы.

Применимость: MS Windows.

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

  • Все рабочие сервера кластера 1С:Предприятия
  • Сервер СУБД
  • Клиентские рабочие станции, работающие под большой нагрузкой

Для каждого из этих компьютеров необходимо настроить постоянный сбор информации по загруженности оборудования.

Сбор информации по загруженности оборудования

Рекомендуется осуществлять постоянный мониторинг и запись основных показателей загруженности оборудования во время работы системы. Для этого следует использовать штатный Performance Monitor, входящий в состав операционной системы Windows.

Откройте окно управления компьютером:

В разделе «Производительность» создайте новый замер:

Добавьте в замер следующие счетчики:

  • Memory Pages/sec
  • Pocessor [_Total] %Processor Time
  • System Processor Queue Length
  • Phisical Disk Avg. Disk Queue Length
  • Network Interface Bytes Total/sec

Рекомендуемая частота получения значений – один раз в 15 секунд.

Перейдите на закладку «Log Files» и установите тип файла «Binary Circular File»:

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

Нажмите кнопку «Configure» чтобы задать каталог для хранения файла замера и предельный размер файла:

Сохраните созданный замер. При этом он будет запущен автоматически:

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

Анализ собранной информации

Просмотр сохраненного замера

Временно остановите сбор информации (Stop) и скопируйте файл замера в другую папку. Затем следует возобновить сбор информации (Start).

Запустите скопированный файл замера, дважды кликнув по нему мышкой. В запустившемся Performance Monitor укажите мышкой на поле графиков, вызовите контекстное меню и выберите из него пункт «Свойства».

В открывшемся окне перейдите на закладку «Источник данных» и выберите скопированный файл замера.

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

Затем перейдите на закладку «Данные», удалите все счетчики, которые есть в списке, а затем при помощи кнопки «Добавить» добавьте счетчики, сохраненные в файле замера:

Нажмите кнопку «ОК» и сохраненный замер откроется в основном окне Performance Monitor.

Анализ данных замера

Анализ данных следует проводить на основании среднего и максимального значения для каждого счетчика на выбранном интервале времени. Эти значения отображаются в нижней части основного окна Performance Monitor.

Ниже в таблице приведены описания счетчиков Performance Monitor и предельные значения для каждого из них. При превышении этих значений следует рассмотреть вопрос о увеличении производительности соответствующей аппаратной компоненты.

Предисловие

Часто возникает потребность в режиме реального времени сообщать администратору о проблемах, связанных с БД (базой данных).

В данной статье будет описано, что необходимо настроить в Zabbix для слежения за базой данных MS SQL Server.

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

Решение

Вначале опишу все те счетчики производительности (через элементы данных в Zabbix), которые нам нужны:

    Logical Disk
    Avg Disc sec/Read
    Показывает выраженное в секундах среднее время чтения данных с диска. Среднее значение счетчика производительности Avg. Disk sec/Read не должно превышать 10 миллисекунд. Максимальное значение счетчика производительности Avg. Disk sec/Read не должно превышать 50 миллисекунд.

Zabbix: perf_counter[LogicalDisk(_Total)Avg. Disk sec/Read], а также важно проследить за нужным диском, например так: perf_counter[LogicalDisk(C:)Avg. Disk sec/Read]

Примеры триггеров:
<НАЗВАНИЕ_УЗЛА:perf_counter[LogicalDisk(_Total)Avg. Disk sec/Read].last()>>0.005, уровень-высокий
и
<НАЗВАНИЕ_УЗЛА:perf_counter[LogicalDisk(_Total)Avg. Disk sec/Read].last()>>0.0025, уровень-средний

Avg Disc sec/Write
Показывает выраженное в секундах среднее время записи данных на диск. Среднее значение счетчика производительности Avg. Disk sec/Write не должно превышать 10 миллисекунд. Максимальное значение счетчика производительности Avg. Disk sec/Write не должно превышать 50 миллисекунд.

Zabbix: perf_counter[LogicalDisk(_Total)Avg. Disk sec/Write], а также важно проследить за нужным диском, например так: perf_counter[LogicalDisk(C:)Avg. Disk sec/Write]

Cредняя длина очереди запросов к диску. Отображает количество запросов к диску, ожидающих обработки в течении определенного интервала времени. Нормальным считается очередь не больше 2 для одиночного диска. Если в очереди больше двух запросов, то возможно диск перегружен и не успевает обрабатывать поступающие запросы. Уточнить, с какими именно операциями не справляется диск, можно с помощью счетчиков Avg. Disk Read Queue Length (очередь запросов на чтение) и Avg. Disk Wright Queue Length (очередь запросов на запись).
Значение Avg. Disk Queue Length не измеряется, а рассчитывается по закону Литтла из математической теории очередей. Согласно этому закону, количество запросов, ожидающих обработки, в среднем равняется частоте поступления запросов, умноженной на время обработки запроса. Т.е. в нашем случае Avg. Disk Queue Length = (Disk Transfers/sec) * (Avg. Disk sec/Transfer).

Avg. Disk Queue Length приводится как один из основных счетчиков для определения загруженности дисковой подсистемы, однако для его адекватной оценки необходимо точно представлять физическую структуру системы хранения. К примеру, для одиночного жесткого диска критическим считается значение больше 2, а если диск располагается на RA >
Zabbix: perf_counter[LogicalDisk(_Total)Avg. Disk Queue Length], а также важно проследить за нужным диском, например так: perf_counter[LogicalDisk(C:)Avg. Disk Queue Length]

Memory

    Pages/sec
    Показывает число страниц, которые SQL Server считал с диска или записал на диск для того, чтобы разрешить обращения к страницам памяти, которые не были загружены в оперативную память в момент обращения. Эта величина является суммой величин Pages Input/sec и Pages Output/sec, а также учитывает страничный обмен (подкачку/свопинг) системной кэш-памяти для доступа к файлам данных приложений. Кроме того, сюда включается подкачка не кэшированных файлов, непосредственно отображаемых в память. Это основной счетчик, за которым следует следить в том случае, если наблюдается большая нагрузка на использование памяти и связанный с этим избыточный страничный обмен. Этот счётчик характеризует величину свопинга и его нормальное (не пиковое) значение должно быть близко к нолю. Увеличение свопинга говорит о необходимости наращивания ОЗУ или уменьшения числа исполняемых на сервере прикладных программ.
Читайте также:  Световое давление испытываемое 1 м зеркальной поверхности

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

Zabbix: perf_counter[MemoryPage Faults/sec]
Пример триггера:
<НАЗВАНИЕ_УЗЛА:perf_counter[MemoryPage Faults/sec].min(5m)>>1000, уровень-информация
Available Bytes

Отслеживает количество доступной памяти в байтах для выполнения различных процессов. Низкие показатели означают нехватку памяти. Решение — увеличить память. Этот счётчик в большинстве случаев должен быть постоянно выше 5000 КВ.
Есть смысл выставлять порог для Available Mbytes вручную из соображений:

•50% свободной памяти доступно = Отлично
•25% доступно памяти = Требует внимания
•10% свободно = Возможны проблемы
•Меньше 5% доступно памяти= Критично для скорости, нужно вмешиваться.
Zabbix: perf_counter[MemoryAvailable Bytes]

Processor (Total): % Processor Time
Этот счетчик показывает процентное отношение времени, которое процессор был занят выполнением операций для не простаивающих потоков (non-Idle thread). Эту величину можно рассматривать как долю времени, приходящегося на выполнение полезной работы. Каждый процессор может быть назначен простаивающему потоку, который потребляет непродуктивные циклы процессора, не используемые другими потоками. Для этого счётчика характерны непродолжительные пики, которые могут достигать 100 процентов. Однако, если наблюдаются продолжительные периоды, когда утилизация процессора выше 80 процентов, то система будет более эффективной при использовании большего числа процессоров.

Zabbix: perf_counter[Processor(_Total)\% Processor Time], здесь же может иметь место по ядрам выводить
Пример триггера:
<НАЗВАНИЕ_УЗЛА:perf_counter[Processor(_Total)\% Processor Time].min(5m)>>80, уровень-информация

  • Network Interface (*): % Bytes Total/sec
    Общее количество переданных и полученных байт за секунду по всем интерфейсам. Это пропускная способность интерфейса (в байтах). Необходимо сравнить значение этого счётчика с максимальной пропускной способностью сетевой платы. Вообще, этот счётчик должен показать не более 50% утилизации пропускной способности сетевого адаптера.
    Zabbix: perf_counter[Network Interface(*)Bytes Sent/sec]
  • MS SQL Server: Access Methods
    Объект Access Methods (Методы доступа) в SQL Server предоставляет счетчики, помогающие следить за доступом к логическим данным в рамках базы данных. Физический доступ к страницам базы данных на диске контролируется при помощи счетчиков диспетчера буферов. Наблюдение за методами доступа к данным в базе данных помогает определить, можно ли увеличить производительность запросов путем добавления или изменения индексов, добавления или перемещения секций, добавления файлов или групп файлов, дефрагментации индексов или изменения текста запросов. Кроме того, при помощи счетчиков объекта Access Methods можно следить за размером данных, индексов и свободного пространства в базе данных, контролируя объем и фрагментацию для каждого экземпляра сервера. Чрезмерная фрагментация индексов может значительно снизить производительность.
    1. Page Splits/sec
      Количество разбиений страниц в секунду, выполненных в результате переполнения страниц индекса. Большое значение этого показателя означает, что при выполнении операций вставки и изменения данных SQL Server приходится выполнять большое количество ресурсоемких операций по разбиению страниц и переносу части существующей страницы на новое место. Таких операций по возможности следует избегать. Проблему можно попытаться решить двумя способами:
      — создать кластерный индекс для столбцов с автоприращением. В этом случае новые записи не будут помещаться внутрь страниц, уже занятых данными, а будут последовательно занимать новые страницы;
      — перестроить индексы, увеличив значение параметра Fillfactor. Этот параметр позволяет зарезервировать в страницах индексов свободное место, которое будет использоваться для размещения новых данных, без необходимости производить операции разбиения страниц.
      Zabbix: perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Access MethodsPage Splits/sec",30]
      Пример триггера: <НАЗВАНИЕ_УЗЛА:perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Access MethodsPage Splits/sec",30].last()>><НАЗВАНИЕ_УЗЛА:perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:SQL StatisticsBatch Requests/sec",30].last()>/5, уровень-информация
    2. Full Scans/sec
      Количество неограниченных операций полного сканирования в секунду. К таким операциям относятся сканирование основной таблицы и полное сканирование индекса. Стабильное повышение этого показателя может свидетельствовать о деградации системы (нехватка нужных индексов, их сильная фрагментация, неиспользование оптимизатором существующих индексов, наличие неиспользуемых индексов). Однако, стоит отметить, что полное сканирование в небольших таблицах невсегда плохо, т к если удается всю таблицу разместить в ОЗУ, то как раз быстрее будет произвести полное сканирование. Но в большинстве случаев стабильный рост показателя этого счетчика будет говорить о деградации системы. Все это применимо только для OLTP-систем. В OLAP-системах постоянные полные сканирования-это нормально.
      Zabbix: perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Access MethodsFull Scans/sec",30]
    3. MS SQL Server: Buffer Manager
      Объект Buffer Manager (диспетчера буферов) предоставляет счетчики, позволяющие наблюдать за тем, как SQL Server использует следующие ресурсы:
      — память для хранения страниц данных;
      — счетчики, служащие для мониторинга физического ввода-вывода, когда SQL Server считывает и записывает страницы баз данных;
      — расширение буферного пула для расширения буферного кэша с использованием быстрой энергонезависимой памяти, например твердотельных накопителей (SSD);
      — мониторинг памяти и счетчиков, используемых SQL Server, помогает получить следующие сведения;
      — существуют ли «узкие места», вызванные недостатком физической памяти. Если часто используемые данные не могут быть сохранены в кэше, SQL Server вынужден считывать их с диска;
      — можно ли повысить эффективность выполнения запросов, увеличив объем памяти или выделив дополнительную память для кэширования данных или хранения внутренних структур SQL Server;
      — насколько часто SQL Server считывает данные с диска. В сравнении с другими операциями, такими как доступ к памяти, физический ввод-вывод выполняется дольше. Уменьшение объема ввода-вывода может повысить производительность выполнения запросов.
      1. Buffer Cache hit radio
        Показывает, насколько полно SQL Server может разместить данные в буфере кэша. Чем выше это значение, тем лучше, т.к. для эффективного обращения SQL сервера к страницам данных, они должны находиться в буфере кэша, и операции физического ввода-вывода (I/O) должны отсутствовать. Если наблюдается устойчивое снижение среднего значения этого счётчика, необходимо рассмотреть возможность добавления ОЗУ. Данный показатель всегда должен быть выше 90% для OLTP-систем и выше 50% для OLAP-систем.
        Zabbix: perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Buffer ManagerBuffer cache hit ratio",30]
        Примеры триггеров: <НАЗВАНИЕ_УЗЛА:perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Buffer ManagerBuffer cache hit ratio",30].last()>=0)
        and (<НАЗВАНИЕ_УЗЛА:perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:General StatisticsProcesses blocked",30].time(0)>>=50000)
        and ( <НАЗВАНИЕ_УЗЛА:perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:General StatisticsProcesses blocked",30].time(0)>=500, уровень-информация
      2. Lock Wait Time (ms)
        Суммарное время ожидания блокировок (в миллисекундах) за последнюю секунду.
        Zabbix: perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)Lock Wait Time (ms)",30]
      3. Lock Waits/sec
        Количество случаев за последнюю секунду, когда потоку приходилось ожидать в связи с запросом блокировки.
        Zabbix: perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)Lock Waits/sec",30]
      4. Lock Timeouts/sec
        Количество повторений, когда не удается получить блокировку путем циклического обращения. Значение параметра конфигурирования SQL Server spin counter определяет количество «оборотов» потока (spins), прежде чем истечет время тайм-аута и поток перейдет в неактивное состояние.
        Zabbix: perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)Lock Timeouts/sec",30]
        Пример триггера: <НАЗВАНИЕ_УЗЛА:perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)Locks(_Total)Lock Timeouts/sec",30].last()>>1000, уровень-информация
      5. Lock Requests/sec
        Количество запросов в секунду указанного типа блокировки.
        Zabbix: perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)Lock Requests/sec",30]
        Пример триггера: <НАЗВАНИЕ_УЗЛА:perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)Lock Requests/sec",30].last()>>500000, уровень-информация
      6. Lock Number of Deadlocks/sec
        Количество запросов блокировки в секунду, приводящих к взаимоблокировке. Наличие взаимоблокировок свидетельствует о неправильно построенных запросах, которые блокируют совместные ресурсы.
        Zabbix: perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Number of Deadlocks/sec",30]
        Пример триггера: <НАЗВАНИЕ_УЗЛА:perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)Number of Deadlocks/sec",30].last()>>1, уровень-высокий
      7. Читайте также:  Aida64 инвентаризация по сети

      8. MS SQL Server: Memory Manager
        Объект Memory Manager (Диспетчер памяти) в Microsoft SQL Server обеспечивает счетчики для контроля использования памяти всего сервера. Контроль над использованием памяти всего сервера для оценки действий пользователя и использования ресурсов может помочь идентифицировать нехватку производительности. Контроль над памятью, используемый экземпляром SQL Server, может помочь определить:
        — существуют ли нехватки в недостаточной физической памяти для хранения в кэше часто используемых данных. Если памяти недостаточно, SQL Server должен получить данные с диска;
        — может ли производительность запроса улучшиться, если будет добавлена память или увеличится объем доступной памяти для кэширования данных или внутренних структур SQL Server.
        1. Memory Grants Outstanding
          Указывает общее число процессов, успешно получивших память рабочей области. При стабильном падении показателя, необходимо увеличить ОЗУ.
          Zabbix: perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Memory ManagerMemory Grants Outstanding",30]
        2. Memory Grants Pending
          Указывает общее число процессов, ожидающих предоставления памяти рабочей памяти. При стабильном росте показателя, необходимо увеличить ОЗУ.
          Zabbix: perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Memory ManagerMemory Grants Pending",30]
        3. MS SQL Server: Statistics
          Объект Statistics (Статистика) в Microsoft SQL Server обеспечивает работу счетчиков для наблюдения компиляции и типов запросов, отправляемых экземпляру SQL Server. Наблюдение за числом компиляций и повторных компиляций запросов и числа пакетов, полученных экземпляром SQL Server, дает представление о том, как быстро SQL Server выполняет запросы пользователей и насколько эффективно их обрабатывает оптимизатор запросов.
          1. Batch Requests/sec
            Число пакетов команд Transact-SQL, полученных за секунду. На эту статистику влияют любые ограничения (ввод-вывод, число пользователей, размер кэша, сложность запросов и т. д.). Высокое число запросов пакетов свидетельствует о высокой пропускной способности.
            Zabbix: perf_counter["MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:SQL StatisticsBatch Requests/sec",30]
          2. Помимо всего выше перечисленного также можно настроить и другие элементы данных (а также и создать триггеры по ним с последующим оповещением).Например:
            1) размер свободного места на диске
            2) размеры БД-файлов данных и журнала лога
            и т. д.
            Однако, все эти показатели не показывают проблему именно запросов в реальном времени.
            Для этого необходимо создавать свои специальные счетчики.
            Из-за соображений конфиденциальности, не буду приводить примеры таких счетчиков. Тем более, что они настраиваются уникально для каждой системы. Но отмечу, что для таких систем как 1С, NAV и CRM специализированные счетчики создать можно совместно с соответствующими разработчиками.
            Приведу пример создания обобщенного показателя, который показывает сколько запросов выполняется и сколько запросов ожидают выполнения (приостановлены или заблокированы) на каждый момент времени.
            Для этого необходимо создать хранимую процедуру:

            Теперь необходимо создать файл с пользовательскими параметрами и расширением .conf (или добавить строчки в существующий такой пользовательский файл, если он был создан ранее) и вставить следующие строки:
            UserParameter=НАЗВАНИЕ_ПАРАМЕТРА_КОЛИЧЕСТВО_ВЫПОЛНЯЕМЫХ_ЗАПРОСОВ,powershell -NoProfile -ExecutionPolicy Bypass -File ПОЛНЫЙ_ПУТЬzabbixconfuserparams.dНАЗВАНИЕ_ФАЙЛА_ДЛЯ_ВЫПОЛНЯЕМЫХ_ЗАПРОСОВ.ps1
            UserParameter=НАЗВАНИЕ_ПАРАМЕТРА_КОЛИЧЕСТВО_ОЖИДАЮЩИХ_ЗАПРОСОВ,powershell -NoProfile -ExecutionPolicy Bypass -File ПОЛНЫЙ_ПУТЬzabbixconfuserparams.dНАЗВАНИЕ_ФАЙЛА_ДЛЯ_ОЖИДАЮЩИХ_ЗАПРОСОВ.ps1
            После этого сохраняем файл .conf и перезапускаем агент Zabbix.
            После этого добавляем в Zabbix новых два элемента (в данном случае названия и ключ совпадают):
            НАЗВАНИЕ_ПАРАМЕТРА_КОЛИЧЕСТВО_ВЫПОЛНЯЕМЫХ_ЗАПРОСОВ
            НАЗВАНИЕ_ПАРАМЕТРА_КОЛИЧЕСТВО_ОЖИДАЮЩИХ_ЗАПРОСОВ
            Теперь можно создавать графики и триггеры на созданные пользовательские элементы данных.

            Если кол-во ожидающих запросов резко возрастает, то следующим запросом можно вывести все выполняющиеся и ожидающие запросы в данный момент времени с детализацией от куда и под каким логином выполняется запрос, текст и план запроса, а также прочие детали:

            Результат

            В данной статье был рассмотрен пример счетчиков производительности (элементы данных) в Zabbix. Данный подход позволяет уведомлять администраторов о разных проблемах в реальном времени или через какое-то определенное время. Таким образом, данный подход позволяет минимизировать в будущем наступления критической проблемы и остановки работы СУБД и сервера, что в свою очередь защищает производство от остановки рабочих процессов.
            Предыдущая статья: Регламентные работы с базой данных информационной системы 24×7 в MS SQL Server

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

            Для наблюдения за дисками можно выбрать два типа объектов:

            • Physical Disk — в качестве объекта мониторинга выступает то, что система определяет как физическое устройство. Это может быть как отдельный жесткий диск, так и несколько дисков, объединенных в RAID-массив. Если физический диск разбит на логические разделы (тома), то счетчики выдают суммарное значение для всех томов, находящихся на диске.
            • Logical Disk — здесь в качестве объекта мониторинга выступает логический раздел. Perfmon идентифицирует тома по букве диска или точке монтирования (если том примонтирован как папка). Если физический диск разбит на несколько томов, то счетчики будут выдавать значения для каждого выбранного тома отдельно. Возможна и обратная ситуация, когда при использовании динамических дисков том может быть растянут на несколько физических устройств, тогда счетчики покажут значения сразу для всех физических дисков, входящих в состав логического.

            Читайте также:  Монитор acer нет изображения

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

            Приступим к описанию счетчиков.

            %Disk Time

            Показывает процент общей загруженности диска. Представляет из себя сумму значений счетчиков %Disk Read Time (процент загруженности диска операциями чтения) и %Disk Write Time (процент загруженности диска операциями записи). Теоретически его значения должны быть в диапазоне от 0 до 100%, однако это верно только для одиночного диска. При использовании RAID-массивов часто можно увидеть значения этого счетчика больше 100%.

            %Idle Time

            Показывает время простоя диска, т.е. время, в течении которого диск оставался в состоянии покоя, не обрабатывая запросы чтениязаписи. В отличии от %Disk Time лежит строго в диапазоне от 100% (полный покой) до 0 (полная загрузка).

            Disk Transfers/sec

            Основной показатель интенсивности запросов к диску. Показывает общее количество операций вводавывода, обработанных (завершенных) диском в течении 1 секунды (Input/Output Operations Per Second, IOPS). Этот счетчик позволяет примерно оценить, насколько нагрузка на диски близка к предельной. Для дисков, работающих в нормальном режиме, можно ориентироваться на следующие значения: 80-160 IOPS для одиночного жесткого диска SATA или SAS, 1800-5000 IOPS для одиночного SSD диска. Для уточнения можно воспользоваться счетчиками Disk Reads/sec (количество обработанных за секунду запросов на чтение) и Disk Writes/sec (количество обработанных за секунду запросов на запись).

            Avg. Disk sec/Transfer

            Среднее время в секундах, требуемое для выполнения диском одной операции чтения или записи. Складывается из значений Avg. Disk sec/Read (время на выполнение операции чтения) и Avg. Disk sec/Write (время на выполнение операции записи). Для высоконагруженых систем, таких как сервера БД, значение Avg. Disk sec/Transfer не должно превышать 0,1, для рядовых серверов допустимо значение 0,25.

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

            Avg. Disk Queue Length

            Cредняя длина очереди запросов к диску. Отображает количество запросов к диску, ожидающих обработки в течении определенного интервала времени. Нормальным считается очередь не больше 2 для одиночного диска. Если в очереди больше двух запросов, то возможно диск перегружен и не успевает обрабатывать поступающие запросы. Уточнить, с какими именно операциями не справляется диск, можно с помощью счетчиков Avg. Disk Read Queue Length (очередь запросов на чтение) и Avg. Disk Wright Queue Length (очередь запросов на запись).

            Значение Avg. Disk Queue Length не измеряется, а рассчитывается по закону Литтла из математической теории очередей. Согласно этому закону, количество запросов, ожидающих обработки, в среднем равняется частоте поступления запросов, умноженной на время обработки запроса. Т.е. в нашем случае Avg. Disk Queue Length = (Disk Transfers/sec) * (Avg. Disk sec/Transfer).

            Avg. Disk Queue Length приводится как один из основных счетчиков для определения загруженности дисковой подсистемы, однако для его адекватной оценки необходимо точно представлять физическую структуру системы хранения. К примеру, для одиночного жесткого диска критическим считается значение больше 2, а если диск располагается на RA >

            Current Disk Queue Length

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

            Disk Bytes/sec

            Средняя скорость обмена данными с диском, или скорость чтениязаписи. Показывает общее количество байт, отправленных на диск (запись) и с диска (чтение) в течении одной секунды, тем самым позволяя оценить пропускную способность дисковой системы. Складывается из значений Disk Read Bytes/sec (скорость чтения) и Disk Write Bytes/sec (скорость записи). Предельные значения сильно зависят от типа диска: к примеру для одиночного жесткого диска максимальная скорость чтениязаписи лежит в пределах 160-250Mb/s, для одиночного SSD — около 550-600Mb/s.

            Avg. Disk Bytes/Transfer

            Среднее количество байт, передаваемое при выполнении одной операции чтениязаписи. Чем больше размер передаваемых блоков, тем меньше нагрузка на диск. При нормальной работе этот параметр должен быть больше 20Kb, значения меньше говорят о большом количестве мелких запросов, т.е. о неэффективном использовании дисковой системы. Более точную информацию можно получить из значений счетчиков Avg. Disk Bytes/Read (количество байт, передаваемое при выполнении одной операции чтения) и Avg. Disk Bytes/Write (количество байт, передаваемое при выполнении одной операции записи).

            Split IO/Sec

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

            И только для объектов Logical Disk есть еще два счетчика, позволяющие определить наличие свободного места на диске.

            %Free Space

            Объем свободного дискового пространства на выбранном логическом диске, в процентах.

            Free Megabytes

            Объем свободного пространства на логическом диске, в мегабайтах.

            Заключение

            Для того, чтобы адекватно оценить полученные данные, необходимо точно представлять физическую структуру системы хранения. В первую очередь важен тип используемых дисков (HDD, SSD), интерфейс (SATA, SAS, FC, PCIe), скорость вращения HDD (7200, 10k, 15k). При использовании RAID-массивов нужно знать тип массива (0, 1, 5, 10 и т.д.) и количество дисков в массиве.

            И еще, при оценке производительности дисковой подсистемы обязательно надо учитывать тип нагрузки, создаваемой приложениями. В идеале есть два типа дисковых нагрузок:

            1. Большое количество случайных операций чтениязаписи, данные обрабатываются небольшими блоками. Этот тип нагрузки характерен для серверов баз данных. При таком типе нагрузки наиболее важным параметром является количество IOPS-ов. Основные счетчики — Disk Transfers/sec, Avg. Disk sec/Transfer и конечно Avg. Disk Queue Length.

            2. Последовательное чтениезапись больших блоков данных. Такая нагрузка характерна, к примеру, для серверов потокового видео. В этом случае наиболее важна пропускная способность дисковой системы, которую показывает Disk Bytes/sec.

            Оцените статью
            Добавить комментарий

            Adblock
            detector