Анализ производительности накопителя Intel Optane SSD 750 GB - Академия Selectel
В панель
описание картинки

Анализ производительности накопителя Intel Optane SSD 750 GB

Тирекс Тирекс Самый зубастый автор 29 марта 2018

Летом прошлого года мы опубликовали статью о дисковых накопителях Intel Optane SSD и предложили всем желающим принять участие в бесплатном тестировании. Новинка вызвала большой интерес: наши пользователи пробовали применять Optane для научных расчётов, для работы с in-memory базами данных, для проектов в области машинного обучения. Мы сами давно собирались написать подробный обзор, но всё не […]

Изображение записи

Летом прошлого года мы опубликовали статью о дисковых накопителях Intel Optane SSD и предложили всем желающим принять участие в бесплатном тестировании. Новинка вызвала большой интерес: наши пользователи пробовали применять Optane для научных расчётов, для работы с in-memory базами данных, для проектов в области машинного обучения.

Мы сами давно собирались написать подробный обзор, но всё не доходили руки. Но совсем недавно подходящая возможность появилась: коллеги из Intel предоставили нам для тестирования новый Optane, ёмкостью 750 ГБ. О результатах наших экспериментов пойдёт речь ниже.

Intel Optane P4800X 750ГБ: общая информация и технические характеристики

Накопители Intel Optane SSD выпускаются по 20-нм технологическому процессу. Он существует в двух форм-факторах: в виде карты (HHHL (CEM3.0) — подробнее о том, что это такое, см. здесь) и U.2 15 мм.

У нас имеется диск в виде карты:

Он виден в BIOS и определяется системой без установки каких-либо драйверов и дополнительных программ (приводим пример для ОС Ubuntu 16.04):

$ lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 149.1G 0 disk
├─sda2 8:2 0 1K 0 part
├─sda5 8:5 0 148.1G 0 part
│ ├─vg0-swap_1 253:1 0 4.8G 0 lvm [SWAP]
│ └─vg0-root 253:0 0 143.3G 0 lvm /
└─sda1 8:1 0 976M 0 part /boot
nvme0n1 259:0 0 698.7G 0 disk

Более подробную информацию можно просмотреть с помощью утилиты nvme-cli (она включена в репозитории большинства современных дистрибутивов Linux, но в очень устаревшем варианте, поэтому мы рекомендуем собрать свежую версию из исходного кода):

Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1     PHKS7296002J750BGN   INTEL SSDPED1K750GA                      1         750.16  GB / 750.16  GB    512   B +  0 B   E2010325

А вот его основные технические характеристики (взяты с официального сайта Intel):

ХарактеристикаЗначение
Объём750ГБ
Производительность при выполнении операций последовательного чтения, МБ/с2500
Производительность при выполнении операций последовательной записи, МБ/с2200
Производительность при выполнении операций случайного чтения, IOPS550000
Производительность при выполнении операций случайной записи, IOPS550000
Задержка при выполнении операции чтения (latency)10 µs
Задержка при выполнении операции записи10 µs
Износостойкость, PBW41.0

На первый взгляд все смотрится очень впечатляюще. Но цифрам, приводимым в маркетинговых материалах, многие (и не без оснований) привыкли не доверять. Поэтому не лишним будет их проверить, а также провести некоторые дополнительные эксперименты.

Начнём мы с достаточно простых синтетических тестов, а затем проведём испытания в условиях, максимально приближенных к реальной практике.

Конфигурация тестового стенда

Коллеги из Intel (за что им огромное спасибо) предоставили нам сервер со следующими техническими характеристиками:

  • материнская плата — Intel® R2208WFTZS;
  • процессор — Intel® Xeon® Gold 6154 (24.75M Cache, 3.00 GHz);
  • память — 192GB DDR4;
  • Intel® SSD DC S3510 (на этот диск была установлена ОС);
  • Intel® Optane™ SSD DC P4800X 750GB.

На сервере была установлена ОС Ubuntu 16.04 с ядром 4.13.

Обратите внимание! Чтобы получить хорошую производительность NVMe-накопителей, требуется версия ядра не ниже 4.10. С более ранними версиями ядра результаты будут хуже: поддержка NVMe в них надлежащим образом не реализована.

