Анализ утилизации СХД
Как понять, что СХД плохо? Как определить что запас производительности исчерпан? Какие параметры об этом свидетельствуют? В этой статье речь пойдет об анализе утилизации СХД, а также выявлении и прогнозировании проблем связанных с производительностью. Материал может быть не интересен опытным storage администраторам, поскольку будут рассмотрены только общие моменты, без углубления в логику работы хитрых механизмов оптимизации производительности.
Для начала определимся с терминологией. Есть несколько терминов и аббревиатур близких по смыслу: СХД, дисковый массив, SAN, Storage Array или просто Storage. Попробую внести ясность.
SAN — Storage Area Network или сеть хранения данных, это совокупность оборудования осуществляющая передачу трафика между сервером и системой хранения данных.
СХД — система хранения данных или дисковый массив, оборудование на котором хранятся данные с возможностью оперативного доступа. Есть еще архивные хранилища, но здесь мы их рассматривать не будем. Аббревиатура СХД так же может употребляться как сокращение от сеть хранения данных, но среди русскоговорящих специалистов термин СХД закрепился именно за системой хранения данных.
СХД могут обеспечивать два способа доступа к данным:
- Блочный доступ, операционная система сервера работает с СХД как с SCSI жестким диском (упрощенно).
- Файловый доступ, операционная система сервера работает с СХД как с файловым хранилищем по протоколу NFS, SMB и тд.
Для оценки производительности СХД используют три основные метрики
- Service Time, часто именуемый latency или responce time, измеряется в миллисекундах и обозначает:
- при чтении: время с момента получения СХД задания на чтение блока информации до отправки запрошенной информации.
- при записи: время с момента получения записываемого блока информации до подтверждения о его успешной записи.
- IO/s — количество операций ввода вывода в секунду.
- MB/s — количество переданных мегабайт в секунду.
Рассмотрим наиболее типичные проявления проблем производительности СХД по показателям Service Time, IO/s и MB/s.
Повышенный Service Time
Для каждого СХД есть крайнее значение Service Time которое соответствует максимальной производительности, другими словами, незначительное увеличение нагрузки приведет к существенному повышению Service Time, вызвав тем самым деградацию требовательных к задержкам приложений.
Для примера, ниже графики зависимости Service Time от IOPS для двух конфигураций СХД.
ST для All flash СХД, 2 Node, 24×1.9 TB SSD, RAID 5, Random 32k, 50/50 Read/Write.
ST для классического СХД, 2 Node, 24×1.8 TB HDD, RAID 5, Random 32k, 50/50 Read/Write.
В общих случаях для All Flash СХД приемлемым считается Service time меньше 1ms, а для классических СХД до 20ms. Порог приемлемого Service time зависит от числа контроллеров, скорости дисков и конечно модели самой СХД, и может отличаться от приведенных значений.
Также нужно учитывать до какого уровня задержек дисковой подсистемы сохраняется нормальная работоспособность приложения, и всегда иметь необходимый запас.
Планка по MB/s
Чаще всего свидетельствует об исчерпании пропускной способности канала или FC адаптера.
Конкурирующие значения по MB/s или IO/s
Сумма (оранжевый график) двух или более параметров на отрезке времени имеет константу и не превышает ее в какой-либо момент. Такая ситуация может наблюдаться в случае конкуренции за пропускную способность канала или порта СХД.
Понижение IO при возрастании ST
В случае если процентное распределение размеров блока не изменилось, но при этом ST начинает повышаться, а IO падать, это может свидетельствовать об аппаратных проблемах с СХД, деградации одного из контроллеров или высокой утилизации CPU.
Утилизация CPU
Утилизация CPU контроллеров СХД в общих случаях не должна превышать 70%, если она постоянно выше 70%, то это свидетельствует об отсутствии запаса производительности СХД.
Тут нужно отметить, что СХД можно разделить на две большие группы:
- С использованием ASIC, в таких СХД передача данных внутри массива обрабатывается отдельным высокопроизводительным чипом, а CPU остаются сервисные задачи, такие как создание и удаление дисков и снапшотов, сбор статистики и тд.
- Без использования ASIC, в таких СХД все задачи выполняет CPU.
Медленный рост IO на чтение
Такая проблема может наблюдаться в случае если СХД использует тиринг размещения данных между носителями разной скорости (например, SSD и NL SATA).
К примеру: некая БД работает с высокой нагрузкой один день в неделю, а остальное время простаивает, в таком случае данные к которым давно не было обращений перейдут на носители с малой скоростью, и скорость чтения будет постепенно расти при переходе (так называемом прогреве данных) на быстрые носители.
Какой характер нагрузки не свидетельствует о проблемах?
Пилообразный график IO
Скачки по MB
Прыгающие значения IO
Все перечисленные примеры нагрузки не свидетельствуют о каких-либо проблемах на стороне СХД. Нагрузка создается хостом подключенным к СХД и зависит от логики процессов использующих дисковое пространство.
Как определить трешхолды для Service Time, IO/s и MB/s?
Данные параметры можно рассчитать теоретически, складывая производительность дисков и считая пенальти выбранного уровня RAID, также можно воспользоваться сайзерами при наличие оных, но расчет будет очень приблизительным, поскольку не будет учитываться реальный профиль нагрузки. Для определения точных пороговых значений, свидетельствующих например о 90% загрузке СХД, необходимо провести нагрузочное тестирование при помощи специального ПО, сформировав профиль нагрузки близкий к реальному и замерить максимальные значения IO/s и MB/s. Но как быть с Service Time? Тут зависимость нелинейная. Для определения Service Time соответствующего 90% загрузке нужно просто сгенерировать 90% от максимально достигнутого значения по IO. Полученные результаты можно экстраполировать на близкие по конфигурации СХД.
Вместо заключения
Анализ и интерпретация параметров производительности СХД в большинстве случаев задача не тривиальная, нужно понимать архитектуру и принцип работы конкретной СХД, иметь схему портов SAN и знать нюансы работы используемых FC адаптеров. Я не рассматривал влияние репликации и использование конвергентных решений, поскольку применение данных технологий существенно усложняет описание процессов влияющих на производительность и сужает перечень общих рекомендаций. В статье не разбирались параметры использования кеша контроллеров, загрузки дисков и утилизации портов внутренней коммутации СХД, поскольку интерпретация этих данных сильно зависит от конкретной модели СХД и применяемых технологий.
- IT-инфраструктура
- SAN
- Хранилища данных
HDD Utilization 100% при низких read и write
Прошу Вас помощи в теории о странном поведении системы в плане работы с жестким диском.
В мире существует достаточно загруженный сервер на Centos 6.7, являющиеся виртуальной машиной VMWare. Сервер очень загружен днём и не сильно ночью. В своё время данную виртуальную машину апгрейдили по CPU, RAM и HDD. Однако пользователей становилось всё больше и мы упёрлись в I/O HDD, который уже так просто не «добавить».
Пока оптимизация данного параметра только в планах, однако мне на руки попался график с Zabbix, где я обнаружил одну странную вещь.
Дело в том, что днём HDD Utilization доходит до 100% и оно понятно — пользователи выполняют кучу операций по чтению и записи. Но меню больше интересует, что творить ночью. Как видите, часов в 5-6 HDD Utilization держится на 100%, однако операции чтения/записи околонулевые. Сколько я не пытался найти информацию по поводу данного факта в интернете — ничего полезного не узнал. Совершенно не понятно, что заставляет Утилизацию держаться на максимальных значениях: то ли идёт какая-то проверка дисков на целостность данных по ночам (тогда почему фиксируется Утилизация, но не фиксируется чтение/запись), то ли планировщик сошел с ума и гоняет считыватель жесткого диска туда-сюда, то ли соседние виртуальные машины на этом сервере виртуализации VMWare выполняют какой-то массовую обработку информации и нашему серверу эти все операции видны только зашкаливающей утилизацией. Не понятно.
Подскажите, было ли в Вашей работе нечто подобное и куда тут стоит копать?
PIKNIK
05.07.16 17:59:02 MSK
На random seek hdd сосут.
anonymous
( 05.07.16 18:15:20 MSK )
Смотри crontab, что там у тебя запускается. Может бэкап делается или сканер какой работает. Ну или проснись в это время, залезь в консоль и смотри top/iotop/iostat.
И с чего ты взял что ио не фиксируется? Ты его не видишь потому что масштаб большой.
anonymous
( 05.07.16 22:27:58 MSK )
Ответ на: комментарий от anonymous 05.07.16 18:15:20 MSK
А где ты ещё видел random seek?
И где на графике виден random io в 5-6 утра?
anonymous
( 05.07.16 22:32:05 MSK )
Ответ на: комментарий от anonymous 05.07.16 22:32:05 MSK
anonymous
( 05.07.16 22:33:40 MSK )
Ответ на: комментарий от anonymous 05.07.16 22:33:40 MSK
А что, у них быстрее random seek? Ты бы ещё дискеты и стримеры вспомнил.
anonymous
( 05.07.16 23:01:32 MSK )
Что именно на данном графике считается за 100%?
Deleted
( 05.07.16 23:27:14 MSK )
Сколько у тебя iops в нормальном состоянии (при утилизации в районе 70%) и сколько при 100%?
Если посмотреть на график — выглядит, как-будто кто-то пишет по несколько байт в разных сторон диска (т.е. много времени уходит на позиционирование головки).
Что в это время говорит iotop?
CaveRat ★★
( 05.07.16 23:37:14 MSK )
Хотелось бы обратить внимание экспертов на то, что это виртуальная машина. Нагрузку на диск/схд могут создавать другие потребители. В т.ч. другие хосты.
Ночь — время бекапов, кстати
router ★★★★★
( 05.07.16 23:42:51 MSK )
Ответ на: комментарий от CaveRat 05.07.16 23:37:14 MSK
Если посмотреть на график — выглядит, как-будто кто-то пишет по несколько байт в разных сторон диска
ТС обозначил временные рамки проблемы: 5-6 утра, на графике в этот период почти нет синеньких черточек, одни зеленые. Где запись увидел?
anonymous
( 06.07.16 09:24:44 MSK )
Ответ на: комментарий от router 05.07.16 23:42:51 MSK
Эксперты обратили внимание, но странно что никто пока не сказал что ТС что-то не то меряет. 🙂
в график не мешало бы всунуть временные метрики из iostat, например: iowait, avgsvctime, etc.
anonymous
( 06.07.16 10:01:48 MSK )
Увеличил график. Там выделилось чтение на 0.5К r/s и пики записи на ~1К w/r. Считайте, что нулевая нагрузка.
Для сравнения, в дневное время данные цифры держатся в районе 30-70К.
Вот IOstat в дневное время:
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sdb 0,00 49,20 114,40 8,20 5206,40 459,20 46,21 0,43 3,48 2,37 29,04 sdf 0,00 98,20 308,40 165,80 7392,00 2112,00 20,04 0,99 2,09 1,44 68,44 sde 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 sdc 0,00 12,00 401,80 3,60 16489,60 124,80 40,98 1,73 4,26 2,32 94,16 sdd 0,00 3,60 45,60 3,20 985,60 54,40 21,31 0,15 3,13 3,00 14,64 sda 0,00 1,20 0,00 0,40 0,00 12,80 32,00 0,00 0,50 0,50 0,02 sdg 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 dm-0 0,00 0,00 0,00 1,60 0,00 12,80 8,00 0,00 0,50 0,12 0,02 dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 dm-2 0,00 0,00 870,60 343,80 30043,20 2750,40 27,00 3,66 3,02 0,82 100,00
В ночное я чуть позже смогу снять.
dm-2 — это LVM из дисков sdb, sdc, sdd, sdf, sdg Именно на него ложится вся нагрузка и именно он фигурирует в графике.
PIKNIK
( 06.07.16 10:47:05 MSK ) автор топика
Ответ на: комментарий от PIKNIK 06.07.16 10:47:05 MSK
Крон пустой, кстати.
Про random seek сейчас почитаю.
PIKNIK
( 06.07.16 10:48:49 MSK ) автор топика
посмотри метрики гипервизора.
Deleted
( 06.07.16 12:41:26 MSK )
Ответ на: комментарий от Deleted 06.07.16 12:41:26 MSK
PIKNIK
( 06.07.16 12:43:49 MSK ) автор топика
Ответ на: комментарий от PIKNIK 06.07.16 12:43:49 MSK
покажи iostat в мегабайтах, а не секторах.
похоже, что у тебя диск читает на полную катушку, если перевести сектора в мегабайты при условии сектор=4К
Deleted
( 06.07.16 13:54:48 MSK )
Ответ на: комментарий от Deleted 06.07.16 13:54:48 MSK
Сейчас уже вечер, утил на половину упал.
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util sdb 0,01 485,47 57,09 27,50 1,97 2,00 96,13 0,31 3,63 1,94 16,38 sdf 0,06 217,69 115,79 89,05 4,17 1,20 53,69 1,34 6,53 1,66 34,08 sde 0,00 0,00 0,00 0,00 0,00 0,00 9,63 0,00 0,10 0,09 0,00 sdc 0,00 36,45 26,61 3,54 1,14 0,16 88,26 0,14 4,74 3,12 9,42 sdd 0,01 64,83 36,90 4,93 2,39 0,27 130,32 0,23 5,58 2,53 10,56 sda 1,95 9,21 4,97 3,77 0,13 0,05 42,74 0,04 4,43 0,91 0,80 sdg 0,01 124,44 1,13 1,07 0,14 0,49 584,58 1,09 492,03 6,65 1,47 dm-0 0,00 0,00 4,62 11,57 0,12 0,05 21,22 0,31 19,41 0,46 0,74 dm-1 0,00 0,00 2,31 1,41 0,01 0,01 8,00 0,05 12,44 0,37 0,14 dm-2 0,00 0,00 237,60 1054,98 9,81 4,12 22,07 0,58 0,28 0,40 51,79
PIKNIK
( 06.07.16 16:17:25 MSK ) автор топика
Нужно просто понимать, как рассчитывается утилизация диска. На коротких временных интервалах утилизация составляет либо 100%, либо 0%. Диск либо занят выполнением какой-либо операции, либо простаивает — третьего не дано. Всякие там мониторинги просто усредняют это значение на более длинных временных интервалах. Например, если ты видишь утилизацию диска, равную 60% на минутном интервале, то это означает, что на протяжении 60% времени от 1 минуты диск был занят на 100%, и на протяжении 40% времени от 1 минуты диск был занят на 0%.
Если у тебя там ночью около 200 IO/s, то при service_time в 5 ms это уже даст 100%-ю утилизацию диска (диск был занят 200*5=1000ms в сек). Кстати, на графиках этого самого service_time очень не хватает.
bigbit ★★★★★
( 06.07.16 16:19:41 MSK )
Ответ на: комментарий от PIKNIK 06.07.16 16:17:25 MSK
Ну смотри, у тебя 1055 запроса в секунду на запсись, я считаю, что это неплохая производительность для гипервизора с 16 дисками в radid10 при средней нагрузке.
Deleted
( 06.07.16 16:25:01 MSK )
Из мана по iostat:
%util Percentage of CPU time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100% for devices serving requests serially. But for devices serving requests in parallel, such as RAID arrays and modern SSDs, this number does not reflect their performance limits.
Т.е. этот параметер меряет на самом деле попугаев, а точнее отношение того, сколько CPU(! не диск!) занимался I/O или своими прямыми обязаностями (расчётами и т.д.).
Ночью нагрузка на CPU маленькая (DB и заводы стоят, юзвери спят, webserver скучает). Всё, чем занимается CPU — это обработка парочки залётных I/O запросов и занимется этим (та-дам!) ~100% своего времени.
beastie ★★★★★
( 06.07.16 16:40:18 MSK )
Последнее исправление: beastie 06.07.16 16:42:24 MSK (всего исправлений: 1)
Ответ на: комментарий от anonymous 06.07.16 09:24:44 MSK
Тьфублин. Не туда посмотрел.
CaveRat ★★
( 06.07.16 17:12:21 MSK )
дефрагментация? планировщик io пробовали менять?
darkenshvein ★★★★★
( 06.07.16 17:18:44 MSK )
Ответ на: комментарий от beastie 06.07.16 16:40:18 MSK
сколько CPU(! не диск!) занимался I/O или своими прямыми обязаностями (расчётами и т.д.)
%util — это сколько квантов времени диск делал хоть что-то, т.е. был хоть чем-то занят. На том же stackoverflow.com есть тема «How the util of iostat is computed?» с исходниками iostat или вот тут по-русски неплохо описано:
http://beastea.blogspot.ru/2012/11/util-iostat.html
Обрати внимание на 2 последних предложения из мана, которые ты выше процитировал про разные точки насыщения для RAID и SSD. Если бы дело было только в CPU, как ты говоришь, то эти строки не имели бы смысла.
bigbit ★★★★★
( 06.07.16 17:51:51 MSK )
Ответ на: комментарий от PIKNIK 06.07.16 16:17:25 MSK
В общем ночью цифры держатся в тех же значениях.
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util sdb 0,01 440,80 55,48 25,17 1,94 1,82 95,37 0,29 3,62 1,96 15,82 sdf 0,06 201,04 114,49 87,46 4,14 1,13 53,42 1,26 6,25 1,67 33,78 sde 0,00 0,00 0,00 0,00 0,00 0,00 9,70 0,00 0,10 0,10 0,00 sdc 0,00 33,43 26,10 3,30 1,13 0,14 88,79 0,14 4,71 3,12 9,17 sdd 0,01 57,76 36,79 4,50 2,39 0,24 130,76 0,22 5,39 2,51 10,36 sda 1,74 8,94 4,56 3,70 0,12 0,05 41,80 0,04 4,33 0,93 0,77 sdg 0,01 118,90 1,38 1,03 0,17 0,47 540,98 1,00 415,16 6,24 1,50 dm-0 0,00 0,00 4,26 11,38 0,11 0,04 20,36 0,28 18,12 0,46 0,71 dm-1 0,00 0,00 2,04 1,25 0,01 0,00 8,00 0,04 12,44 0,37 0,12 dm-2 0,00 0,00 234,32 973,39 9,77 3,80 23,01 2,13 1,60 0,43 51,53
Эти ~51% утилизации держатся всю ночь, хотя нагрузка на сервер тогда минимальная (но не отсутствующая т.к. несколько заблудших пользователей продолжают работать). При этом в Zabbix’e в это время показывает 100% утилизации.
Теперь вообще странные данные получились. Полное несоответствие графиков и iostat. Я уже было думал, что сервера перепутал, но это я перепроверил раза 3.
Птн Июл 8 03:45:35 MSK 2016 avg-cpu: %user %nice %system %iowait %steal %idle 9,40 0,00 1,02 1,82 0,00 87,76 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util sdb 0,01 441,84 55,49 25,23 1,93 1,82 95,34 0,29 3,62 1,96 15,84 sdf 0,06 201,50 114,38 87,64 4,11 1,13 53,14 1,26 6,25 1,67 33,73 sde 0,00 0,00 0,00 0,00 0,00 0,00 9,70 0,00 0,10 0,10 0,00 sdc 0,00 33,51 26,10 3,31 1,13 0,14 88,71 0,14 4,71 3,12 9,17 sdd 0,01 57,89 36,54 4,51 2,38 0,24 130,79 0,22 5,41 2,52 10,33 sda 1,75 8,95 4,56 3,70 0,12 0,05 41,82 0,04 4,33 0,93 0,77 sdg 0,01 119,09 1,38 1,03 0,17 0,47 540,84 1,00 415,19 6,24 1,50 dm-0 0,00 0,00 4,27 11,40 0,11 0,04 20,37 0,28 18,14 0,46 0,71 dm-1 0,00 0,00 2,05 1,26 0,01 0,00 8,00 0,04 12,44 0,37 0,12 dm-2 0,00 0,00 233,97 975,54 9,72 3,81 22,91 2,10 1,58 0,43 51,43
Птн Июл 8 04:05:35 MSK 2016 avg-cpu: %user %nice %system %iowait %steal %idle 9,39 0,00 1,02 1,82 0,00 87,77 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util sdb 0,01 441,38 55,45 25,21 1,93 1,82 95,37 0,29 3,62 1,96 15,82 sdf 0,06 201,29 114,44 87,57 4,13 1,13 53,31 1,26 6,25 1,67 33,76 sde 0,00 0,00 0,00 0,00 0,00 0,00 9,70 0,00 0,10 0,10 0,00 sdc 0,00 33,48 26,08 3,30 1,13 0,14 88,78 0,14 4,71 3,12 9,17 sdd 0,01 57,83 36,55 4,50 2,38 0,24 130,98 0,22 5,41 2,52 10,33 sda 1,75 8,94 4,56 3,70 0,12 0,05 41,81 0,04 4,33 0,93 0,77 sdg 0,01 119,06 1,38 1,03 0,17 0,47 540,98 1,00 415,16 6,24 1,50 dm-0 0,00 0,00 4,26 11,39 0,11 0,04 20,37 0,28 18,13 0,46 0,71 dm-1 0,00 0,00 2,05 1,25 0,01 0,00 8,00 0,04 12,44 0,37 0,12 dm-2 0,00 0,00 233,98 974,64 9,74 3,81 22,96 2,13 1,60 0,43 51,47
Птн Июл 8 04:30:06 MSK 2016 avg-cpu: %user %nice %system %iowait %steal %idle 9,38 0,00 1,02 1,82 0,00 87,78 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util sdb 0,01 440,81 55,48 25,17 1,94 1,82 95,37 0,29 3,62 1,96 15,82 sdf 0,06 201,04 114,47 87,46 4,14 1,13 53,43 1,26 6,25 1,67 33,78 sde 0,00 0,00 0,00 0,00 0,00 0,00 9,70 0,00 0,10 0,10 0,00 sdc 0,00 33,44 26,10 3,30 1,13 0,14 88,79 0,14 4,71 3,12 9,17 sdd 0,01 57,76 36,79 4,50 2,39 0,24 130,76 0,22 5,39 2,51 10,36 sda 1,74 8,94 4,56 3,70 0,12 0,05 41,80 0,04 4,33 0,93 0,77 sdg 0,01 118,90 1,38 1,03 0,17 0,47 540,98 1,00 415,16 6,24 1,50 dm-0 0,00 0,00 4,26 11,38 0,11 0,04 20,36 0,28 18,12 0,46 0,71 dm-1 0,00 0,00 2,04 1,25 0,01 0,00 8,00 0,04 12,44 0,37 0,12 dm-2 0,00 0,00 234,30 973,41 9,77 3,80 23,01 2,13 1,60 0,43 51,53
В итоге у нас 2 неизвестных:
1) почему график показывает 100% утила, когда он ~51%
2) Почему значения на iostat почти не меняются, а в графике меняются.
Я прям чувствую, что кто-то обманывает. Но кто и зачем — не понятно.
PIKNIK
( 08.07.16 09:33:16 MSK ) автор топика
Ответ на: комментарий от PIKNIK 08.07.16 09:33:16 MSK
Как iostat запускаешь? Надеюсь, ты в курсе, что первое измерение в iostat надо отбрасывать, т.к. это средние значения с момента загрузки ОС? Либо запускать с опцией -y.
bigbit ★★★★★
( 08.07.16 11:16:00 MSK )
Ответ на: комментарий от bigbit 08.07.16 11:16:00 MSK
Не в курсе. Перемеряю.
PIKNIK
( 08.07.16 12:22:46 MSK ) автор топика
Ответ на: комментарий от PIKNIK 08.07.16 12:22:46 MSK
Впоимал нужные пики утила.
10.07.2016 04:30:24 avg-cpu: %user %nice %system %iowait %steal %idle 1,57 0,00 0,37 2,86 0,00 95,20 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util sdb 0,00 5,67 0,10 2,50 0,00 0,03 25,74 0,00 1,45 1,33 0,35 sdf 0,00 2,80 82,50 6,27 11,43 0,04 264,53 1,32 14,85 9,68 85,90 sde 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 sdc 0,00 0,10 0,23 0,10 0,03 0,00 209,60 0,00 3,00 2,30 0,08 sdd 0,00 0,33 11,27 0,33 1,54 0,00 271,59 0,20 17,62 11,45 13,28 sda 0,00 7,37 2,23 3,27 0,06 0,04 36,46 0,01 1,28 0,88 0,48 sdg 0,00 1,07 0,50 1,07 0,02 0,01 39,83 0,00 1,96 0,96 0,15 dm-0 0,00 0,00 2,23 10,63 0,06 0,04 15,59 0,01 1,07 0,38 0,49 dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 dm-2 0,00 0,00 94,63 20,23 13,03 0,08 233,66 1,54 13,41 8,62 99,04 10.07.2016 04:35:24 avg-cpu: %user %nice %system %iowait %steal %idle 1,87 0,00 0,48 2,38 0,00 95,27 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util sdb 0,00 1,43 143,80 1,07 19,22 0,01 271,80 0,51 3,54 2,10 30,44 sdf 0,00 2,17 3,37 21,27 0,03 0,09 10,50 0,03 1,11 1,02 2,52 sde 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 sdc 0,00 0,40 280,93 1,07 37,38 0,01 271,48 1,00 3,56 2,10 59,36 sdd 0,00 0,00 37,03 0,00 4,86 0,00 268,79 0,14 3,73 2,24 8,30 sda 0,00 2,30 1,77 1,93 0,04 0,02 30,99 0,00 1,34 0,67 0,25 sdg 0,00 0,17 0,00 0,17 0,00 0,00 16,00 0,00 0,80 0,80 0,01 dm-0 0,00 0,00 1,77 4,23 0,04 0,02 19,11 0,01 1,38 0,41 0,25 dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 dm-2 0,00 0,00 465,13 27,73 61,49 0,11 255,95 1,69 3,43 1,98 97,58 11.07.2016 11:01:40 avg-cpu: %user %nice %system %iowait %steal %idle 15,30 0,00 2,47 4,26 0,00 77,98 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util sdb 0,00 31,63 233,77 13,17 10,08 0,18 85,02 0,86 3,47 2,12 52,45 sdf 0,00 93,43 388,47 174,53 6,73 1,05 28,29 2,29 4,07 1,68 94,58 sde 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 sdc 0,00 21,93 124,10 5,20 3,92 0,11 63,72 0,57 4,43 2,97 38,41 sdd 0,00 4,93 83,53 6,53 1,42 0,04 33,40 0,43 4,83 3,30 29,75 sda 0,93 6,80 2,93 2,93 0,06 0,04 34,45 0,01 1,59 1,20 0,70 sdg 0,00 2,53 2,07 2,07 0,08 0,02 49,74 0,03 6,90 3,73 1,54 dm-0 0,00 0,00 3,90 9,73 0,06 0,04 14,83 0,03 2,24 0,52 0,71 dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 dm-2 0,00 0,00 832,00 355,93 22,23 1,39 40,73 4,44 3,73 0,84 99,43
В первом выводе у нас имеется 99% утила при одном лишь чтении в 13МБ/с, а на втором (разница 5 минут) уже 97% утила при чтении в 61МБ/с. Сверил с графиком — он корректно вырисовывает цифры r/s и w/s. То есть непонятна разница, почему утил может пикануть при 13МБ/c чтении, а может при 61МБ/с чтении.
Для сравнения третий вывод — это вывод пика днём.
В общем вопрос всё тот же: почему утил держится на 100%, но при этом жесткий диск на чтение может показывать несоизмеримо разные значения.
Мне всё же кажется, что это проделки виртуальной машины (может IOstat считает read и write от ОС, а утил от драйвера HDD, который эмулируется сервером виртуализации). Но это только догадки.
PIKNIK
( 11.07.16 11:26:55 MSK ) автор топика
Ответ на: комментарий от PIKNIK 11.07.16 11:26:55 MSK
Ну все правильно. Разберем первое измерение: (94,63+20,23)*8,62 = 990.0932. Т.е. 990 миллисекнд из 1000 (1 секунда) диск чем-то занимался. Т.е. его утилизация и правда 99%. Он сделал всего 114 IO/s, но делал их очень медленно — обрати внимание на service_time=8,62. Наверняка ночью идут бэкапы, и возрастает время отклика. С этими данными уже можно идти к админам гипервизора и стораджа и разбираться, какого фига и доколе (шутка, 8 ms это тоже неплохо).
По остальным измерениям аналогично. Там service_time отличный, но и IO/s намного больше, что и дает ту же утилизацию в 100%.
Вообще, тебя не должно удивлять то, что диск выдает 100% утилизвцию при малом количестве IO/s и ту же 100% утилизацию при большом. Метод подсчета утилизации не учитывает, что некоторые диски могут делать несколько операций одновремено. Другими словами, если диск занят на 100%, это не означает, что он не может делать больше. Это отнсится к RAID и в особенности к SSD. Да, диск был занят 100% времени, но если ему еще поддать IO/s, то он их сделает, т.к. может делать несколько операций параллельно.
bigbit ★★★★★
( 11.07.16 12:14:42 MSK )
Последнее исправление: bigbit 11.07.16 12:15:48 MSK (всего исправлений: 1)
Ответ на: комментарий от bigbit 11.07.16 12:14:42 MSK
Да, действительно полезное говоришь. Спасибо!
Очень приятно пообщаться со знающими людьми. Буду и дальше продолжать развиваться в этом вопросе!
Спасибо всем за всё! Удачи)
Уничтожение дисков
Наряду с бумажными носителями информации в последнее время стали популярными и цифровые: многие компании частично или полностью переходят на электронный документооборот. Именно поэтому такие услуги как уничтожение CD-, DVD-дисков и уничтожение жестких дисков пользуются в наше время огромным спросом, ведь таким образом организации могут предотвратить утечку информации.
Утилизация дисков: способы
Уничтожение CD-, DVD-дисков осуществляют различными способами:
- шредирование – промышленные шредеры большой мощности способны уничтожать портативные носители, превращая их в «крошку»;
- размагничивание – при помощи специальных устройств производят смену магнитных свойств носителей, делая их нечитабельными. Чаще всего подобным образом происходит уничтожение жестких дисков;
- дробление – полная ликвидация дисков под гидравлическим прессом.
Стоит заметить, что, несмотря на разнообразие методов, единственным, который гарантирует 100%-ный результат, является механическое уничтожение дисков. Только в таком случае можно быть полностью уверенными, что конфиденциальная информация, хранящаяся на цифровом носителе, станет полностью недоступной.
Уничтожение жестких дисков
При необходимости утилизировать жесткие диски выполняется уничтожение элементов ноутбуков и компьютеров путем превращения их в металлическую крошку. Только это поможет избежать утечки внутренней информации и секретов компании в сеть Интернет или ее восстановления при удалении из устройства. В случае выхода из строя или смены компьютеров необходимо обязательно позаботиться об изъятии и утилизации жестких дисков.
Уничтожение CD- и DVD-дисков
Самыми распространенными считаются CD- и DVD-диски, которые отличаются компактными размерами, низкой стоимостью, удобством использования и свойством хранить большие объемы информации. Качественное и полное уничтожение CD-, DVD-дисков без возможности восстановления или копирования информации реально только при условии их дробления или измельчения. Данная операция при использовании современного оборудования занимает минимум времени и не будет слишком затратной.
Архивная компания ОРБ предлагает вам уничтожение жестких дисков и прочих портативных носителей информации быстро и надежно. Мы позаботимся о том, чтобы ваша информация была уничтожена и не подлежала восстановлению. Наши специалисты защитят вас от экономического, промышленного и интеллектуального шпионажа путем удаления информации и ликвидации ее носителей навсегда.
Утилизация жестких дисков / (351) 777-777-1
Наша компания предлагает услугу уничтожения жестких дисков и других электронных носителей с гарантией полного уничтожения информации. Мы обеспечим полную конфиденциальность и гарантируем 100% физическое разрушение жесткого диска без возможности его восстановления. На специальном оборудовании каждый диск просвериливается толстым сверлом в особом месте, просверлив отверстие в корпусе привода, которое проходит через все пластины, вы не сможете запустить привод.
Большинство современных жестких дисков не имеют воздуха внутри корпуса. Просверливание заполняет полость крошечными кусочками сверлильной стружки, которая будет на всем, включая тарелки, и сломает головки. Это также приведет к разбалансированию пластины. Также будет уничтожена плате контроллера. Уничтожение может проводиться в присутствии заказчика. скорость уничтожения до 10 дисков в минуту. Утилизацию и уничтожение жестких дисков наша компания осуществляет в соответствии с установленным законодательством РФ, оформлением полного пакета документации, в том числе актов технической экспертизы.
Самая главная угроза для экологии, которая исходит от старой оргтехники и электронного оборудования — это высокое содержание опасных веществ внутри механизмов или в материалах основания. Жесткие диски в своём составе могут иметь свинец, мышьяк, железо, алюминий, тяжелые металлы. При разобщении таких элементов происходит отравление окружающей среды.
Сюда же можно отнести старые жесткие диски типа HDD, SDD. Утилизация жестких дисков — процесс не из лёгких. Современная технологическая сфера не стоит на месте — уже начали продумывать модель жесткого диска с восстановительными магнитами, что впоследствии значительно облегчит использование накопителей в работе организации. Но на данный момент электронные жесткие диски — это достаточно проблематичные объекты с точки зрения переработки.
Как происходит утилизация жестких дисков?
Уничтожение данных и обесточивание жёсткого диска осуществляют с помощью спецустройств, которые называют утилизаторами.
Жесткий диск помещается в небольшую камеру, где на него воздействуют магнитами. Такая утилизация полностью безопасна.
Затем сам корпус и основание жёсткого диска демонтируют, разбирают, сортируют детали, оправляя часть на переработку, а часть на ликвидацию.
Мы готовы выполнить для Вас услугу Утилизация жестких дисков
в ДЕНЬ ЗАКАЗА (351) 777-777-1 или телефоны Наших менеджеров