Pull to refresh
  • by relevance
  • by date
  • by rating

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

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

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

Лирика



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


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

Как мерять правильно
Total votes 151: ↑145 and ↓6 +139
Views 298K
Comments 164

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

Configuring Linux *System administration *Server optimization *
Sandbox
Навеяно постом уважаемого 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 секунд. Также для полноты картины измерим скорость линейной записи.
Читать дальше →
Total votes 21: ↑12 and ↓9 +3
Views 25K
Comments 21

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

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

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

High performance *
Sandbox

Предыстория


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

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

Ниже я опишу такой способ, который был с успехом опробован. Для опытов был взят самый заслуженный дистрибутив Linux — Debian.
Читать дальше →
Total votes 83: ↑74 and ↓9 +65
Views 113K
Comments 165

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

WestComp corporate blog
Мы постоянно сталкиваемся с типовой задачей о развёртывании офисного сервера для различных компаний. Чаще всего клиент хочет купить сервер, на котором будут работать офисная почта, например, 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.
Читать дальше →
Total votes 12: ↑10 and ↓2 +8
Views 18K
Comments 8

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

WestComp corporate blog

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

Сейчас же, решили сравнить производительность СХД начального уровня и массива на контроллере 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)



Читать дальше →
Total votes 11: ↑9 and ↓2 +7
Views 7.3K
Comments 6

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

System administration *IT Infrastructure *Virtualization *Server optimization *Data storage *
Tutorial

Введение




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

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

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

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

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

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

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

High performance *Configuring Linux *System administration *IT Infrastructure **nix *
Тестируем производительность ZFS и mdadm+ext4 на SSD Sandisk CloudSpeed
для выбора технологии создания локального дискового массива.


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

image
Читать дальше →
Total votes 13: ↑9 and ↓4 +5
Views 22K
Comments 65

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

Nutanix corporate blog System administration *Virtualization *Cloud computing *Data storage *
— Штурман, приборы!
— 36!
— Что 36?
— А что приборы?

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

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

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

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

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

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

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

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

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

Обещаю, я буду осторожен
Total votes 90: ↑86 and ↓4 +82
Views 73K
Comments 159

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

Southbridge corporate blog System administration *Server Administration *DevOps *
Translation


Короткая история о 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]
Читать дальше →
Total votes 25: ↑25 and ↓0 +25
Views 4.2K
Comments 2

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

АЭРОДИСК corporate blog System administration *Server Administration *Data storage *Data storages *


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

Читать дальше →
Total votes 7: ↑5 and ↓2 +3
Views 5.9K
Comments 23

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

АЭРОДИСК corporate blog System administration *IT Infrastructure *Server Administration *Data storage *
Recovery mode


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

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

АЭРОДИСК corporate blog System administration *Server Administration *Data storage *Data storages *


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

Читать дальше →
Total votes 11: ↑11 and ↓0 +11
Views 3.5K
Comments 12

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

АЭРОДИСК corporate blog System administration *Server Administration *Data storage *Data storages *


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

Читать дальше →
Total votes 7: ↑7 and ↓0 +7
Views 3.3K
Comments 7

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

Флант corporate blog System administration *Data storages *Kubernetes *
Translation
Прим. перев.: эта статья — итоги мини-исследования, проведенного инженерами IBM Cloud в поисках решения реальной проблемы, связанной с эксплуатацией базы данных etcd. Для нас была актуальна схожая задача, однако ход размышлений и действий авторов может быть интересен и в более широком контексте.



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


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