Для тестов мы использовали следующее ПО:

  • утилиту fio,  которая является де-факто стандартом в области измерения производительности дисков;
  • диагностические инструменты, разработанные Бренданом Греггом в рамках проекта iovisor;
  • утилита db_bench, созданная в Facebook и используемая для измерения производительности в хранилище данных rocksdb.

Синтетические тесты

Как уже было сказано выше, сначала мы рассмотрим результаты синтетических тестов. Их мы проводили с помощью утилиты fio версии 3.3.31, которую мы собирали из исходного кода.

В соответствии с принятой у нас методикой в тестах использовались следующие профили нагрузок:

  • случайная запись/чтение блоками по 4 Kб, глубина очереди — 1;
  • случайная запись/чтение блоками по 4 Kб, глубина очереди — 16;
  • случайная запись/чтение блоками по 4 М, глубина очереди — 32;
  • случайная запись/чтение блоками по 4 Kб, глубина очереди — 128.

Приведём пример конфигурационного файла:

[readtest]
blocksize=4M
filename=/dev/nvme0n1
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=32
runtime=1200

[writetest]
blocksize=4M filename=/dev/nvme0n1 rw=randwrite direct=1 buffered=0 ioengine=libaio iodepth=32

Каждый тест выполнялся в течение 20 минут; по завершении мы заносили все интересующие нас показатели в таблицу (см. ниже).

Наибольший интерес для нас будет представлял такой параметр, как число операций ввода-вывода в секунду (IOPS). В тестах на чтение и запись блоков по 4M в таблицу внесен размер полосы пропускания (bandwidth).

Для наглядности мы приводим результаты не только для Optane, но и для других NVMe-накопителей: это Intel P 4510, а также диск другого производителя — Micron:

Модель дискаЁмкость диска, ГБrandread

 

 

4k

iodepth

=128

randwrite

 

 

4k

iodepth

=128

randread

 

 

4M

iodepth

=32

randwrite

 

 

4M

iodepth

=32

randread

 

 

4k

iodepth

=1

randwrite

 

 

4k

iodepth

=16

randread

 

 

4k

iodepth

=1

randwrite

 

 

4k

iodepth

=1

Intel P4800 X 750 ГБ4000003240002663238239900036200037300076100
Intel P45101 TБ33500017900023405041420001430001230073500
Micron MTFDHA

 

 

X1T6MCE

1.6 ТБ387000201000293375480600146000842527400

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

Но чтобы выносить более или менее объективные суждения о производительности диска, одного только количества IOPS явно недостаточно. Этот параметр сам по себе ничего не значит вне связи с другим — временем задержки (latency).

Latency — это промежуток времени, в течение которого выполняется запрос на операцию ввода-вывода, отправленный приложением. Измеряется он при помощи всё той же утилиты fio. По завершении всех тестов она выдаёт на консоль следующий вывод (приводим лишь небольшой фрагмент):

Jobs: 1 (f=1): [w(1),_(11)][100.0%][r=0KiB/s,w=953MiB/s][r=0,w=244k IOPS][eta 00m:00s]
writers: (groupid=0, jobs=1): err= 0: pid=14699: Thu Dec 14 11:04:48 2017
write: IOPS=46.8k, BW=183MiB/s (192MB/s)(699GiB/3916803msec)
slat (nsec): min=1159, max=12044k, avg=2379.65, stdev=3040.91
clat (usec): min=7, max=12122, avg=168.32, stdev=98.13
lat (usec): min=11, max=12126, avg=170.75, stdev=97.11
clat percentiles (usec):
| 1.00th=[ 29], 5.00th=[ 30], 10.00th=[ 40], 20.00th=[ 47],
| 30.00th=[ 137], 40.00th=[ 143], 50.00th=[ 151], 60.00th=[ 169],
| 70.00th=[ 253], 80.00th=[ 281], 90.00th=[ 302], 95.00th=[ 326],
| 99.00th=[ 363], 99.50th=[ 379], 99.90th=[ 412], 99.95th=[ 429],
| 99.99th=[ 457]

