750GB Intel Optane SSDドライブのパフォーマンス分析

昨年の夏、インテルOptane SSDディスクドライブに関する記事を公​​開し、 無料のテストに参加するよう全員に招待しました 。 ノベルティは大きな関心を呼びました：ユーザーは、機械学習の分野のプロジェクトで、 メモリ内のデータベースを操作するために、 科学的な計算にOptaneを使用しようとしました。

私たちは長い間詳細なレビューを書くつもりでしたが、すべてが手に届きませんでした。 しかし、つい最近、適切な機会が現れました。Intelの同僚が、テスト用に750 GBの容量を持つ新しいOptaneを提供してくれました。 私たちの実験の結果を以下に説明します。

Intel Optane P4800X 750GB：一般情報と仕様

Intel Optane SSDは20nmプロセスで利用可能です。 2つのフォームファクターで存在します：マップの形式（HHHL（CEM3.0）-詳細はこちらを参照）とU.2 15 mm。

カードの形のディスクがあります。





BIOSに表示され、ドライバーと追加プログラムをインストールせずにシステムによって決定されます（Ubuntu 16.04 OSの例を示します）。

$ 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 Webサイトから取得）

特徴	価値
ボリューム	750GB
シーケンシャル読み取りパフォーマンス、MB / s	2500
順次書き込み操作中のパフォーマンス、MB / s	2200
ランダム読み取りパフォーマンス、IOPS	550000
ランダム書き込みパフォーマンス、IOPS	550000
読み取り操作の遅延	10 µs
録音中の遅延	10 µs
耐摩耗性、PBW *	41.0

* PBWは、書き込まれたペタバイトの略です。 この特性は、ライフサイクル全体でディスクに書き込むことができる情報の量を示します。

一見、すべてが非常に印象的です。 しかし、マーケティング資料に記載されている数字の多く（理由がないわけではありません）は、信頼しないことに慣れています。 したがって、それらを確認したり、追加の実験を行ったりする必要はありません。

かなり単純な模擬テストから始め、実際の練習に可能な限り近い条件でテストを実施します。

テストベッド構成

Intelの同僚（多くの人に感謝します）は、次の技術仕様のサーバーを提供してくれました。

• マザーボード-Intel R2208WFTZS;
• プロセッサー-Intel Xeon Gold 6154（24.75Mキャッシュ、3.00 GHz）;
• メモリ-192GB DDR4;
• Intel SSD DC S3510（OSはこのディスクにインストールされました）;
• Intel Optane™SSD DC P4800X 750GB。

4.13カーネルのUbuntu 16.04 OSがサーバーにインストールされました。

注意してください！ NVMeドライブの良好なパフォーマンスを得るには、少なくとも4.10のカーネルバージョンが必要です。 以前のバージョンのカーネルでは、結果はさらに悪くなります。NVMeサポートが適切に実装されていません。

テストでは、次のソフトウェアを使用しました。

• fioユーティリティ。ディスクパフォ​​ーマンスを測定する分野の事実上の標準です。
• iovisorプロジェクトの一部としてBrendan Greggによって開発された診断ツール。
• Facebookで作成され、 rocksdbデータウェアハウスのパフォーマンスを測定するために使用されるdb_benchユーティリティ。

模擬試験

前述のように、最初に合成テストの結果を確認します。 ソースコードから収集したfioユーティリティバージョン3.3.31を使用して実行しました。

方法論に従って、テストでは次の負荷プロファイルを使用しました。

• 4 Kbのブロックでのランダムな書き込み/読み取り、キューの深さ-1。
• 4 Kbのブロックでのランダムな書き込み/読み取り、キューの深さ-16。
• 4 Mのブロックでのランダムな書き込み/読み取り、キューの深さ-32;
• 4 Kbのブロックでのランダムな書き込み/読み取り、キューの深さ-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分間実行されました。 完了したら、関心のあるすべての指標を表に入力しました（以下を参照）。

私たちにとって最も興味深いのは、1秒あたりの入出力操作数（IOPS）などのパラメーターです。 各4Mのブロックの読み取りと書き込みのテストでは、帯域幅のサイズ（帯域幅）がテーブルに入力されます。

わかりやすくするために、Optaneだけでなく、他のNVMeドライブの結果も表示します。これはIntel P 4510であり、他のメーカーのドライブです-Micron ：

