??ОПСы и как их измерить.
Зачастую камнем преткновения в анализе производительности системы хранения является замер текущей производительности дисковой подсистемы в IOPS. Без таких данных очень сложно, а порой и невозможно спроектировать адекватную систему хранения для имеющихся данных. Ошибка в оценке необходимого уровня производительности может напрямую исчисляться в тысячах долларов, ушедших в «молоко» при создании системы с «перелетом», и не меньших тысячах долларов потраченных на систему, не выполняющую своих задач в случае «недолета».
Грубой оценкой, но, как правило, достаточной для оценки текущей производительности для базы данных или иной системы, будут показания штатного Performance Monitor (perfmon) из Windows Server.
В запущенном perfmon к имеющимся по умолчанию счетчикам Pages/sec, Avg.Disk Queue и %Processor следует добавить из группы Physical Disk параметры Disk Reads/sec и Disk Writes/sec для нужного диска (в том случае если исследуемая активность принадлежит одному физическому диску, если же нет – те же параметры из группы Logical Disk). Таким диском может быть, например, диск, содержащий базу данных, почтовую базу или любую другую информацию, которую вы намерены перенести на внешнее хранилище. Обратите внимание, что по умолчанию выбирается общая активность всей дисковой подсистемы (_Total).
Очевидно, что сумма значений по Disk Writes/sec и Disk Reads/sec будет приблизительно искомой величиной в IOPS.
Если же мы хотим не просто посмотреть загрузку по IOPS, а провести продолжительный анализ, например для вывявления пиков загрузки и средней величины, то следует воспользоваться так называемыми «журналами счетиков» того же perfmon.
В Performance Logs and Alerts выбрать «Журналы счетчиков» и создать новый журнал с типом данных, например, csv. Добавить в этот журнал уже знакомые нам объекты Disk Reads/sec и Disk Writes/sec и установить желаемый интервал сбора данных. Следует обратить внимание, что включение счетчиков диска немного, но все же снижает общую производительность дисковой подсистемы дополнительной нагрузкой, это имеет смысл учитывать в интерпретации итоговых значений. Кроме того, слишком малый интервал считывания данных хоть и даст более детальный отчет, но, возможно, излишне нагрузит систему и даст черезмерно объемный файл журнала. Считывания раз в 3-5 секунд будет вполне достаточно. Для больших длительностей замеров имеет смысл выбрать большие интервалы, вплоть до минуты. Позаботьтесь о том, чтобы файл отчета не переполнил отведенное ему место, оставьте систему со включенным журналом регистрации и через искомое время вы получите csv-файл, наполненный значениями загрузки вашей дисковой подсистемы. Путем импорта и обработки в Excel вы сможете извлечь желаемые данные, например, средние и пиковые значения загрузки, время пиковых загрузок.
Полезными для анализа параметрами будут также значения следующих объектов:
Disk Bytes Read/sec и Disk Bytes Write/sec – показывают скорость передачи данных с диска. Должны быть близки к величине Disk Reads/sec и Disk Writes/sec помноженных на размер блока файловой системы. Показывают скорость передачи данных с диска. Полезно будет также отметить характер доступа, соотношение операций чтения к записи.
Avg.Disk Queue – показывает величину «очереди запросов» к диску. Значение длительно удерживающееся заметно выше 1,5..2*количество шпинделей дисков показывает перегруженную дисковую подсистему или дисковый контроллер, величина показывает количество запросов стоящих в очередь к диску и ожидающих его освобождения после выполнения предшествующих запросов.
%Processor – постоянная загрузка выше 60%-80% показывает слабость имеющегося процессора для выполняемой задачи, либо наличие какой-то «паразитной» загрузки сервера посторонними задачами.
Pages/sec – показывает количество считываний и записей «страниц» в памяти для того, чтобы добраться до нужной для проводящийся в данный момент операции. Резко отличающиеся величины при работе указывают на недостаток оперативной памяти, приводящей к постоянным операциям «paging»-а, переключения страниц, снижающего быстродействия. Величина должна быть близка к нулю в нормальном, непиковом состоянии.
Большое количество специфичных для себя счетчиков добавляет в perfmon установка MS SQL и MS Exchange. Среди них можно обнаружить объекты, измерение которых может помочь детализировать данные по отдельным базам данных или по определенным операциям.
Полное описание всех средств Performance Monitor в Windows Server далеко выходит за рамки этого обзора поэтому ограничимся вышеприведенным.
??нтересующихся можно отослать к следующим статьям:
«Семь наиболее полезных счетчиков эффективности» (SQL.ru)
http://www.sql.ru/articles/mssql/02111903PerformanceCounters.shtml
«Счётчики производительности SQL Server и Windows»
http://www.sql.ru/articles/mssql/03121001PERF_COUNTERs.shtml
Disk Writes/sec и Disk Reads/sec показывают текущее кол-во операций к дисковой подсистеме. Как узнать максимально возможное? Каким инструментом можно с имитировать такую нагрузку, чтобы узнать предельный порог IOPS для изучаемой нами дисковой подсистемы.
Кривцов М.С.:
> Как узнать максимально возможное?
Максимально возможная величина зависит от множества параметров. От размеров блока операции, например. От характера доступа (последовательно или рандомно), от соотношения чтения/записи. Наконец от объемов кэша и эффективности работы алгоритмов кэширования и количества физических дисков.
Если бы было все так просто и детерминировано, то давно была бы уже написана формула, куда только подставь свои данные и получишь результат.
> Каким инструментом можно с имитировать такую нагрузку, чтобы узнать предельный порог IOPS для изучаемой нами дисковой подсистемы.
Множество таких программ. ??з “синтетических” load generators это dynamo из состава IOmeter, Iozone, SQLIO, и так далее. Посмотрите мои статьи про IOmeter в этом блоге, например.
Помогите разобраться в следующих вопросах, или посоветуйте литературу(статьи).
1) Как между собой связаны Stipped Size при создании тома, Allocation Unit Size при форматировании диска, и Block Size которое генерирует приложение.
2) Есть массив, хранящий видео файлы. Одно приложение, работающее с видео (100% чтения) по данным PerfMon генерирует нагрузку Block Size - 40Kbyte, Read Operation/s - 100, Read MBytes/s ~ 4, Queue Average Lenght/Read - 0.22. При создании на дисковом массиве (12 Дисков Raid 5) размер Stipe size указывался 128kByte, при форматировании тома Allocation Unit Size - 8Kbyte.
Если IOMeter c паттерном: размер блока 40Kbyte 100% Read 0% Random выдаст результат 4000IOPS при глубине очереди (32 64 128, приблизительно одинаково), могу ли утверждать, что этот дисковый массив выдержит нагрузку от 40 пользователей?(Возможно степень рэндома здесь помешает, если это так - подскажите как ее померить)
Stripe Size это размер блока чередования в RAID. Он задается при создании RAID. Для оптимизации работы массива данные в RAID4-5-6 чередуются не посекторно, а более протяженными блоками - “страйпами” (в RAID-3 как раз секторами, и это очень сильно сказывается на быстродействии).
Allocation Unit Size это адресуемый блок в понятиях файловой системы. Это участок данных, к которому можно обратиться, извлечь его или записать, методами работы OS с файловой системой.
Block Size это размер блока, которым оперирует приложение.
Общий принцип выбора таков: чем больше последовательных обращений, тем выгоднее использование больших блоков, так как на чтение или запись одного блока (allocation unit size, etc) расходуется одна “операция”. Однако при росте random-ных операций, эффективность сильно падает, так как если приложению нужен один байт из кластера секторов размером 4…64 килобайта, то 4…64 килобайта - 1 байт будут считаны напрасно, и лишь зря займут bandwith канала при чтении-записи и место в кэше. Чем больше random-операций - тем менее выгодно увеличение размера “блока операций”.
В деталях, к сожалению, многое зависит от конкретной реализации.
Правильно ли я понял, в случае, когда приложение на запись генерирует блок 1.5Mbyte, если том отформатирован с размером кластера 8Kbyte, то это приложение должно потреблять 1.5*1024/6 = 192 IOPS?