Обратите внимание на следующий фрагмент:

slat (nsec): min=1159, max=12044k, avg=2379.65, stdev=3040.91
clat (usec): min=7, max=12122, avg=168.32, stdev=98.13
lat (usec): min=11, max=12126, avg=170.75, stdev=97.11

Это и есть значения latency, которые мы получили во время теста. Наибольший интерес для нас представляет
Slat — это время отправки запроса (т.е. параметр, который имеет отношение к производительности подсистемы ввода-вывода Linux, но не диска), а clat — это так называемая complete latency, т.е. время выполнения запроса, поступившего от устройства (именно этот параметр нас и интересует). О том, как анализировать эти цифры, неплохо написано в этой статье, опубликованной пять лет назад, но актуальности при этом не утратившей.

Fio — это общепринятая и хорошо зарекомендовавшая себя утилита, однако иногда в реальной практике возникают ситуации, когда нужно получить более точную информации о времени задержки и выявить возможные причины, если значение этого показателя слишком высоко. Инструменты для более точной диагностики разрабатываются в рамках проекта iovisor (см. также репозиторий на GitHub.  Все эти инструменты построены на базе механизма eBPF (extended  Berkeley Packet Filters.  В наших тестах мы попробовали утилиту  biosnoop (см. исходный код здесь. Она отслеживает все операции ввода-вывода в системе и измеряет время задержки для каждой из них.

Это бывает очень полезно, если возникают проблемы с производительностью диска, к которому выполняется большое количество запросов на чтение и запись (например, на диске размещена база данных для какого-нибудь высоконагруженного веб-проекта).

Мы начали с самого простого варианта: запускали стандартные тесты fio и замеряли latency для каждой операции с помощью biosnoop, которую запускали в другом терминале. Во время работы biosnoop пишет в стандартный вывод следующую таблицу:

TIME(s)       COMM PID      DISK T  SECTOR     BYTES     LAT(ms)
300.271456000 fio  34161 nvme0n1 W  963474808   4096    0.01
300.271473000 fio  34161 nvme0n1 W  1861294368  4096    0.01
300.271491000 fio  34161 nvme0n1 W  715773904   4096    0.01
300.271508000 fio  34161 nvme0n1 W  1330778528  4096    0.01
300.271526000 fio  34161 nvme0n1 W  162922568   4096    0.01
300.271543000 fio  34161 nvme0n1 W  1291408728  4096    0.01

Эта таблица состоит из 8 столбцов:

  • TIME — время совершения операции в формате Unix Timestamp;
  • COMM — имя процесса, выполнившего операцию;
  • PID — PID процесса, выполнившего операцию;
  • T — тип операции (R — read, W — write);
  • SECTOR — сектор, куда осуществлялась запись;
  • BYTES — размер записываемого блока;
  • LAT (ms) — время задержки для операции.

Мы провели много измерений для разных дисков и обратили внимание на следующее: для Optane в течение всего теста (а продолжительность тестов при этом варьировалась от 20 минут до 4 часов) значение параметра latency оставалось неизменным и соответствовало заявленному в таблице выше значению 10 µs, в то время как у других накопителей наблюдались колебания.

По полученным результатам синтетических тестов вполне можно вполне предположить, что Optane и под высокой нагрузкой будет показывать хорошую производительность и самое главное — низкое время задержки. Поэтому мы решили на чистой “синтетике” не останавливаться и провести тест с реальными (или по крайней мере максимально приближенными к реальным) нагрузками.

Для этого мы воспользовались утилитами для измерения производительности, которые входят в состав RocksDB — интересным и набирающим популярность хранилищем пар “ключ — значение”, разработанным в Facebook. Ниже мы подробно опишем проведённые тесты и проанализируем их результаты.

Optane и RocksDB: тесты производительности

Почему RocksDB

В последние годы широкое резко возросла потребность в отказоустойчивых хранилищах больших объёмов данных. Они находят применение в самых разных областях: социальные сети, корпоративные информационные системы, мессенджеры, облачные хранилища и других. Программные решения для таких хранилищ, как правило, построены на базе так называемых LSM-деревьев — в качестве примера можно привести Big Table, HBase, Cassandra, LevelDB, Riak, MongoDB, InfluxDB. Работа с ними сопряжена с серьёзными нагрузками, в том числе и на дисковую подсистему — см., например, здесь. Optane со всей износостойкостью и долговечностью мог бы стать вполне подходящим решением.

RocksdDB (см. также репозиторий на GitHub) — это хранилище типа «ключ-значение», разработанное в Facebook и являющееся форком небезызвестного проекта LevelDB. Оно используется для решения широкого круга задач: от организации storage engine для MySQL до кэширования данных приложений.

Мы выбрали именно его для наших тестов, руководствуясь следующими соображениями:

  • RocksDB позиционируется как хранилище, созданное специально для быстрых накопителей, в том числе и NVMe;
  • RocksDB успешно используется в высоконагруженных проектах Facebook;
  • в состав RocksDB входят интересные утилиты для тестирования, создающие очень серьёзную нагрузку (подробности см. ниже);
  • наконец, нам было просто интересно взглянуть, как Optane с его надёжностью и устойчивостью выдержит большие нагрузки.

Все описанные ниже тесты проводились на двух дисках:

  • Intel Optane SSD 750 GB;
  • Micron MTFDHAX1T6MCE.

Подготовка к тестированию: компиляция RocksDB и создание базы

RocksDB мы собрали из исходного кода, опубликованного на GitHub (здесь и далее приводятся примеры команд для Ubuntu 16.04):

$ sudo apt-get install libgflags-dev libsnappy-dev zlib1g-dev libbz2-dev liblz4-dev libzstd-dev gcc g++ clang make git
$ git clone https://github.com/facebook/rocksdb/
$ cd rocksdb
$ make all

После установки требуется подготовить к тесту диск, куда будут записываться данные.
В официальной документации с RocksDB рекомендуется использовать файловую систему XFS, которую мы и создадим на нашем Optane:

$ sudo apt-get install xfsprogs
$ mkfs.xfs -f /dev/nvme0n1

$ mkdir /mnt/rocksdb
$ mount -t xfs /dev/nvme0n1 /mnt/rocksdb

На этом подготовительная работа завершена, и можно переходить к созданию базы данных.
RocksDB не является СУБД в классическом смысле слова, и чтобы создать базу данных, потребуется написать небольшую программу на C или С++. Примеры таких программ (1 и 2) имеются в официальном репозитории RocksDB в директории examples. В исходный код нужно будет внести некоторые изменения и указать правильный путь к базе. В нашем случае это выглядит так:

$ cd rockdb/examples
$ vi simple_example.cc

В этом файле нужно найти строку

std::string kDBPath ="/tmp/rocksdb_simple_example"

И прописать в ней путь к нашей базе:

std::string kDBPath ="/mnt/rocksdb/testdb1"

После этого нужно переходить к компиляции:

$ make
$ ./simple_example

В результате выполнения этой команды в указанной директории будет создана база. Мы будем в неё записывать (и считывать из неё) данные в наших тестах. Тестировать мы будем с помощью утилиты db_bench; соответствующий бинарный файл есть в корневой директории RocksDB.

Методика тестирования подробно описана на официальной wiki-странице проекта.

Если вы внимательно прочтёте текст по ссылке, то увидите, что смысл теста заключается в записи одного миллиарда ключей в базу (и в последующем чтении данных из этой базы). Суммарный объём всех данных составляет около 800 ГБ. Мы такого себе позволить мне можем: объём нашего Optane составляет всего 750 ГБ. Поэтому число ключей в нашем тесте мы сократили ровно вдвое : не один миллиард, а 500 миллионов. Для демонстрации возможностей Optane и этой цифры вполне достаточно.

В нашем случае объём записываемых данных составит примерно 350 ГБ.
Хранятся все эти данные в формате SST(сокращение от Sorted String Table; см. также  эту статью). На выходе мы получим несколько тысяч так называемых SST-файлов (подробнее можно почитать здесь.

Перед запуском теста нужно обязательно увеличить лимит на число одновременно открытых файлов в системе, иначе ничего не получится: примерно через 15 — 20 минут после начала теста мы увидим сообщение Too many open files.

Чтобы всё прошло, как надо, выполним команду ulimit c опцией n:

$ ulimit -n

По умолчанию в системе установлен лимит на 1024 файла. Во избежание проблем мы сразу увеличим его до миллиона:

$ ulimit -n 1000000

Обратите внимание: после перезагрузки этот лимит не сохраняется и возвращается к значению по умолчанию.

Вот и всё, подготовительные работы завершены. Переходим к описанию непосредственно тестов и разбору результатов.

Описание тестов

Вводные замечания

Опираясь на методику, описанную по ссылке выше, мы провели следующие тесты:

  • массовая загрузка ключей в последовательном порядке;
  • массовая загрузка ключей в случайном порядке;
  • случайная запись;
  • случайное чтение.

Все тесты проводились с помощью утилиты db_bench, исходный код которой можно найти в репозитории rocksdb.

Размер каждого ключа составляет 10 байт, а размер значения — 800 байт.
Рассмотрим результаты каждого теста более подробно.

Тест 1. Массовая загрузка ключей в последовательном порядке

Для запуска этого теста мы использовали те же параметры, что указаны в инструкции по ссылке выше. Изменили мы только количество записываемых ключей (об этом мы уже упоминали): не 1 000 000 000, а 500 000 000.
В самом начале база пуста; она заполняется во время теста. Во время загрузки данных никакого чтения не производится.

Команда db_bench для запуска теста выглядит так:

bpl=10485760;mcz=2;del=300000000;levels=6;ctrig=4; delay=8; stop=12; wbn=3; \
mbc=20; mb=67108864;wbs=134217728; sync=0; r=50000000 t=1; vs=800; \
bs=4096; cs=1048576; of=500000; si=1000000; \
./db_bench \
--benchmarks=fillseq --disable_seek_compaction=1 --mmap_read=0 \
--statistics=1 --histogram=1 --num=$r --threads=$t --value_size=$vs \
--block_size=$bs --cache_size=$cs --bloom_bits=10 --cache_numshardbits=6 \
--open_files=$of --verify_checksum=1 --sync=$sync --disable_wal=1 \
--compression_type=none --stats_interval=$si --compression_ratio=0.5 \
--write_buffer_size=$wbs --target_file_size_base=$mb \
--max_write_buffer_number=$wbn --max_background_compactions=$mbc \
--level0_file_num_compaction_trigger=$ctrig \
--level0_slowdown_writes_trigger=$delay \
--level0_stop_writes_trigger=$stop --num_levels=$levels \
--delete_obsolete_files_period_micros=$del --min_level_to_compress=$mcz \
--stats_per_interval=1 --max_bytes_for_level_base=$bpl \
--use_existing_db=0 --db=/mnt/rocksdb/testdb

Команда содержит множество опций, которые просто необходимо прокомментировать: они будут использоваться и в последующих тестах. В самом начале мы задаём значения важных параметров:

  • bpl ― максимальное количество байт на один уровень;
  • mcz ― минимальный уровень сжатия;
  • del ― промежуток времени, по истечении которого нужно удалять устаревшие файлы;
  • levels ― количество уровней;
  • ctrig ― количество файлов, по достижении которого нужно начинать сжатие;
  • delay ― время, по истечении которого нужно замедлить скорость записи;
  • stop ― время, по истечении которого нужно прекратить запись;
  • wbn ― максимальное число буферов записи;
  • mbc ― максимальное число фоновых сжатий;
  • mb ― максимальное число буферов записи;
  • wbs ― размер буфера записи;
  • sync ― включить/отключить синхронизацию;
  • r ― количество пар “ключ-значение”, которые будут записываться в базу;
  • t ― количество потоков;
  • vs ― величина значения;
  • bs ― размер блока;
  • сs ― размер кэша;
  • оf ― количество открытых файлов (не работает, см. комментарий по этому по поводу выше);
  • si ― периодичность сбора статистики.

Об остальных параметрах можно подробнее прочитать, выполнив команду

./db_bench --help

Подробные описания всех опций также приведены здесь.

Какие результаты показал тест? Операция последовательной загрузки была выполнена за 23 минуты. Скорость записи при этом составила 536,78 МБ/с.
Для сравнения: на NVMe-накопителе Micron эта же процедура занимает чуть больше 30 минут, а скорость записи составляет 380.31 МБ/с.

Тест 2. Массовая загрузка ключей в случайном порядке

Для тестирования случайной записи использовались следующие настройки db_bench (приводим полный листинг команды):

bpl=10485760;mcz=2;del=300000000;levels=2;ctrig=10000000; delay=10000000; stop=10000000; wbn=30; mbc=20; \
mb=1073741824;wbs=268435456; sync=0; r=50000000; t=1; vs=800; bs=65536; cs=1048576; of=500000; si=1000000; \
./db_bench \
--benchmarks=fillrandom --disable_seek_compaction=1 --mmap_read=0 --statistics=1 --histogram=1 \
--num=$r --threads=$t --value_size=$vs --block_size=$bs --cache_size=$cs --bloom_bits=10 \
--cache_numshardbits=4 --open_files=$of --verify_checksum=1 \
--sync=$sync --disable_wal=1 --compression_type=zlib --stats_interval=$si --compression_ratio=0.5 \
--write_buffer_size=$wbs --target_file_size_base=$mb --max_write_buffer_number=$wbn \
--max_background_compactions=$mbc --level0_file_num_compaction_trigger=$ctrig \
--level0_slowdown_writes_trigger=$delay --level0_stop_writes_trigger=$stop --num_levels=$levels \
--delete_obsolete_files_period_micros=$del --min_level_to_compress=$mcz \
--stats_per_interval=1 --max_bytes_for_level_base=$bpl --memtablerep=vector --use_existing_db=0 \
--disable_auto_compactions=1 --allow_concurrent_memtable_write=false --db=/mnt/rocksdb/testb1

Выполнение этого теста заняло у нас 1 час 6 минут, а скорость записи при этом составила 273.36 МБ/с. На Microne тест выполняется за 3 часа 30 минут, а скорость записи при этом колеблется: среднее значение — 49.7 МБ/с.

Тест 3. Случайная запись

В этом тесты мы попробовали перезаписать 500 миллионов ключей в созданную ранее базу данных.
Приводим полный листинг команды db_bench:

bpl=10485760;mcz=2;del=300000000;levels=6;ctrig=4; delay=8; stop=12; wbn=3; \
mbc=20; mb=67108864;wbs=134217728; sync=0; r=500000000; t=1; vs=800; \
bs=65536; cs=1048576; of=500000; si=1000000; \
./db_bench \
--benchmarks=overwrite --disable_seek_compaction=1 --mmap_read=0 --statistics=1 \
--histogram=1 --num=$r --threads=$t --value_size=$vs --block_size=$bs \
--cache_size=$cs --bloom_bits=10 --cache_numshardbits=4 --open_files=$of \
--verify_checksum=1 --sync=$sync --disable_wal=1 \
--compression_type=zlib --stats_interval=$si --compression_ratio=0.5 \
--write_buffer_size=$wbs --target_file_size_base=$mb --max_write_buffer_number=$wbn \
--max_background_compactions=$mbc --level0_file_num_compaction_trigger=$ctrig \
--level0_slowdown_writes_trigger=$delay --level0_stop_writes_trigger=$stop \
--num_levels=$levels --delete_obsolete_files_period_micros=$del \
--min_level_to_compress=$mcz --stats_per_interval=1 \
--max_bytes_for_level_base=$bpl --use_existing_db=/mnt/rocksdb/testdb

В этом тесте был получен очень хороший результат: 2 часа 51 минута со скоростью 49 МБ/с (в моменте снижалась до 38 МБ/c).

На Microne выполнение теста занимает чуть больше — 3 часа 16 минут; скорость примерно такая же, но колебания выражены более отчётливо.

Тест 4. Случайное чтение

Смысл этого теста заключается в случайном чтении 500 000 000 ключей из базы. Приведём полный, со всеми опциями, листинг команды db_bench:

bpl=10485760;mcz=2;del=300000000;levels=6;ctrig=4; delay=8; stop=12; wbn=3; \
mbc=20; mb=67108864;wbs=134217728; sync=0; r=500000000; t=1; vs=800; \
bs=4096; cs=1048576; of=500000; si=1000000; \
./db_bench \
--benchmarks=fillseq --disable_seek_compaction=1 --mmap_read=0 \
--statistics=1 --histogram=1 --num=$r --threads=$t --value_size=$vs \
--block_size=$bs --cache_size=$cs --bloom_bits=10 --cache_numshardbits=6 \
--open_files=$of --verify_checksum=1 --sync=$sync --disable_wal=1 \
--compression_type=none --stats_interval=$si --compression_ratio=0.5 \
--write_buffer_size=$wbs --target_file_size_base=$mb \
--max_write_buffer_number=$wbn --max_background_compactions=$mbc \
--level0_file_num_compaction_trigger=$ctrig \
--level0_slowdown_writes_trigger=$delay \
--level0_stop_writes_trigger=$stop --num_levels=$levels \
--delete_obsolete_files_period_micros=$del --min_level_to_compress=$mcz \
--stats_per_interval=1 --max_bytes_for_level_base=$bpl \
--use_existing_db=0
bpl=10485760;overlap=10;mcz=2;del=300000000;levels=6;ctrig=4; delay=8; \
stop=12; wbn=3; mbc=20; mb=67108864;wbs=134217728; sync=0; r=500000000; \
t=32; vs=800; bs=4096; cs=1048576; of=500000; si=1000000; \
./db_bench \
--benchmarks=readrandom --disable_seek_compaction=1 --mmap_read=0 \
--statistics=1 --histogram=1 --num=$r --threads=$t --value_size=$vs \
--block_size=$bs --cache_size=$cs --bloom_bits=10 --cache_numshardbits=6 \
--open_files=$of --verify_checksum=1 --sync=$sync --disable_wal=1 \
--compression_type=none --stats_interval=$si --compression_ratio=0.5 \
--write_buffer_size=$wbs --target_file_size_base=$mb \
--max_write_buffer_number=$wbn --max_background_compactions=$mbc \
--level0_file_num_compaction_trigger=$ctrig \
--level0_slowdown_writes_trigger=$delay \
--level0_stop_writes_trigger=$stop --num_levels=$levels \
--delete_obsolete_files_period_micros=$del --min_level_to_compress=$mcz \
--stats_per_interval=1 --max_bytes_for_level_base=$bpl \
--use_existing_db=1

Как видно из приведённых команд, этот тест состоит из двух операций: сначала мы записываем в базу ключи, а потом их читаем. По завершении записи утилита db_bench случайным образом выбирала из базы ключ и выполняла операцию чтения.
Операция чтения осуществлялась в 32 потока. При каждой операции чтения осуществлялась проверка контрольной суммы.
На Optane выполнение теста заняло 5 часов 2 минуты, на Microne — около 6 часов.

Заключение

В этой статье мы описали тесты производительности накопителя Intel Optane SSD объёмом 750 ГБ. Как показывают результаты, диск показывает высокую производительность и стабильность. Даже при большой загрузке мы не наблюдали деградации производительности, а время задержки оставалось практически неизменным. Ещё раз выражаем коллегам из Intel огромную благодарность за предоставленную возможность познакомиться с новинкой.

Как мы уже писали, диски Optane хорошо подойдут для использования в высоконагруженных сервисах или корпоративных СХД. Но лучше один раз увидеть, чем сто раз услышать. Мы до сих пор предлагаем Optane для бесплатного тестирования всем желающим. Условия те же: мы даём вам доступ к тестовому серверу, а вы пишете обзор и публикуете его в любом открытом источнике.
А если вы уже готовы использовать Optane на постоянной основе, то выделенные серверы соответствующей конфигурации уже доступны для заказа в наших дата-центрах.

В этой статье мы не затронули вопросы использования технологии IMDT (Intel Memory Drive). Это очень сложная тема, которая требует отдельного рассмотрения. Публикация на эту теме появится в нашем блоге в ближайшее время.

Читайте также: