Nabe International | Takeru Boost >> Takeruを回せ！ >>

ZFS with QAT(Quick Assist Technology)

未分類

QATzfs

昨年8月のブログでも少し触れたのですがzfsの圧縮オプションのうち、gzipに関してはIntelのQuick Assist Technologyを使うことでCPUからOffloadさせることができます。QATは、圧縮・解凍の機能の他、暗号化などにも対応しています。QATの機能を使うにはQATが搭載されたハードウェアとソフトウェア側の対応が必要なのですが、今回QATを内蔵しているChipsetを搭載したMotherboardでテストを行う機会があったのでその結果を紹介したいと思います。

テスト環境

Hardware

  • Motherboard : Supermicro X11DPH-Tq (Intel C627のChipsetにQATが搭載)
  • CPU : Xeon Platinum 8164 x2 下にも書きましたが、Onload負荷時との比較をするために、CPUコア数は全て有効にせず、BIOS設定で2core x2, 16core x2の2パターンで測定しています。
  • Memory : 256GB
  • System Disk : 512GB M2. NVMe
  • Data Disk(zfs) : 6TB SATA x9 (RAID0) : Sequential Disk I/O性能は非圧縮の状態でRead 1500MB/s , Write 950MB/s程度

Software

  • OS : CentOS 7.6
  • Kernel : 3.10.0-957.12.2.el7.x86_64
  • QAT : 1.7.L.4.5.0-00034 https://01.org/intel-quickassist-technology
  • ZFS on Linux : 0.8.0 : 以下の4種類のファイルシステムを同じプール上に構成
# zfs get compress
NAME             PROPERTY     VALUE     SOURCE
Babbage0         compression  off       default
Babbage0/GZIP    compression  gzip      local
Babbage0/LZ4     compression  lz4       local
Babbage0/NoComp  compression  off       default
Babbage0/QAT     compression  gzip      local

実施したテスト

  1. fastqファイルのコピー (圧縮)
  2. fastqファイルのcat > /dev/null (解凍)

テストの詳細と結果

1. fastqファイルのコピー

