Длина очереди диска что это
Использование Монитора ресурсов: дисковая подсистема
Для удобства рассмотрения мы будем использовать скриншот Монитора ресурсов (рис. A), запущенного на производственном сервере под управлением Windows Server 2008 R2. На этом сервере установлен Exchange Server 2010 со всеми ролями, поэтому он нуждается в большой дисковой подсистеме с приемлемой производительностью. (Примечание: как и все другие наши серверы, этот работает в виртуальной машине на базе VMware vSphere 4.1.)
Начнем с общего обзора консоли. Большую часть окна занимают статистические показатели, о которых я подробно расскажу ниже. Справа расположены графики, каждый из которых представляет один из важных показателей производительности дисковой подсистемы.
Ниже я подробно рассмотрю каждый показатель. Я не буду повторяться: если показатель присутствует в нескольких местах, я упомяну его только в первый раз.
Процессы с дисковой активностью
В разделе «Процессы с дисковой активностью» (Processes With Disk Activity) перечислены все запущенные процессы, использующие ресурсы хранения. В списке показано имя исполняемого файла и ряд связанных с ним статистических показателей.
• «Образ» (Image) – имя исполняемого файла. Это имя процесса, активно использующего диск.
• «ИД процесса» (PID) – идентификатор процесса. Может пригодиться для управления процессами с использованием других утилит или для поиска процессов в Диспетчере задач (Task Manager).
• «Чтение (байт/с)» (Read (B/sec)) – среднее количество прочитанных процессом байтов в секунду за последнюю минуту.
• «Запись (байт/с)» (Write (B/sec)) – среднее количество записанных процессом байтов в секунду за последнюю минуту.
• «Всего (байт/с)» (Total (B/sec)) – среднее количество использованных байтов в секунду за последнюю минуту.
Информация, которая приводится в этом разделе, не особенно актуальна для диагностики – она лишь позволяет выяснить, какие процессы потребляют больше всего ресурсов диска. На рис. A, например, можно заметить, что больше всего операций чтения с диска выполняет процесс с именем «DPMRA.exe».
В разделе «Работа диска» (Disk Activity) собраны более полезные для диагностики сведения. Самый ценный показатель – пожалуй, время ответа, поскольку его можно оценить, даже не зная исходной конфигурации дисковой подсистемы.
Справа от названия раздела расположены два небольших индикатора. Зеленый показывает текущий дисковый ввод/вывод (Disk I/O), то есть, количество передаваемых в данный момент данных), а синий – максимум активного времени дисковой подсистемы (Highest Active Time).
• «Файл» (File) – имя файла, используемого процессом. Здесь указывается полный путь к файлу, чтобы его легче было найти.
• «Приоритет ввода/вывода» (I/O Priority) – приоритет операций ввода/вывода.
• «Время ответа (мс)» (Response Time (ms)) – время отклика диска в миллисекундах. Как правило, чем ниже этот показатель, тем лучше. В целом, время ответа менее 10 мс свидетельствует о хорошей производительности. Не страшно, если этот показатель время от времени превышает отметку в 10 мс, но если системе постоянно приходится дожидаться ответа дисковой подсистемы более 20 мс, это может свидетельствовать о наличии проблем, а конечные пользователи в таком случае заметят ощутимое снижение быстродействия. Если время ответа достигает 50 мс и выше, значит, проблема действительно серьезная. На рис. A, как видите, время ответа составляет 5-6 мс, так что дисковая подсистема функционирует исправно, если судить по этому показателю.
В разделе «Запоминающие устройства» (Storage) содержатся следующие сведения:
• «Логический диск» (Logical Disk) – буква диска.
• «Физический диск» (Physical disk) – выбранный для мониторинга физический диск.
• «Активное время (%)» (Active Time (%)) – сколько времени диск проводит, активно обслуживая запросы, в противовес времени простоя. Если активность диска постоянно очень высока (скажем, более 80%), это может указывать на наличие потенциальных проблем, связанных с ресурсами хранения. Если пользователи жалуются на низкое быстродействие, а активное время постоянно составляет 100%, возможно, необходимо увеличить объем дисковой подсистемы или установить более производительные накопители.
• «Свободно (МБ)» (Available Space (MB)) – количество свободного пространства в текущем томе диска.
• «Всего (МБ)» (Total Space (MB)) – общий объем тома.
• «Длина очереди диска» (Disk Queue Length) – средняя длина очереди диска. Длина очереди показывает количество ожидающих выполнения запросов (на чтение и запись) в любой момент времени. Если этот показатель довольно высок, это может свидетельствовать о том, что скорость вращения диска недостаточна для удовлетворения запросов приложений или что дисковая подсистема имеет слишком низкую производительность и не справляется с запросами. Однако чтобы оценить, насколько высок показатель, необходимо хорошо понимать, как создается базовый том в SAN. Каждый диск, из которых складывается базовый том, предоставляет дополнительные ресурсы, которые учитываются при расчете длины очереди (проще говоря, чем больше дисков, тем выше будет длина очереди).
Уровень RAID и размер страйпа тоже влияют на длину очереди, что дополнительно усложняет задачу. Однако если компьютер оснащен всего одним диском, а длина очереди постоянно превышает 2, система нуждается в дополнительных ресурсах хранения. Длина очереди более 5 свидетельствует о наличии серьезных проблем. Если вам известно, из скольких дисков состоит базовый том, умножьте количество дисков на 2, чтобы очень грубо, приблизительно, прикинуть максимально допустимую длину очереди. К примеру, если в системе десять дисков, а длина очереди равна 18, значит, все в порядке.
Графики – очень полезный инструмент. В верхнем графике показана скорость обмена данными между диском и операционной системой за последнюю минуту. Зеленая кривая показывает текущий суммарный ввод/вывод, а синяя – активное время диска за этот период. На остальных графиках показана длина очереди для каждого диска в системе.
На сервере Exchange, который показан в моем примере, используется четыре диска (тома SAN). С учетом структуры базовых томов SAN в этом массиве, никаких проблем, связанных с длиной очереди, не возникает.
До встречи во второй части
Автор: Scott Lowe
Перевод SVET
Оцените статью: Голосов
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Как видим за один и тот же промежуток времени определенная область диска сделает поворот на один и тот же угол, если мы обозначим эту область в виде сектора, то окажется что в него попадет пять секторов с внешней дорожки и только три с внутренней. Следовательно за данный промежуток времени магнитная головка считает с внешнего цилиндра большее количество информации, чем с внутреннего. На практике это проявляется в том, что график скорости чтения любого диска представляет собой снижающуюся кривую.
Начальные сектора и цилиндры всегда располагаются с внешней стороны, обеспечивая максимальную скорость обмена данными, поэтому рекомендуется размещать системный раздел именно в начале диска.
Здесь будет не лишним вспомнить о таком параметре как плотность записи, которая выражается в площади необходимой для записи 1 бита данных. Чем выше этот параметр, тем больше данных может вместить одна пластина и тем выше скорость линейного обмена данными. Этим объясняются более высокие скоростные характеристики современных винчестеров, хотя технически они могут ничем не отличаться от более старых моделей. Рисунок ниже иллюстрирует данную ситуацию. Как несложно заметить, при более высокой плотности записи за один и тот-же промежуток времени, при той же самой скорости вращения будет считано/записано большее количество данных
Теперь разберем прямо противоположную ситуацию, нам требуется считать большое количество небольших файлов случайным образом разбросанных по всему диску. В этом случае количество операций ввода-вывода будет велико, а скорость обмена данными низка. Основное время будет занимать ожидание доступа к следующему блоку данных, которое зависит от времени позиционирования головки и задержки из-за вращения диска. Простой пример: если после 100 сектора поступит команда прочитать 98, то придется ждать полный оборот диска, пока появится возможность прочитать данный сектор. Сюда же следует добавить время, которое требуется чтобы физически прочитать нужное количество секторов. Совокупность этих параметров составит время случайного доступа, которое имеет очень большое влияние на производительность винчестера.
Следует отметить, что для ОС и многих серверных задач (СУБД, виртуализация и т.п.) характерен именно случайный доступ с размером блока в 4 Кб (размер кластера), при этом основным показателем производительности будет не скорость линейного обмена данными (MBPS), а максимальное количество операций ввода-вывода в секунду (IOPS). Чем выше этот параметр, тем большее количество данных может быть считано в единицу времени.
Однако количество операций ввода-вывода не может расти бесконечно, это значение очень жестко ограничено сверху физическими показателями винчестера, а именно временем случайного доступа.
А теперь поговорим о фрагментации, суть этого явления общеизвестна, мы же посмотрим на него сквозь призму производительности. Для крупных файлов и линейных нагрузок фрагментация способна значительно снизить производительность, так как последовательный доступ превратится в случайный, что вызовет резкое снижение скорости доступа и также резко увеличит количество операций ввода-вывода.
При случайном характере доступа фрагментация не играет особой роли, так как нет никакой разницы в каком именно месте диска находится тот или иной блок данных.
Появление дисков с более крупным 4 Кб сектором стало причиной появления еще одной проблемы: выравнивания файловой системы относительно секторов диска. Здесь возможны два варианта: если файловая система выровнена, то каждому кластеру соответствует сектор, если не выровнена, то каждому кластеру соответствует два смежных сектора. А так как сектор это минимальная адресуемая единица, то для считывания одного кластера потребуется считать не один, а два сектора, что негативно скажется на производительности, особенно при случайном доступе.
При случайном доступе скорость будет минимальна, так как размер пакета данных очень мал (в худшем случае кластер) и производительность упрется в максимально доступное количество IOPS. Для современных массовых дисков это значение равно около 70 IOPS, нетрудно посчитать, что при случайном доступе с размером пакета в 4 Кб мы получим максимальную скорость не более 0,28 MBPS.
Непонимание этого момента часто приводит к тому, что дисковая подсистема оказывается бутылочным горлышком, которое тормозит работу всей системы. Так, выбирая между двумя дисками с максимальной линейной скоростью в 120 и 150 MBPS, многие не задумываясь выберут второй, не посмотрев на то, что первый диск обеспечивает 70 IOPS, а второй всего 50 IOPS (вполне характерная ситуация для экономичных серий), а потом будут сильно удивляться тому, почему «более быстрый» диск сильно тормозит.
Что будет, если количества IOPS диска окажется недостаточно чтобы обработать все запросы? Возникнет очередь дисковых запросов. На практике все несколько сложнее и очередь диска будет возникать даже в том случае, когда IOPS достаточно. Это связано с тем, что различные процессы, обращающиеся к диску, имеют разный приоритет, а также то, что операции записи всегда имеют приоритет над операциями чтения. Для оценки ситуации существует параметр длина очереди диска, значение которого не должно превышать (по рекомендациям Microsoft)
В любом случае постоянная большая длина очереди говорит о том, что системе недостаточно текущего значения IOPS. Увеличение очереди диска на уже работающих системах говорит либо о увеличении нагрузки, либо о выходе из строя или износе жестких дисков. В любом случае следует задуматься об апгрейде дисковой подсистемы.
На этом мы закончим наш сегодняшний материал, приведенной информации должно быть достаточно для понимания физических процессов, происходящих при работе жесткого диска и того, как они влияют на производительность. В следующих статьях мы рассмотрим, как правильно определить, какое количество IOPS нужно в зависимости от характера нагрузки и как правильно спроектировать дисковую подсистему, чтобы она удовлетворяла предъявляемым требованиям.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Счетчики производительности для дисковой подсистемы
Дисковая подсистема довольно часто становится узким местом в работе приложений, поэтому очень важно уметь диагностировать проблемы с дисками. Одним из основных инструментов для наблюдения за производительностью дисковой подсистемы являются счетчики производительности, о которых и пойдет сегодня речь.
Для наблюдения за дисками можно выбрать два типа объектов:
• Physical Disk — в качестве объекта мониторинга выступает то, что система определяет как физическое устройство. Это может быть как отдельный жесткий диск, так и несколько дисков, объединенных в RAID-массив. Если физический диск разбит на логические разделы (тома), то счетчики выдают суммарное значение для всех томов, находящихся на диске.
• Logical Disk — здесь в качестве объекта мониторинга выступает логический раздел. Perfmon идентифицирует тома по букве диска или точке монтирования (если том примонтирован как папка). Если физический диск разбит на несколько томов, то счетчики будут выдавать значения для каждого выбранного тома отдельно. Возможна и обратная ситуация, когда при использовании динамических дисков том может быть растянут на несколько физических устройств, тогда счетчики покажут значения сразу для всех физических дисков, входящих в состав логического.
Набор счетчиков для физического и логического диска практически идентичен, за небольшим исключением, о котором чуть позже.
Приступим к описанию счетчиков.
%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, а если диск располагается на RAID-массиве из 4-х дисков, то волноваться стоит при значении больше 4*2=8.
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.
Длина очереди диска что это
Анализ загрузки диска средствами Системного монитора, Процент загрузки диска (% Disk Time), Текущая длина очереди диска (Current Disk Queue Length), % Активности диска при чтении (% Disk Read Time) и % Активности диска при записи (% Disk Write Time)
Третья подсистема, мониторинг которой имеет смысл производить для сервера SQLServer 2005, — это дисковая подсистема. Она считается главной с точки зрения производительности для задач DataWarehousing, т. е. для хранилищ данных. Объяснение достаточно простое — по сравнению с обычными системами OLTP, наиболее распространенная операция в системах DataWarehouse — это полное сканирование всей таблицы. Операции изменения данных в системах DataWarehouse также очень редки. Поэтому роль кэша в них, в отличие от систем OLTP, невелика, а вот требования к дискам предъявляются намного серьезнее.
По опыту практической работы можно отметить, что и для систем OLTP именно увеличение скорости работы дисковой подсистемы дает наибольший эффект.
Главный счетчик для дисковой подсистемы — Процент загрузки диска (% Disk Time) для объекта Логический диск (Logical Disk) или Физический диск (Physical Disk). Объект Логический диск удобнее, поскольку информация показывается по разделам, но он почему-то не всегда доступен. Пороговое значение для этого счетчика формулируется так: в течение продолжительного промежутка времени значение не должно приближаться к 100%. Если дисковая подсистема постоянно загружена почти на 100%, то очевидно, что она является узким местом системы и ее надо заменить. Если вы не уверены, что за активность дисковой подсистемы ответственен именно SQLServer, имеет смысл проверить значение счетчика Обмен данными, байт в секунду (I/O bytes/sec) для объекта Процесс (сравнить это значение для экземпляра SQLServer и объекта _Total).
Отметим лишь одну особенность счетчиков Процент загрузки диска для объектов Логический диск и Физический диск: они не всегда показывают точные значения при использовании RAID-массивов.
Форум Тринити
Так, в практической работе иногда можно увидеть значение этого параметра более 100%. Однако больших проблем это не создает: при нормальной нагрузке на дисковую подсистему среднее значение этого счетчика должно быть существенно ниже 50%.
Еще один счетчик, который можно использовать для проверки, — Текущая длина очереди диска (Current Disk Queue Length) для тех же объектов Физический диск и Логический диск.
Этот параметр показывает, сколько запросов стоит в очереди на обработку дисковой подсистемы. Его значение на протяжении длительного промежутка времени не должно превышать 2 для одного диска (если, например, в RAID-массиве находится 10 дисков, то среднее значение этого счетчика не должно быть больше 20).
Если вы не уверены, чем именно вызвана загрузка диска — операциями чтения или записи, то определить это помогут счетчики % Активности диска при чтении (% Disk Read Time) и % Активности диска при записи (% Disk Write Time) для объектов Физический диск и Логический диск.
Если узким местом системы является диск (а это случается очень часто), то вариантов решения может быть несколько. Самое простое и очевидное из них — обновить дисковую подсистему, например, купив новый RAID-массив. Однако большой выигрыш могут дать и другие, более дешевые варианты решения.
Очень часто лишние операции с диском возникают из-за проблем с индексами. Про оптимизацию системы индексов будет рассказываться далее в разд. 11.5.5.
Большое влияние на производительность и отказоустойчивость работы SQLServer оказывает распределение файлов по дискам сервера.
Какое нормальное значение счетчика «Средняя длина очереди диска»?
Уже описывал свою конфигурацию: сервер Win2K8 подключен к СХД Xyratex c 12-мя дисками SATA через FC-адаптеры 4Gb\s. На данной полке создано два RAID-5 массива по 5 дисков в каждом, 2 — в глобальном спейре.
Для примера попробуем добавить счетчики производительности. Для начала удалите все используемые в данный момент счетчики. Для этого нужно выделить счетчик в области счетчиков и нажать клавишу Delete. После этого вызовите контекстное меню в любой из областей системного монитора и выберите команду Добавить счетчики. Это приведет к отображению диалогового окна, приведенного на рис. 11.2.
Рис. 11.2. Окно добавления счетчиков
С помощью данного окна можно определить, счетчики какого компьютера будут подключаться к консоли (локального или любого другого, подключенного к сети), определить устройство (список Объект), за работой которого вы будете следить, а также определить сами счетчики (переключатель Выбрать счетчики из списка) параметров работы устройства, которые будут отслеживаться. После выбора счетчика в правом окне можно выбрать экземпляр устройства, работа которого будет отслеживаться. На рис. 11.2 отображено только два экземпляра устройства — _Total и 0. Экземпляр 0 определяет первый процессор, установленный в системе, а экземпляр _Total определяет слежение за всеми процессорами, установленными на компьютере (при этом будет выводиться среднее арифметическое данных по работе процессоров). Если на компьютере установлен только один процессор, то экземпляр _Total эквивалентен экземпляру 0, но если бы компьютер содержал большее количество установленных процессоров, то присутствовали бы и другие экземпляры устройств: 1 — для второго процессора, 2 — для третьего процессора и т.д.
ПРИМЕЧАНИЕ
Если значение DWORD-параметра Disable Performance Counters, расположенного в ветви системного реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib, будет равно 1, то будет запрещено добавление счетчиков, а также работа с ActiveX-объектом Системный монитор. Если значение данного параметра будет равно 1, то список счетчиков просто-напросто будет пуст. Аналогичного результата можно добиться, если присвоить DWORD-параметру Updating той же ветви реестра значение, равное 0.
ВНИМАНИЕ
Название экземпляра Total можно изменить на любое другое. Для этого применяется параметр строкового типа TotalInstanceName, расположенный в ветви реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Perflib. При этом следует учитывать, что все счетчики, загруженные до изменения значения параметра TotalInstanceName, работать не будут.
Если просмотреть список объектов, за которыми можно следить, а также количество различных счетчиков, реализованных для них, можно ужаснуться. Что же из этого многообразия выбрать? Частично решить этот вопрос вам поможет кнопка Объяснение, после выбора счетчика и нажатия которой перед вами отобразится диалоговое окно с описанием того, за чем же следит данный счетчик. Вам также могут помочь советы профессионалов, которые предлагают следить за следующими компонентами (если необходимо определить общий уровень производительности компьютера или устройства, которые пора улучшить) компьютера: Процессор, Память, Система и Физический диск. Вкратце рассмотрим наиболее интересные счетчики данных устройств.
ПРИМЕЧАНИЕ
В любом случае, здесь не будут рассмотрены все объекты, счетчики которых можно использовать, так как количество объектов на различных компьютерах может быть разное. Это связано с тем, что любая служба может добавить свои собственные счетчики. Для этого достаточно в параметре строкового типа Library указать библиотеку, содержащую функции работы с новыми счетчиками. Параметр расположен в разделе Performance ветви реестра, хранящей сведения о данной службе (на страницах книги уже несколько раз упоминалось, что настройки служб находятся в отдельных разделах ветви реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services).
Повышенная нагрузка на диски сервера баз данных SQL Server
Можно также удалить возможность работы со счетчиками данного объекта, просто удалив раздел Performance (или переименовав его). Но можно поступить и намного проще — просто запретить работу счетчиков данного объекта. Для этого необходимо в разделе Performance данной службы создать DWORD-параметр Disable Performance Counters и присвоить ему значение 1.
Основные параметры раздела Performance неинтересны и содержат названия функций библиотеки для работы со счетчиками.
Для процессора это следующие счетчики.
% загруженности процессора — в зависимости от экземпляра устройства определяет процент загруженности конкретного процессора или всех процессоров, установленных на компьютере. Аналогичную информацию можно просмотреть и в Диспетчере задач Windows (на вкладке Быстродействие). Если процессор постоянно загружен на 70-90%, значит, пора покупать более мощный процессор.
% времени прерываний — в зависимости от экземпляра устройства определяет процент времени загруженности конкретного процессора или всех процессоров, установленных на компьютере, в течение которого процессор обрабатывает различные аппаратные прерывания. Если показания данного счетчика колеблются в пределах 25-35%, стоит также подумать о более мощном процессоре.
Для памяти это следующие счетчики.
Обмен страниц в секунду — определяет количество страниц, считываемых или записываемых на диск в течение одной секунды. Как правило, страницы записываются на диск в том случае, если оперативная память компьютера исчерпана и системе приходится использовать файл подкачки. Иными словами, чем меньше показания данного счетчика, тем лучше. В случае большого объема обмена страниц (имеется в виду обмен страницами в течение всего сеанса работы пользователя, а не временный обмен, который может быть ассоциирован записью информации на диск (а следовательно, не отображает реальную картину загруженности памяти)) рекомендуется купить дополнительную планку оперативной памяти.
Ошибок страницы в секунду — указывает количество ошибок доступа к оперативной памяти, возникающих при отсутствии в оперативной памяти необходимых данных. Как правило, после выявления ошибки системе приходится обращаться к содержимому жесткого диска за получением необходимой информации и повторного помещения ее в память, что занимает большое количество времени (сравнительно). При показаниях данного счетчика, превышающих значение 5, рекомендуется купить дополнительные планки оперативной памяти.
Доступно байт — определяет количество свободной в данный момент виртуальной памяти. Если показания этого счетчика постоянно колеблются в пределах 10-20 Мбайт, рекомендуется купить дополнительные планки оперативной памяти.
Для физического диска это следующие счетчики.
% активности диска — определяет процент времени, которое жесткий диск тратит на удовлетворение запросов на чтение/запись данных. Если показания данного счетчика долгое время колеблются в районе 80-100%, то необходимо подумать над покупкой более быстрого жесткого диска или дополнительного объема оперативной памяти.
Текущая длина очереди диска — указывает количество запросов на выполнение чтение/запись на диск, ожидающих своего выполнения в очереди. Показания счетчика, отображающие больше двух запросов в очереди, уже считаются поводом покупки дополнительной оперативной памяти или более быстрого жесткого диска.
Для системы это следующий счетчик.
Длина очереди процессора — определяет количество процессов, ожидающих своего выполнения в очереди процессов. Показания счетчика, отображающие больше двух процессов, уже считаются поводом покупки более производительного процессора.
ПРИМЕЧАНИЕ
Названия счетчиков, а также описания их работы на разных компьютерах могут отличаться. Это связано с тем, что сведения о названиях счетчиков и их описания хранятся не в файле библиотеки, а непосредственно в реестре. Для их хранения применяются два параметра REG_MULTI_SZ-типа ветви реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\019 (для англоязычной версии операционной системы используется конечный подраздел 009). Данная ветвь реестра содержит два параметра — Counter и Help. Первый из них определяет названия счетчиков, а второй — их описание.
Для примера загрузим в консоль следующие счетчики: % времени прерываний и Длина очереди процессора для процессора, Ошибок страниц в секунду для памяти, % активности дисков и Текущая длина очереди диска для физического диска. Чтобы загрузить счетчик, необходимо выделить его и нажать кнопку Добавить. После этого счетчик загрузится, но диалог Добавить счетчики закрыт не будет. После того, как вы добавите все необходимые счетчики, просто нажмите кнопку Закрыть, чтобы перейти к окну консоли.
Вниз 
Счетчик ошибок страницы в Диспетчере задач.
Счетчик ошибок страницы в Диспетчере задач.Что это такое? Как понимать его показания? В справке не описано.
Это нормально, когда у программы он растет со скоростью 2-3 тыс единиц в секунду?
> Что это такое? Как понимать его показания?
Да не паникуй ты так. Это количество страниц, к котрым онадобился доступ когда их не было в оперативной памяти. А если еще точнее, то количество страниц, к котрым онадобился доступ когда их не было в рабочем наборе приложения, что не значит что их не было в оперативе.
> Это нормально, когда у программы он растет со скоростью
> 2-3 тыс единиц в секунду?
Нет 🙂 Пора идти в магазин за оперативой 🙂
> [0] DVM © (01.05.07 13:42)
> Что это такое?
это ошибка доступа к странице памяти, при её возникновении системы выгружает нужную страницу из файла подкачки в ОЗУ.
> Это нормально, когда у программы он растет со скоростью
> 2-3 тыс единиц в секунду?
не очень (хотя тут нужно смотреть конкретную ситуацию), нужно побольше ОЗУ.
> Это нормально, когда у программы он растет со скоростью
> 2-3 тыс единиц в секунду?
Я счас подергал окошко оперы за края, погонял апатчь, до 5 тышь в секунду доходило. Вот же уродский оптимайзер памяти у винды 🙁 Так что пара тысячь в секунду — вполне нормально.
Я вот попытался локализовать в своей программе место, которое более всего увеличивает счетчик — оказалось это место в FastDIB. А именно:
Вот такие преобразования моя программа делает до 200 в секунду.
Если я комментирую преобразование, то счетчик не растет практически.
Памяти 100% достаточно. Ее количество не влияет на этот счетчик. 2Гб ее.
ну если это не дает лишней нагрузки на CPU — можно смело забить, если нагрузку дает — исключить вызов FastDIB2Bitmap.
щас может тупой вопрос задам:)
А так — procedure FastDIB2Bitmap(Src:TFastDIB; var Dst:TBitmap);
?
> ну если это не дает лишней нагрузки на CPU
Не нагрузки не дает абсолютно. Память не растет, никакие ресурсы не уменьшаются.
> [6] antonn © (01.05.07 16:43)
в Делфи идентификатор объекта является указателем на объект )
> в Делфи идентификатор объекта является указателем на объект
> )
:Р
Я вот попытался локализовать в своей программе место, которое более всего увеличивает счетчик — оказалось это место в FastDIB.
По логике, нужно сначала всё освободить, потом присваивать Handle.
Возможно, и освобождать необязательно, во всяком случае в примере Bumpmap сделано так:
procedure TBumpForm.SetThumbnail(Image:TImage; Bmp:TFastDIB);
var
Tmp: TFastDIB;
begin
Tmp:=TFastDIB.Create;
Tmp.SetSize(105,105,Bmp.Bpp);
if Tmp.Bpp=8 then
begin
Tmp.Colors^:=Bmp.Colors^;
Tmp.UpdateColors;
end;
Bilinear(Bmp,Tmp);
Tmp.FreeHandle:=False;
Image.Picture.Bitmap.Handle:=Tmp.Handle;
Tmp.Free;
Image.Refresh;
end;
А вообще, откуда надобность выполнять подобное преобразование 200 раз/c? Может лучше выкинуть TBitmap и выполнять все операции с TFastDIB? А то мне сейчас лень смотреть, но подозреваю, что в TBitmap.SetHandle куда больше действий, чем просто присвоение переменной.
Ещё, имейте в виду, что FastGate — это не оригинальный FastLIB.
Длина очереди диска на SQL сервере.
Автор этого модуля уже допускал ляпы при «улучшении» библиотеки, так что аккуратнее с ним (хотя, строго говоря, и «оригинал» не безгрешен).
> А вообще, откуда надобность выполнять подобное преобразование
> 200 раз/c?
Да есть вот задачи. Видеонаблюдение.
> Может лучше выкинуть TBitmap и выполнять все операции с
> TFastDIB?
Так и планирую сделать, но есть свои грабли и очень много вносить изменений. В принципе FastDIB тут прикручен из-за фантастически быстрой SetSize.
> TBitmap.SetHandle куда больше действий, чем просто присвоение
> переменной.
Да, там намного больше действий.
> Sapersky
Не подскажите, как правильно скопировать один TFastDIB в другой. Не Assign(), а именно копирование? У меня вот какая штука:
Во вторичном потоке происходит декодирование JPEG в TFastDIB. Далее этот FastDIB с сообщением высылается в основной поток и там преобразуется в TBitmap, который и отрисовывается при необходимости в основном потоке по WM_PAINT. Так сделано сейчас. Так вот получается, что и основной поток и вторичный на деле же работают с одним и тем же хэндлом одного и того же битмапа по сути. Ведь FastDIB2Bitmap просто присваивает хэндл. И пока первичный поток отрисовывает его на окне вторичный ведь может и поменять его содержимое. Или я неправ? Так можно делать или надо полностью копироваить битмап в основной поток и там работать с ним?
Хм, а я кажеться понял почему так много ошибок доступа в этом месте. Потому что по Dst фактически заново создаеться, под новый битмап выделяеться память. А менеджер памяти в виндовсе имеет такое замечательное свойство, не выделять память физически, а лишь помечать страницы как зарезервированые. А вот когда уже на новый хэндл уже копируеться изображение со старого, идет непосредственное обращение к страницам, и они выделяются физически (в ОП), а счетчик ошибок доступа мотает. Так что эта строчка имхо — большая дыра в производительности. Попробуй как минимум создавать TBitmap как DIB, как максимум, здесь вобще нужно логику программы переделывать.
> Так вот получается, что и основной поток и вторичный на
> деле же работают с одним и тем же хэндлом одного и того
> же битмапа по сути.
Скорее всего нет. Как я понимаю невозможно преобразовать DDB в DIB не выделив под него второй хэндл.
> Потому что по Dst.Handle:=Src.Handle; Dst фактически заново
> создаеться, под новый битмап выделяеться память
Да, получается, что так.
> Так что эта строчка имхо — большая дыра в производительности.
Может быть, но это далеко не самая тяжелая операция. Декодирование из JPEG во вторичных потоках занимает в тысячи раз больше времени.
> как максимум, здесь вобще нужно логику программы переделывать.
Я вот попробовал переделать на TFastDIB в основном потоке — проблема с ошибками страницы исчезла.
Возникла другая проблема — как мне правильно передать с сообщением переменную типа TFastDIB из вторичного потока в первичный с сообщением и присвоить полченное в основном потоке значение переменной в первичном потоке.
Просто присваиванием очевидно нельзя — возникают сразу утечки GDI ресурсов (вот здесь отличие от TBITMAP).
Не подскажите, как правильно скопировать один TFastDIB в другой. Не Assign(), а именно копирование?
Dst.MakeCopy(Src, True); // делается SetSize и Move
Или можно (при UseGDI = True) установить размер Dst = Src, потом
Src.Draw(Dst.hDC, 0, 0); // фактически BitBlt
удобно тем, что конвертирует битмапы разных форматов, хотя, как правило, не очень качественно. Впрочем, для этого есть FConvert.pas.
И пока первичный поток отрисовывает его на окне вторичный ведь может и поменять его содержимое. Так можно делать или надо полностью копироваить битмап в основной поток и там работать с ним?
Если вторичный поток не изменяет размер битмапа, т.е. не портит указатель/Handle, то, наверное, можно его спокойно рисовать, в крайнем случае нарисуется половина старого, половина нового. Хотя сам не пробовал, не знаю, как функции GDI отнесутся к тому, что кто-то будет писать в используемую ими область памяти. Можно на всякий случай прицепить к битмапу крит. секцию.
Если изменяет — тогда однозначно нужна или синхронизация, или копирование, или и то, и другое.
Просто присваиванием очевидно нельзя — возникают сразу утечки GDI ресурсов (вот здесь отличие от TBITMAP).
Что такое «присваивание»?
Если Assign — возможно, «аффтар» FastGate с ним напортачил в новой версии, пытаясь добиться того же поведения, что и у TBitmap. В оригинале это поведение довольно специфическое — битмап-источник уничтожается.
В общем, лучше «присваивание» делать как Dst := Src с соответствующей синхронизацией или MakeCopy.
> Вот же уродский оптимайзер памяти у винды
Слону, сам понимаешь, пофиг.
> Sapersky (02.05.07 00:38) [16]
Большое спасибо. Метод TFastDib.MakeCopy() действительно то что нужно.
Счетчики ошибок страницы не растут. Утечек тоже нет. Как обстоят дела с производительностью такого решения выясняю.
Форум: «Прочее»;
Поиск по всему сайту: www.delphimaster.net;
Текущий архив: 2007.05.27;
Скачать: [xml.tar.bz2];
Наверх 