[PR] 100億件のアンロードを60分で達成！
はじめに
- 本稿は Haswell 世代の Xeon® E5 v3 プロセッサを2個搭載した入門レベルのx86サーバを使い 10の10乗行という途方もない量の Oracle Database 上のデータを何分掛けてアンロードできるかを検証した記事です。
- 測定結果から、約 1.5 テラ・バイトに及ぶ CSV データを 58 分 17 秒で出力できる事を確認しました。
- これは 1 秒当たりのデータ量に換算すると、行数 270万行、451 メガ・バイトにあたります。
- 多数の物理コアをもつ NUMA ノードシステムのポテンシャルをフル活用できる、 MTU の底力について解説します。
動機
- 本稿公開以前（2015年5月）は2008年に発売されたx86ベースのＰＣサーバを使って製品を検証していました。搭載された CPU は本稿執筆時点から数えて現行の 4 世代前にあたる Nehalem マイクロアーキテクチャに属する Xeon® E5420 （１個搭載）というモデルで、導入当初は十分な能力でした。
- ところが近頃は、ユーザが使うサーバの方が性能的に何倍も優れているケースが相次ぐようになりました。それにつれて、ユーザの性能目標を満たせるかどうかという質問へ次第に答えにくくなる状況が進んでいました。古過ぎるCPUを使った実証実験の結果とユーザのサーバとの性能比較から得た判断の有効性に疑念が生じたからです。
- このままでは製品の長所であるパフォーマンスについて、実証実験の結果からここまでのことが出来るという事が語れないので、思い切って検証サーバを刷新する事になりました。
- 新検証サーバは、現行の１世代前にあたる Haswell マイクロアーキテクチャの Xeon® E5 v3 プロセッサが2個搭載されており、DDR4 の RAMが64GB、最新のチップセット Intel® C610 に加え、ディスクも合計で10テラバイトを超える余裕のスペックです。
- 本稿の狙いは、新検証サーバの能力をフル活用して得た結果を通じて、大量データ抽出処理の長期化に直面している読者へ、現行のサーバとMTUを組み合わせて使えば、抱えている課題を乗り越えられるという確信を抱いて頂くのに十分な情報を提供する事に有ります。
測定条件
全体の条件
| 条件 |
選択内容 |
| 使用したシステム |
こちらのリンクをクリックすると、テストに使用したコンピュータについて解説した、このサイト内の記事へジャンプします。
Oracle Database 11g R2 から登場した Oracle Restart や、12c から登場したプラガブル・データベースといった、新しい技術への対応を検証する為の設定が含まれています。 |
MTU用環境変数
(出荷時初期値を変更した主なもの) |
LISTTABLE=HASH_PART_0160
FILESIZE=0
BIND_SIZE=1G
OVERLAP_BUFFER_LENGTH=4M
PARTITIONING=0
|
アンロード対象テーブル：HASH_PART_0160 の特性
| 条件 |
選択内容 |
| パーティション化 |
verchar2(15)型データをキーとしてハッシュ・パーティショニング |
| パーティション数 |
32 |
パーティションあたりの
平均データ件数 [単位:百万件] *1 |
312.5
（標準偏差:81571 行） |
| CSV の平均データ長 [単位:バイト] |
165 |
| 項目数 VARCHAR2 |
4 |
| 項目数 DATE |
2 |
| 項目数 NUMBER |
3 |
| 項目数 CHAR |
1 |
| 総項目数 |
10 |
| データ生成所要時間 [単位:秒] *2 |
43900 |
| セグメントサイズ合計 [単位:GB] *3 |
1078 |
| CSV データ量 [単位:GB] |
1542 |
- パーティション化キーに乱数に基づく値を用いているので平均値を中心に件数が僅かに分散しています。
- データ生成は弊社のオリジナルユーティリティー（非公開）を使用
- 表圧縮オプション未使用、USER_SEGMENTS ビューの BYTES 列値を集計表示
出力されるデータのサンプル (3件分)
0000000148~~Foqvre~~,~~21530424004401~~,280731594835,~~dlG9HSUf~~,748766.98,~~23240607215642~~,~~k7037 ~~,~~FFw5hZ12W~~,768478998939019,~~9LRhSbMaR9fBv~~,
0000000159~~1cCQM39g~~,~~38441127025731~~,2379760955898,~~EMLo6HgNWq~~,996422.43,~~28320220041621~~,~~ikKDhPZ ~~,~~hDWNzNWpV~~,793767313694761,~~HR3Z3krExrMuKMu7Od2~~,
0000000160~~sQ5QpcWkOu~~,~~35821117194854~~,3681160762725,~~rfBYL7IYdN5go~~,622915.16,~~19750226100019~~,~~oM4LJJ ~~,~~MKExk1~~,629023003075868,~~2VXfksb1aVlUcoBfad~~,
スケーラビリティを検証する為に変化させた条件
- MTU の環境変数 PARALLELISM へ設定する値を、32,28,24,…,4 と -4 刻みに変化させ、追加で 3 と 2 の場合も測定しました。
測定結果
スケーラビリティ
- 並列度が最も高い条件下での所要時間が 3497 秒（58分17秒）である事を確認しました。
- （一部逆転する領域もありますが）概ね、並列度が下がると平均処理能力も下がる傾向が確認できました。
| 並列度
| 性能指標 |
アンロード所要時間
[単位:秒] |
平均処理能力
[単位:kB/秒] |
タスクマネージャ
ＣＰＵタブ |
コンソール
出力 |
| 32 |
3497 |
462202 |
 |
 |
