Как стать автором
Обновить

Как правильно мерять производительность диска

Настройка Linux *Системное администрирование *Серверная оптимизация *
Туториал
abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

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

Лирика



Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:
  • научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
  • использование bonnie++
  • использование iozone
  • использование пачки cp с измерениема времени выполнения
  • использование iometer с dynamo на 64-битных системах


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

Как мерять правильно
Всего голосов 151: ↑145 и ↓6 +139
Просмотры 316K
Комментарии 164

Меряем производительность накопителей или снова про IOPS

Настройка Linux *Системное администрирование *Серверная оптимизация *
Из песочницы
Навеяно постом уважаемого amarao о том, как надо измерять производительность дисков.

Цель:


Протестировать производительность имеющихся в наличии средств хранения информации и убедиться в верности выбранной методики, а также понять разницу в производительности между разными видами накопителей, а также enterprise-level и consumer-level жёсткими дисками.

Оборудование:


  1. SD-карта Sandisk Class 10 UHS 1 Extreme Pro 8 GB (до 95 Мбайт/с чтение, до 90 Мбайт/с запись)
  2. SD-карта Team Class 10 32 GB (до 20 Мбайт/с)
  3. SD-карта Transcend 2GB без класса скорости
  4. SSD-диск OCZ-AGILITY3 60 GB
  5. SATA-диск consumer-level Hitachi Deskstar HDS723020BLA642 2 ТБ 7200 об/мин, 64 Мбайт
  6. SATA-диск enterprise-level Western Digital RE3 WD2502ABYS-23B7A0 250 GB 7200 об/мин 16 Мбайт
  7. SATA-диск consumer-level Seagate Barracuda 7200.11 ST3320613AS 320 GB 7200 об/мин 16 Mбайт
  8. CD-ROM
  9. RAM-диск /dev/ram в Linux


Методика тестирования:


Методика полностью описана в посте. Есть правда несколько не совсем понятных моментов:
Мы подбираем такую глубину параллельности операций, чтобы latency оставалось в разумных пределах.
Задача подобрать такой iodepth, чтобы avg.latency была меньше 10мс.

Так как в тестировании используется не СХД и не диски SAS, а различные накопители SATA, то параллельность нам измерять нету смысла.
Очищать диск перед каждым тестированием (dd if=/dev/zero of=/dev/sdz bs=2M oflag=direct) очень времязатратно, поэтому будем это делать перед тестированием один раз на каждый накопитель.
Тестировать весь диск полностью очень времязатратно, поэтому будем использовать тестирование в течении 30 секунд.
Итак, сформулируем методику тестирования для нашего случая:
Получить значение IOPS, выдаваемое накопителем при произвольном чтении и записи блоками по 4 Кбайт и задержке avg.latency не более 10 мс за время теста в 30 секунд. Также для полноты картины измерим скорость линейной записи.
Читать дальше →
Всего голосов 21: ↑12 и ↓9 +3
Просмотры 25K
Комментарии 21

Как работает SSD кеширование средствами гипервизора в облаке VMware

Блог компании CloudMTS
Компания VMware еще с выходом VMware vSphere 5.1 объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, включая возможность использования распределенного кеш на SSD-накопителях локальных дисков серверов ESXi. Данная технология имела рабочее название vFlash и находилась в стадии Tech Preview, превратившись позднее в полноценную функцию vSphere Flash Read Cache (vFRC) платформы VMware vSphere 5.5. И это вполне рабочий инструмент, который можно использовать в задачах различного уровня.
Читать дальше →
Всего голосов 11: ↑9 и ↓2 +7
Просмотры 32K
Комментарии 10

Файловая система Linux полностью на tmpfs — скорость без компромиссов

Высокая производительность *
Из песочницы

Предыстория


Так сложилось, что уже пять лет мой раздел ntfs с операционной системой Windows располагается на рамдиске. Решено это не аппаратным, а чисто программным способом, доступным на любом ПК с достаточным количеством оперативной памяти: рамдиск создается средствами загрузчика grub4dos, а Windows распознаёт его при помощи драйвера firadisk.