駆動モデル	ディスク容量GB	ランドリード 4k 十二面体 = 128	randwrite 4k 十二面体 = 128	ランドリード 4M 十二面体 = 32	randwrite 4M 十二面体 = 32	ランドリード 4k 十二面体 = 1	randwrite 4k 十二面体 = 16	ランドリード 4k 十二面体 = 1	randwrite 4k 十二面体 = 1
Intel P4800 X	750 GB	40万	324k	2663	2382	399k	362k	373k	76.1k
Intel P4510	1 TB	335k	179k	2340	504	142k	143k	12.3k	73.5k
ミクロンMTFDHA X1T6MCE	1.6 TB	387k	201k	2933	754	80.6k	146k	8425	27.4k

ご覧のとおり、一部のテストでは、Optaneは他のドライブの同様のテストの結果よりも数倍高い数値を示しています。

しかし、ディスクパフォ​​ーマンスについて多かれ少なかれ客観的な判断を下すためには、IOPSの数だけでは明らかに十分ではありません。 このパラメーター自体は、別のレイテンシーに関係なく何も意味しません。

待機時間とは、アプリケーションから送信されたI / O要求が実行される時間です。 同じ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 

これらは、テスト中に受け取ったレイテンシ値です。 私たちにとって最大の関心事は

Slatはリクエストが送信された時間（つまり、ディスクではなくLinux I / Oサブシステムのパフォーマンスに関連するパラメーター）であり、clatはいわゆる完全なレイテンシー、つまり デバイスから受信したリクエストの実行時間（このパラメーターが重要です）。 これらの数値を分析する方法は、5年前に公開されたこの記事に詳しく記載されていますが、その関連性は失われていません。

Fioは一般的に受け入れられ、定評のあるユーティリティですが、実際には、遅延時間に関するより正確な情報を取得し、このインジケーターの値が高すぎる場合に考えられる理由を特定する必要がある場合があります。 より正確な診断のためのツールは、 iovisorプロジェクトの一部として開発されています （ GitHubのリポジトリも参照してください。これらのツールはすべて、 eBPFメカニズム（拡張バークレーパケットフィルター）に基づいています。システムの入出力操作を実行し、それぞれの遅延時間を測定します。

これは、多数の読み取りおよび書き込み要求が実行されるディスクのパフォーマンスに問題がある場合（たとえば、負荷の高いWebプロジェクトのデータベースがディスク上にある場合）に非常に役立ちます。

最も単純なオプションから始めました。標準のfioテストを実行し、別の端末で実行された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タイムスタンプ形式の操作の時間。
• COMM-操作を実行したプロセスの名前。
• PID-操作を実行したプロセスのPID。
• T-操作のタイプ（R-読み取り、W-書き込み）;
• セクター -記録が行われたセクター。
• BYTES-記録されたブロックのサイズ。
• LAT（ms） -操作の遅延時間。

さまざまなディスクについて多くの測定を行い、次のことに注意を促しました：テスト全体（およびテストの期間は20分から4時間の範囲）のOptaneでは、レイテンシパラメーターは変更されず、上の表に記載されている10μsの値に対応しました他のドライブには変動があります。

合成テストの結果に基づいて、Optaneおよび高負荷下で優れたパフォーマンスを発揮し、最も重要なのは低レイテンシーであると想定することは完全に可能です。 そのため、純粋な「合成」にとどまらず、実際の（または少なくとも可能な限り実際の）負荷でテストを実行しないことにしました。

これを行うには、RocksDBに含まれるパフォーマンス測定ツールを使用しました。これは、Facebookによって開発された興味深い成長を続けるキーと値のペアのリポジトリです。 以下では、実行したテストの詳細を説明し、その結果を分析します。

OptaneおよびRocksDB：パフォーマンステスト

RocksDBを選ぶ理由

近年、大量のデータのフォールトトレラントストレージに対する需要が急激に拡大しています。 ソーシャルネットワーク、企業情報システム、インスタントメッセンジャー、クラウドストレージなど、さまざまな分野で応用されています。 このようなストレージのソフトウェアソリューションは、原則として、いわゆるLSMツリーに基づいて構築されます -例として、Big Table、HBase、Cassandra、LevelDB、Riak、MongoDB、InfluxDBを引用できます。 それらの操作には、ディスクサブシステムを含む深刻な負荷が伴います 。たとえば、 こちらを参照してください。 Optaneは、そのすべての耐久性と耐久性を備えており、完全に適切なソリューションとなります。

RocksdDB （ GitHubリポジトリも参照）は、Facebookによって開発されたKey-Valueリポジトリであり、悪名高いLevelDBプロジェクトのフォークです。 MySQLのストレージエンジンの編成からアプリケーションデータのキャッシュまで、さまざまなタスクを解決するために使用されます。

次の考慮事項に従って、テスト用に選択しました。