| 28 |
4740 |
341032 |
 |
 |
| 24 |
4463 |
362178 |
 |
 |
| 20 |
5260 |
307323 |
 |
 |
| 16 |
6298 |
256679 |
 |
 |
| 12 |
7158 |
225840 |
 |
 |
| 8 |
6805 |
237562 |
 |
 |
| 4 |
12841 |
125898 |
 |
 |
| 3 |
18380 |
87956 |
 |
 |
| 2 |
23760 |
68041 |
 |
 |
並列度と平均処理能力の関係
- 上の表をグラフに表現すると以下のようになりました。
- 並列度=8 までは、平均処理能力が直線的に伸び、平均で 1論理プロセッサあたり29MB/秒増加する事が判りました。
- 並列度=8 を超えると、平均処理能力の伸びの鈍化が目立つことが分かりました。この領域では平均で 1論理プロセッサあたり9.1MB/秒増加する事が判りました。
並列度と平均処理能力の関係
作業負荷最大時のリソース・モニタ状況
- 並列度=32 を指定し、作業負荷を最大にした時の稼働している各プロセスの CPU 使用率と。I/O データ率をリソースモニタを使って確認しました。
- CPU 使用率では、MTU が 89%、Oracle.exe が 8%、その他合計が 3% となりました。
- I/O データ率では、MTU による書き込みが約 452MB/秒、Oracle.exe による読み取りが約 315MB/秒の速度で実行されている事が判りました。書込みと読取りの率が同じにならない理由は、Oracleの内部データ表現に比べてテキストデータは冗長性が大きい為と考えられます。
- MTU と、Oracle.exe は全く競合せずに動作している事が、ドライブ C: のキュー長が殆どゼロである事から確認できました。
CPU占有率の降順でプロセスを確認
I/O率の降順でプロセスを確認
ロード・バランスされない作業負荷
偏った負荷の割当 (並列度=16)
- 並列度が 32 に満たない全てのケースで、NUMA ノードへの偏った負荷の割当が確認されました。
- 偏って負荷が集中するのは、いつも同じ NUMA ノードとは限らず、MTU を繰り返し実行する度にランダムに切り替わる現象が観察されました。
- 並列度を上昇させて 100% に達するまでは片方の NUMA ノードだけに作業負荷が積み上がる現象が観察されました。（右の画像を参照）
- 片方のノードが作業負荷で飽和すると、並列度の割増しで追加された分の作業負荷は、アイドルであったもう片方のノードに分配されるような現象が観察されました。
ターボ・ブースト
無負荷状態
偏在した負荷状態
まとめ
- 並列度=8 以下の測定では、ターボ・ブーストによる能力増強の影響が強く現れた為、並列度と平均処理能力の関係が直線にはなりませんでした。
- ディスク・ベンチマークテスト（Sequential Write = 496.897 MB/s）と当テスト（462202 kB/s=451 MB/s）の比較結果から、ストレージへの書込み能力限界に近いデータレートで処理できることが分かりました。
