Рубрика «fio»

в 9:34, , рубрики: etcd, fdatasync, fio, kubernetes, Блог компании Флант, производительность, системное администрирование, хранилища данных

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

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

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

Производительность кластера etcd сильно зависит от скорости хранилища, лежащего в его основе. Для контроля за производительностью etcd экспортирует различные метрики Prometheus. Одной из них является wal_fsync_duration_seconds. В документации к etcd говорится, что хранилище можно считать достаточно быстрым, если 99-й процентиль этой метрики не превышает 10 мс…Читать полностью »

в 14:42, , рубрики: devops, etcd, fio, k8s, linux, prometheus, storage, Блог компании Southbridge, Серверное администрирование, системное администрирование

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

Короткая история о 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]

Читать полностью »

в 9:15, , рубрики: fio, linux, mdadm, raid, zfs, виртуализация, высокая производительность, Настройка Linux, системное администрирование, СХД

Тестируем производительность ZFS и mdadm+ext4 на SSD Sandisk CloudSpeed
для выбора технологии создания локального дискового массива.

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

image
Читать полностью »

в 13:03, , рубрики: 7-zip, benchmark, C, CoreMark, E2K, fio, gcc, intel atom, Intel Core i7, iperf, java, LCC, Linpack, linux, mplayer, openssl, Pgbench, postgresql, R500, SciMark, sparc, SPECjvm, UnixBench, Железо, МСВС, МЦСТ, Софт, Эльбрус

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

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

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

Читать полностью »

в 9:22, , рубрики: fio, IOPS, latency, linux, tmpfs, высокая производительность, Настройка Linux, рамдиск, скорость работы, метки:

Предыстория

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

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

Ниже я опишу такой способ, который был с успехом опробован. Для опытов был взят самый заслуженный дистрибутив Linux — Debian.
Читать полностью »

в 12:07, , рубрики: fio, ssd caching, ssd кэш, vflash, vFRC, VMware ESXi 5.5 Update 2, vSphere, vSphere 5.5, Блог компании ИТ-ГРАД, ИТ-ГРАД, ит-инфраструктура, Облачные вычисления, хостинг, метки: ,

Компания VMware еще с выходом VMware vSphere 5.1 объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, включая возможность использования распределенного кеш на SSD-накопителях локальных дисков серверов ESXi. Данная технология имела рабочее название vFlash и находилась в стадии Tech Preview, превратившись позднее в полноценную функцию vSphere Flash Read Cache (vFRC) платформы VMware vSphere 5.5. И это вполне рабочий инструмент, который можно использовать в задачах различного уровня.
Читать полностью »

в 5:02, , рубрики: disk performance, fio, hdd, IOPS, linux, performance tests, ssd, дисковая подсистема, Серверная оптимизация, системное администрирование, метки: , , , , , , ,

Навеяно постом уважаемого 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. SATA-диск consumer-level Hitachi Deskstar HDS723020BLA642 2 ТБ 7200 об/мин, 64 Мбайт
  5. SATA-диск enterprise-level Western Digital RE3 WD2502ABYS-23B7A0 250 GB 7200 об/мин 16 Мбайт
  6. SATA-диск consumer-level Seagate Barracuda 7200.11 ST3320613AS 320 GB 7200 об/мин 16 Mбайт
  7. CD-ROM
  8. 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 секунд. Также для полноты картины измерим скорость линейной записи.Читать полностью »

в 10:10, , рубрики: disk performance, fio, hdd, IOPS, linux, NAS, performance tests, SAN, ssd, дисковая подсистема, Серверная оптимизация, системное администрирование, СХД, метки: , , , , , , , , , ,

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

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

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

  • научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
  • использование bonnie++
  • использование iozone
  • использование пачки cp с измерениема времени выполнения
  • использование iometer с dynamo на 64-битных системах

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

Читать полностью »

Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js