• RocksDBは、NVMeを含む高速ドライブ専用に作成されたストレージとして位置付けられています。
• RocksDBは、負荷の高いFacebookプロジェクトで正常に使用されています。
• RocksDBには、非常に深刻な負荷をかける興味深いテストユーティリティが含まれています（以下の詳細を参照）。
• 最後に、信頼性と安定性を備えたOptaneがどのように重い負荷に耐えられるかを知りたいと思いました。

以下で説明するすべてのテストは、2つのディスクで実行されました。

• Intel Optane SSD 750 GB
• ミクロンMTFDHAX1T6MCE

テストの準備：RocksDBのコンパイルとベースの作成

GitHubで公開されているソースコードからRocksDBをコンパイルしました（ここと以下は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の公式ドキュメントでは、Optaneで作成するXFSファイルシステムを使用することをお勧めします。

 $ sudo apt-get install xfsprogs $ mkfs.xfs -f /dev/nvme0n1 $ mkdir /mnt/rocksdb $ mount -t xfs /dev/nvme0n1 /mnt/rocksdb 

これで、準備作業が完了し、データベースの作成に進むことができます。
RocksDBは、古典的な意味でのDBMSではありません。データベースを作成するには、CまたはC ++で小さなプログラムを作成する必要があります。 そのようなプログラムの例（1および2）は、examplesディレクトリの公式RocksDBリポジトリにあります。 ソースコードにいくつかの変更を加え、データベースへの正しいパスを示す必要があります。 この場合、次のようになります。

 $ 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ページで詳細に説明されています 。

リンクのテキストを注意深く読むと、テストの意味は10億個のキーをデータベースに書き込むことであることがわかります（そして、このデータベースからのデータのその後の読み取りで）。 すべてのデータの合計量は約800 GBです。 Optaneのボリュームは750 GBしかありません。 したがって、テストのキー数を正確に半分に減らしました。10億ではなく、5億です。 Optaneの機能を実証するには、この数値で十分です。

この場合、記録されるデータの量は約350 GBです。

このデータはすべてSST形式で保存されます（ Sorted String Tableの略。 この記事も参照してください ）。 出力では、数千のいわゆるSSTファイルを取得します（詳細については、 こちらをご覧ください 。

テストを開始する前に、システムで同時に開くことができるファイルの数の制限を増やす必要があります。そうしないと何も機能しません。テストの開始から約15〜20分後に、「Too many open files」というメッセージが表示されます。

すべてが正常に実行されるように、nオプションを指定してulimitコマンドを実行します。

 $ ulimit -n 

デフォルトでは、システムには1024ファイルの制限があります。 問題を回避するために、すぐに100万に増やします。

 $ 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-古くなったファイルを削除する必要がある期間。
• レベル-レベルの数;
• ctrig-圧縮を開始する必要があるファイルの数。
• 遅延-記録速度を遅くする必要がある時間;
• stop-記録を停止する必要がある時間。
• wbn-書き込みバッファの最大数。
• mbcは、バックグラウンド圧縮の最大数です。
• mbは書き込みバッファの最大数です。
• wbs-書き込みバッファサイズ。
• sync-同期を有効/無効にします。
• rは、データベースに書き込まれるキーと値のペアの数です。
• tはスレッドの数です。
• vsは値です。
• bsはブロックサイズです。
• cs-キャッシュサイズ。
• f-開いているファイルの数（機能しません。上記のコメントを参照）;
• si-統計収集の頻度。

コマンドを実行して、残りのパラメーターの詳細を読むことができます

 ./db_bench --help 

すべてのオプションの詳細な説明もここに記載されています 。

テストではどのような結果が示されましたか？ 順次ダウンロード操作は23分で完了しました。 書き込み速度は536.78 MB / sでした。
比較のために：Micron NVMeドライブでは、同じ手順に30分強かかり、書き込み速度は380.31 MB / sです。

テスト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 MB /秒でした。 Microneでは、テストは3時間30分で実行され、記録速度は異なります。平均値は49.7 MB / sです。

テスト3.ランダム記録

このテストでは、5億個のキーを以前に作成したデータベースに書き換えようとしました。

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 

このテストでは、 49 MB /秒の速度で2時間51分という非常に良い結果が得られました（現時点では38 MB /秒に減少しました）。

Microneでは、テストに少し時間がかかります（ 3時間16分） 。 速度はほぼ同じですが、変動はより顕著です。

テスト4.ランダム読み取り

このテストの意味は、データベースから5億個のキーをランダムに読み取ることです。 以下は、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) . , . .