　ファイルはある程度のサイズがあって、圧縮が効くタイプのファイルであれば何でもよかったのですが、たまたま別のテストで使っていた大きなfastqファイルprecision-fda_input_HG001-NA12878-pFDA_S1_L001_R1_001.fastq を使いました。これをNVMeから各ZFS領域にコピーをし、時間を測定するというのがテストの内容ですが、NVMeからのRead速度の影響を受けないよう、ファイルは全てキャッシュに載せた状態でcpコマンドを実行しました。従って実際にはメモリからZFS領域への書き込みさせるというワークロードとなります。 　また、CPU上の処理がどの程度かを見るなどの目的のために、CPUの有効コア数を2と16に変更してぞれぞれで測定を行いました。
  • File Size : 179GB (ダウンロード時のgzipのファイルサイズは、68GB(圧縮率 : 2.63x) 
    $ ll -h precision-fda_input_HG001-NA12878-pFDA_S1_L001_R1_001.fastq
-rwxr--r-- 1 root root 179G Jun 13 23:24 precision-fda_input_HG001-NA12878-pFDA_S1_L001_R1_001.fastq
  • 実行コマンド 
    $ time cp precision-fda_input_HG001-NA12878-pFDA_S1_L001_R1_001.fastq [各zfsのディレクトリ]

1-1. CPU 4-core

Xeon Platinum 8164をBIOS設定で有効コアを2に制限。合計4コア
時間 ファイルサイズ 圧縮率
圧縮なし 195s 179GB -
lz4 (default) 191s 107GB 1.68x
gzip (with QAT) 297s 68GB 2.66x
gzip (without QAT) 6480s 61GB 2.97x

1-2. CPU 32-core

Xeon Platinum 8164をBIOS設定で有効コアを16に制限。合計32コア
時間 ファイルサイズ 圧縮率
圧縮なし 203s 179GB -
lz4 (default) 133s 107GB 1.68x
gzip (with QAT) 98s 68GB 2.66x
gzip (without QAT) 948s 61GB 2.97x

ファイルコピー時の負荷状況

負荷状況(dstat) : 圧縮無し
　コア数が少ない方が速いという少々意外な結果でした。これはもしかするとTurbo性能の特性により4coreの方が高クロックで動作していたことが原因かもしれません。
  • 4core 
    # dstat -tcd 10
----system---- ----total-cpu-usage---- -dsk/total-
   time     |usr sys idl wai hiq siq| read  writ
19-06 18:08:33|  0  49  34  16   0   0|1347M  929M
19-06 18:08:43|  0  46  39  14   0   0| 536M  915M
19-06 18:08:53|  0  45  40  15   0   0|7373B  946M
  • 32core 
    # dstat -tcd 10
----system---- ----total-cpu-usage---- -dsk/total-
   time     |usr sys idl wai hiq siq| read  writ
25-06 20:06:02|  0  12  85   3   0   0|   0   880M
25-06 20:06:12|  0  12  85   3   0   0| 410B  890M
25-06 20:06:22|  0  13  84   3   0   0|4096B  888M
負荷状況(dstat) : LZ4 (Disk I/O速度は圧縮後の速度)
　コア数を増やすと性能が1.5x程度上昇しました。dstatで出力される%sysは分母にコア数が入る相対的な値であり、また上の圧縮無しの状態でもそれなりの%を使っているので一概には言えませんが、少なくとも同程度の性能を持ったCPUでは8core程度以上はコア数が無いと圧縮処理がボトルネックになりそうです。
  • 4core 
    # dstat -tcd 10
----system---- ----total-cpu-usage---- -dsk/total-
   time     |usr sys idl wai hiq siq| read  writ
19-06 18:02:06|  0  85  11   3   0   0|   0   521M
19-06 18:02:16|  0  88   9   3   0   0| 819B  563M
19-06 18:02:26|  0  89   8   2   0   0|5325B  564M
  • 32core 
    # dstat -tcd 10
----system---- ----total-cpu-usage---- -dsk/total-
   time     |usr sys idl wai hiq siq| read  writ
25-06 20:14:38|  0  27  70   2   0   0|   0   791M
25-06 20:14:29|  0  25  72   3   0   0|  58M  813M
25-06 20:14:45|  0  26  72   2   0   0|   0   800M
負荷状況(dstat) : GZIP(with QAT) (Disk I/O速度は圧縮後の速度)
　上の圧縮なしと比較しても、%sysは4coreにおいて半分、32coreにおいて同等程度なので圧縮処理自体にCPUが使われていないことが負荷状況から窺えます。ただ、本当に使っていないのであればCPUコア数によって性能はほとんど変わらないはずなのに3xの差が生じているということは、コア数4coreではCPUがボトルネックになっており、それがディスク速度には十分余裕があるのにI/O Wait(wai)が20%程度になっている原因と思われます。下のGZIP without QATの結果と比べても圧縮処理の性能はQATの方がCPUより大幅に大きいことがわかります。
  • 4core 
    # dstat -tcd 10
----system---- ----total-cpu-usage---- -dsk/total-
   time     |usr sys idl wai hiq siq| read  writ
19-06 17:21:38|  0  24  59  17   0   1|   0   215M
19-06 17:21:48|  0  21  59  20   0   1|   0   228M
19-06 17:21:58|  0  19  61  19   0   1|   0   227M
  • 32core 
    # dstat -tcd 10 
----system---- ----total-cpu-usage---- -dsk/total-
   time     |usr sys idl wai hiq siq| read  writ
26-06 08:04:02|  0  14  83   2   0   0|   0   627M
26-06 08:04:06|  0  16  81   3   0   0|   0   736M
26-06 08:04:12|  0  15  82   3   0   0| 395k  711M
負荷状況(dstat) : GZIP(without QAT) (Disk I/O速度は圧縮後の速度)
　QAT無しなので、gzipの圧縮には当然CPUだけが使われているはずです。その結果コア数の違いがダイレクトに速度に違いに表れています。この結果を見る限り、QATは無いけれどもgzipを現実的に適用できる用途は限定されそうです。また、原因はわかりませんが、圧縮率がコマンドでgzipを実行した時よりもかなり向上しています。
  • 4core 
    # dstat -tcd 10
----system---- ----total-cpu-usage---- -dsk/total-
   time     |usr sys idl wai hiq siq| read  writ
21-06 16:02:58|  0  76  20   3   0   0|   0  8960k
21-06 16:03:28|  0  76  21   3   0   0| 546B 9446k
21-06 16:03:58|  0  76  19   4   0   0|   0  9010k
  • 32core 
    # dstat -tcd 10
----system---- ----total-cpu-usage---- -dsk/total-
   time     |usr sys idl wai hiq siq| read  writ
25-06 20:17:04|  0  75  24   1   0   0|2199k   62M
25-06 20:17:14|  0  75  25   1   0   0| 293M   62M
25-06 20:17:24|  0  76  24   0   0   0| 374M   62M

2. fastqファイルの解凍

　対象ファイルは1でコピーしたfastqファイルをそのまま使用しました。1のテストとは逆にキャッシュは毎回クリアした上で実行しています。解凍速度に焦点を当てるために別のファイルシステムにコピーをするといったことはせず、 cat [file] > /dev/nullを実行しました。

2-1. CPU 4-core

時間
圧縮なし 122s
lz4 (default) 216s
gzip (with QAT) 454s
gzip (witout QAT) 717s

2-2. CPU 32-core

時間
圧縮なし 123s
lz4 (default) 218s
gzip (with QAT) 465s
gzip (witout QAT) 767s

ファイル解凍時の負荷状況

　CPUコア数を変えてもほとんど性能差が無いので%sysの差がわかりやすい4core時のみ掲載します。(GZIP without QATのみ4core時の取得忘れのため32core時のもの)
圧縮なし
　圧縮無しで /dev/nullにリダイレクトする場合は、ディスクの性能の上限までほぼ達するので当然の結果と言えます。 
# dstat -tcd 10
----system---- ----total-cpu-usage---- -dsk/total-
     time     |usr sys idl wai hiq siq| read  writ
19-06 20:28:34|  0  39  55   5   0   1|1486M  177k
19-06 20:28:44|  0  39  55   5   0   1|1519M  173k
19-06 20:28:54|  0  39  54   7   0   1|1512M  173k
LZ4
　1コア強が%sysで負荷100%の状態になっていてその解凍処理がボトルネックになっていて圧縮なしの半分程度の性能にとどまっています。 
# dstat -tcd 10
----system---- ----total-cpu-usage---- -dsk/total-
     time     |usr sys idl wai hiq siq| read  writ
19-06 20:22:25|  0  31  68   1   0   1| 479M   96k
19-06 20:22:35|  0  30  68   1   0   1| 492M  201k
19-06 20:22:45|  0  30  68   1   0   1| 489M  173k
GZIP (with QAT)
　%sysは一番低く、一番CPU負荷は抑えられていますが、解凍処理がボトルネックになっており、LZ4の半分以下の性能しか出ていません。(dstatの見た目の速度はLZ4の1/4程度ですが圧縮率が異なるためLZ4に比べて1/2弱の性能になっています。) 
# dstat -tcd 10
----system---- ----total-cpu-usage---- -dsk/total-
     time     |usr sys idl wai hiq siq| read  writ
19-06 19:31:56|  0  10  88   1   0   1| 142M  204k
19-06 19:32:06|  0  10  89   0   0   1| 146M  173k
19-06 19:32:16|  0  11  88   0   0   1| 147M  173k
GZIP (without QAT) [これだけは32core時のもの]
　圧縮時よりはQAT付きGZIPとの差が大きく縮まっていますが、解凍処理をするにしてもCPUよりQATに任せた方が性能は1.5x~2x程度優れているということが言えます。 
# dstat -tcd 10                                                                                                       
----system---- ----total-cpu-usage---- -dsk/total-
     time     |usr sys idl wai hiq siq| read  writ
25-06 21:19:47|  0  10  89   0   0   0|  93M   46M
25-06 21:20:07|  0   3  97   0   0   0|  78M  178k
25-06 21:20:27|  0   3  97   0   0   0|  78M  182k

まとめ

　ZFSに関するという投稿が続いていますがいかがでしたでしょうか。テキストベースのファイルについては、結果が出た後ファイルシステム上でgzipコマンドを実行している方も一定数いるのではないかと推測しているのですが、少なくともzfsの圧縮オプションをgzipに設定している場合はコマンドでgzip圧縮する必要性は無く、むしろやらないほうがベターと言えます。ただ、その後zfs以外のファイルシステムでフォーマットされたUSB HDDなどのコピーする際は注意が必要です。 　ただ、QAT無しでGZIPをONにするにはパフォーマンスのペナルティが大きすぎるので、それなりのスペックを持った上で、性能より圧縮率を優先した用途(例えばバックアップ用サーバーなど)以外では使いにくいものと思われます。CPUのコア数によって上記のような大きな差が生じてしまうのでQATの導入によりどの程度の恩恵が得られるかというのは個別のケースで検討する必要がありそうですが、圧縮性能だけ見ればメインのファイルサーバに用いない理由は無いと言っても良さそうです。(ある程度のCPUコア数、性能があることが前提ですが)。 　解凍の性能に関しては、ある程度の性能を持ったストレージであればLZ4, GZIPいずれも圧縮なしのケースと比べて性能が低く、このあたりについては解凍に関しても優位な性能が出ていると紹介されている昨年のOpenZFS Dev Summitのプレゼンテーションの結果と異なってしまいました。今後別のバージョンや環境などで試してみて異なる結果が出たらまたここで書きたいと思います。 　また、実アプリケーション性能に関しても機会があればまた書きたいと思いますが、現在見ている限りではQATを使ってもLZ4より良いというケースは無さそうです。ただ、これはあくまでローカル性能の話なのでNFSサーバーであればまた結果は変わるかもしれませんし、コア数の割り当てをどのようにするかで結果もだいぶ変わるでしょう(Offload性能の比較の難しいところです)。 　ご興味があれば、具体的に性能を測定することも可能ですので担当の営業かエンジニアにお問い合わせ頂ければと思います。

前の記事

prev-article-image

ストレージのライフサイクルとZFS

次の記事

next-article-image

CWL workflow on Toil with Univa Grid Engine

© Basic Inc. All Rights Reserved.