Летом прошлого года мы опубликовали статью о дисковых накопителях 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, но в очень устаревшем варианте, поэтому мы рекомендуем собрать свежую версию из исходного кода).
А вот его основные технические характеристики (взяты с официального сайта Intel):
| Характеристика | Значение |
| Объём | 750ГБ |
| Производительность при выполнении операций последовательного чтения, МБ/с | 2500 |
| Производительность при выполнении операций последовательной записи, МБ/с | 2200 |
| Производительность при выполнении операций случайного чтения, IOPS | 550000 |
| Производительность при выполнении операций случайной записи, IOPS | 550000 |
| Задержка при выполнении операции чтения (latency) | 10 µs |
| Задержка при выполнении операции записи | 10 µs |
| Износостойкость, PBW* | 41.0 |
*PBW — сокращение от Petabytes written. Эта характеристика обозначает количество информации, которое можно записать на диск в течение всего жизненного цикла.
На первый взгляд все смотрится очень впечатляюще. Но цифрам, приводимым в маркетинговых материалах, многие (и не без оснований) привыкли не доверять. Поэтому не лишним будет их проверить, а также провести некоторые дополнительные эксперименты.
Начнём мы с достаточно простых синтетических тестов, а затем проведём испытания в условиях, максимально приближенных к реальной практике.
Конфигурация тестового стенда
Коллеги из 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 ГБ | 400k | 324k | 2663 | 2382 | 399k | 362k | 373k | 76.1k |
| Intel P4510 | 1 TБ | 335k | 179k | 2340 | 504 | 142k | 143k | 12.3k | 73.5k |
| Micron MTFDHA X1T6MCE |
1.6 ТБ | 387k | 201k | 2933 | 754 | 80.6k | 146k | 8425 | 27.4k |
Как видим, в некоторых тестах 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). Это очень сложная тема, которая требует отдельного рассмотрения. Публикация на эту теме появится в нашем блоге в ближайшее время.
Автор: AndreiYemelianov