Однако до недавнего времени мне не был известен способ, как реализовать подобное для Linux. Нет, безусловно, существует огромное количество линуксовых LiveCD, загружающихся в память при помощи опций ядра toram, copy2ram и т. д., однако это не совсем то. Во-первых, это сжатые файловые системы, обычно squashfs, поэтому любое чтение с них сопровождается накладными расходами на распаковку, что вредит производительности. Во-вторых, это достаточно сложная каскадная система монтирования (так как squashfs — рид-онли система, а для функционирования ОС нужна запись), а мне хотелось по возможности простого способа, которым можно «вот так взять и превратить» любой установленный на жесткий диск Linux в загружаемый целиком в RAM.

Ниже я опишу такой способ, который был с успехом опробован. Для опытов был взят самый заслуженный дистрибутив Linux — Debian.
Читать дальше →
Всего голосов 83: ↑74 и ↓9 +65
Просмотры 117K
Комментарии 165

Производительность дисковых систем серверов HP ProLiant DL360 от Gen5 до Gen8. Всё, что вы не знали и боялись спросить

Блог компании WestComp
Мы постоянно сталкиваемся с типовой задачей о развёртывании офисного сервера для различных компаний. Чаще всего клиент хочет купить сервер, на котором будут работать офисная почта, например, postfix+*SQL, ejabberd с тем же *SQL, samba, а также *SQL под 1С. В этом случае возникает необходимость изучения производительности дисковых массивов применительно к серверам «рабочей группы» одной и той же модели, но различных поколений. Поскольку наша компания в большей степени специализируется на продукции Hewlett-Packard, анализу подверглись 1U серверы HP ProLiant 360 5-го, 6-го, 7-го и 8-го поколений:

Тестируемые сервера
HP Proliant DL360 Gen5 с контроллером P400i
HP Proliant DL360 Gen6 с контроллером P410i
HP Proliant DL360 Gen7 с контроллером P410i
HP Proliant DL360p Gen8 с контроллером P420i


Во всех конфигурациях контроллера используем кэш размером 256Mb. Стоит отметить отличие в пропускной способности PCI Express шины, посредством которой подключены контроллеры: P400i и P410i — 2GBps (гигабайта в секунду), P420 — 8 GBps (гигабайт в секунду).



Первый вопрос, который логично возникает в этом случае: в каких попугаях измерять производительность? Изучив статью уважаемого amarao, мы установили, что подобные измерения стоит проводить как минимум по двум параметрам: IOPS — количество дисковых Input/Output операций в секунду: чем их больше, тем лучше и Latency — время обработки операции: чем меньше, тем лучше.

Было решено произвести сравнение производительности различных конфигураций применительно к разным типовым задачам, поскольку эти задачи подразумевают различные варианты нагрузки на дисковую подсистему. Характер нагрузки определяется следующими параметрами: размер блока, соотношение операций чтение-запись, случайный/последовательный доступ.

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

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

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

Тестируем непосредственно raw-device (прямой доступ, без оглядки на файловую систему), чтобы избежать влияния особенностей реализации файловых систем и всего, что с этим связано на разных платформах.
Под эту задачу были написаны правила для fio и IOMetter.
Читать дальше →
Всего голосов 12: ↑10 и ↓2 +8
Просмотры 18K
Комментарии 8

Тестирование производительности HP P2000 MSA G3

Блог компании WestComp

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

Сейчас же, решили сравнить производительность СХД начального уровня и массива на контроллере P410. Напомню, что интересующие нас параметры: IOPS — количество дисковых операций в секунду (чем больше, тем лучше) и latency — время обработки операции (чем меньше, тем лучше).

Конфигурация стенда:
Шасси HP C7000
Блейд BL460C G6
Сервер HP Proliant DL360 Gen7
Пара свитчей AE372A
Полка HP StorageWorks P2000 G3 MSA
Пара контроллеров AP837B
Диски 2.5" HP 146Gb SAS 15k 6G HDD (512547-B21, 512544-001)



Читать дальше →
Всего голосов 11: ↑9 и ↓2 +7
Просмотры 7.7K
Комментарии 6

HCIBench — нагрузочное тестирование хранилищ под vSphere

Системное администрирование *IT-инфраструктура *Виртуализация *Серверная оптимизация *Хранение данных *
Туториал

Введение




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

Для оценки производительности хранилища, дабы понимать его возможности для выполнения реальных задач, необходимо проведение нагрузочного тестирования. Самыми простыми в реализации являются синтетические тесты, выполняемые, например, с помощью таких популярных утилит как Iometer и Fio. Классическое применение: тестирование локального хранилища узла либо внешней СХД с одного или нескольких узлов.

С виртуальной инфраструктурой дела обстоят несколько сложнее, она состоит из множества хостов, на которых крутятся десятки ВМ. Даже небольшая инсталляция из двух-четырех хостов может легко держать около 100 ВМ, не говоря о средних и больших инфраструктурах из десятков и сотен хостов.

Тестировать общее хранилище для такой инфраструктуры путем запуска Iometer/Fio на одной или нескольких ВМ либо с выделенного узла на голом железе будет некорректным. Такое тестирование должно быть распределенным и обеспечивать параллельную генерацию ввода/вывода и централизованный учет результатов с множества ВМ со всех хостов кластера vSphere. Только такой подход позволит сэмулировать нагрузку реального высоконагруженного виртуального кластера.

Лично я пробовал на своем тестовом кластере vSphere vSAN 6 update 3 из 4х хостов ручками развернуть 4 ВМ на Винде с Iometer, через командную строку подключить Dynamo на 3х ВМ к консоли Iometer на четвертой ВМ, с которой и проводил распределенное тестирование. Даже для 4х ВМ дело это скучное и неблагодарное, разворачивать по несколько ВМ на хост вручную вообще не вариант.

Конечно можно воспользоваться скриптами, средствами автоматизации и сделать всё красиво, но я не умею. Поэтому для таких как я небольшая группа разработчиков VMware выпустила и развивает бесплатную утилиту HCIBench, о ней мы и будем говорить в данной статье.
Читать дальше →
Всего голосов 8: ↑7 и ↓1 +6
Просмотры 8.8K
Комментарии 0

Производительность mdadm raid 5,6,10 и ZFS zraid, zraid2, ZFS striped mirror

Высокая производительность *Настройка Linux *Системное администрирование *IT-инфраструктура **nix *
Тестируем производительность ZFS и mdadm+ext4 на SSD Sandisk CloudSpeed
для выбора технологии создания локального дискового массива.


Цель данного тестирования — выяснить, с какой реальной скоростью смогут работать виртуальные машины в raw файловых образах, если разместить их на 4-х производительных SSD-дисках. Тестирование будет производится в 32 потока, чтобы приблизительно создать условия работы реального гипервизора.

image
Читать дальше →
Всего голосов 13: ↑9 и ↓4 +5
Просмотры 25K
Комментарии 65

Тестирование производительности гиперконвергентных систем и SDS своими руками

Блог компании Nutanix Системное администрирование *Виртуализация *Облачные вычисления *Хранение данных *
— Штурман, приборы!
— 36!
— Что 36?
— А что приборы?

Примерно так на сегодня выглядит большинство синтетических тестов систем хранения данных. Почему так?

До относительно недавнего времени большинство СХД были плоскими с равномерным доступом. Что это означает?

Общее доступное дисковое пространство было собрано из дисков с одинаковыми характеристиками. Например 300 дисков 15k. И производительность была одинаковой по всему пространству. С появлением технологии многоуровневого хранения, СХД стали неплоскими — производительность различается внутри одного дискового пространства. Причем не просто различается, а еще и непредсказуемо, в зависимости от алгоритмов и возможностей конкретной модели СХД.

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

Привычные синтетические тесты резко дают маху, цифры от этих нагрузок потеряли практический смысл. Единственный способ всерьез оценить подходит ли система — это пилотная инсталляция с перенесением продуктива. Но что делать, если на перенос продуктива не дает добро безопасность или это просто слишком долго / трудоемко. Есть ли способ оценки?
Читать дальше →
Всего голосов 9: ↑8 и ↓1 +7
Просмотры 6K
Комментарии 7

Обзор и сравнительное тестирование ПЭВМ «Эльбрус 401‑PC». Часть четвёртая — бенчмарки

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

Вид системного блока Эльбрус 401-PC спереди и сбокуРезультаты теста Pgbench (Postgresql) в упрощённом виде

Осторожно: много букв и картинок!

Обещаю, я буду осторожен
Всего голосов 90: ↑86 и ↓4 +82
Просмотры 73K
Комментарии 159

Скорость хранилища подходит для etcd? Спросим fio

Блог компании Southbridge Системное администрирование *Серверное администрирование *DevOps *
Перевод


Короткая история о fio и etcd


Производительность кластера etcd во многом зависит от производительности его хранилища. etcd экспортирует некоторые метрики в Prometheus, чтобы предоставить нужные сведения о производительности хранилища. Например, метрику wal_fsync_duration_seconds. В документации к etcd сказано: чтобы хранилище считалось достаточно быстрым, 99-й процентиль этой метрики должен быть меньше 10 мс. Если вы планируете запустить кластер etcd на машинах Linux и хотите оценить, достаточно ли быстрое у вас хранилище (например, SSD), можно использовать fio — популярный инструмент для тестирования операций ввода-вывода. Запустите следующую команду, где test-data — это каталог под точкой подключения хранилища:


fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Нужно просто посмотреть результаты и проверить, что 99-й процентиль длительности fdatasync меньше 10 мс. Если да, у вас достаточно быстрое хранилище. Вот пример результатов:


  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]
Читать дальше →
Всего голосов 25: ↑25 и ↓0 +25
Просмотры 4.7K
Комментарии 2

Российская СХД AERODISK: нагрузочное тестирование. Выжимаем IOPS-ы

Блог компании АЭРОДИСК Системное администрирование *Серверное администрирование *Хранение данных *Хранилища данных *


Всем привет! Как и обещали, публикуем результаты нагрузочного теста системы хранения данных российского производства – AERODISK ENGINE N2.

Читать дальше →
Всего голосов 7: ↑5 и ↓2 +3
Просмотры 6.6K
Комментарии 23

AERODISK: ожидание vs. реальность

Блог компании АЭРОДИСК Системное администрирование *IT-инфраструктура *Серверное администрирование *Хранение данных *
Recovery mode


Всем привет. В этой статье мы публикуем мнение нашего партнера — системного интегратора — компании Ulagos. Речь в ней пойдёт о том, как видят компанию Аэродиск заказчики, о том, как в принципе воспринимается любое российское решение и о том, чем заканчивается внедрение и как работает поддержка.
Всего голосов 38: ↑16 и ↓22 -6
Просмотры 9.7K
Комментарии 38

AERODISK Engine: Катастрофоустойчивость. Часть 1

Блог компании АЭРОДИСК Системное администрирование *Серверное администрирование *Хранение данных *Хранилища данных *


Привет, читатели хабра! Темой этой статьи будет реализация средств катастрофоустойчивости в системах хранения AERODISK Engine. Изначально мы хотели написать в одной статье про оба средства: репликацию и метрокластер, но, к сожалению, статья получилась слишком большой, поэтому мы разбили статью на две части. Пойдем от простого к сложному. В этой статье мы настроим и протестируем синхронную репликацию – уроним один ЦОД, а также оборвем канал связи между ЦОД-ами и посмотрим, что из этого получится.

Читать дальше →
Всего голосов 11: ↑11 и ↓0 +11
Просмотры 4.8K
Комментарии 12

AERODISK Engine: Катастрофоустойчивость. Часть 2. Метрокластер

Блог компании АЭРОДИСК Системное администрирование *Серверное администрирование *Хранение данных *Хранилища данных *


Привет, читатели Хабра! В прошлой статье мы рассказали о простом средстве катастрофоустойчивости в системах хранения AERODISK ENGINE – о репликации. В этой статье мы погрузимся в более сложную и интересную тему – метрокластер, то есть средство автоматизированной защиты от катастроф для двух ЦОД-ов, позволяющее работать ЦОД-ам в режиме active-active. Расскажем, покажем, сломаем и починим.

Читать дальше →
Всего голосов 7: ↑7 и ↓0 +7
Просмотры 5.5K
Комментарии 7

Как с fio проверить диски на достаточную производительность для etcd

Блог компании Флант Системное администрирование *Хранилища данных *Kubernetes *
Перевод
Прим. перев.: эта статья — итоги мини-исследования, проведенного инженерами IBM Cloud в поисках решения реальной проблемы, связанной с эксплуатацией базы данных etcd. Для нас была актуальна схожая задача, однако ход размышлений и действий авторов может быть интересен и в более широком контексте.



Краткое резюме всей статьи: fio и etcd


Производительность кластера etcd сильно зависит от скорости хранилища, лежащего в его основе. Для контроля за производительностью etcd экспортирует различные метрики Prometheus. Одной из них является wal_fsync_duration_seconds. В документации к etcd говорится, что хранилище можно считать достаточно быстрым, если 99-й процентиль этой метрики не превышает 10 мс…
Читать дальше →
Всего голосов 37: ↑37 и ↓0 +37
Просмотры 9.8K
Комментарии 7