解決手法「I/O デバイスをチューニングした高速データ登録手法」（手法 1）

課題 1 の解決手法としては「I/O デバイスをチューニングした高速データ登録手法」（手法 1）が 効果的であると考えた．なぜなら，手法 1 による安定した高速データ登録は，性能向上の高速化は ネットワーク I/O，安定稼動はディスク I/O をそれぞれチューニングするため，課題を解決できると 考えたからである．それぞれの具体的手法について以下に説明する．

 ネットワーク I/O チューニング方式：

大規模データの投入はクライアントから書き込みが行われる．そのため，データ投入のチュー ニングは，クライアントが動作する OS のインターフェースで実施した．チューニングのポイントは，

クライアントから OS にデータ書き込みをする通信のコネクションに関する TCP バッファのサイズ であった．TCP バッファのサイズのパラメータチューニングにより，1.5 倍の性能を確保する．詳 細について以下に述べる．

TCP バッファとは，TCP の通信時にパケットを一時的に保管しておくバッファのサイズである．

CBoC タイプ 2 では，書き込みと読み出しの処理は同一マシンで実行する AP とリソースを調整 できるようにするため，バッファのサイズに関する値はパラメータで変更可能である．パラメータ 変更では，ボトルネックとなる上限の値が分かっていないものはデフォルトの値を設定，文献や 実際の測定で分かっているものはその値を設定する．バッファのサイズを大きくする変更は，送

信するパケットサイズを大きくすることでパケットの送信回数を少なくすることで，大量のデータ が送信できるようになるからである¹．この手法で性能要件以上の書き込みを行ったところ，エラ ーが発生しないことを確認した．具体的には，Linux の OS 設定での TCP バッファに対して，送 受信バッファの net.ipv4.tcp_wmem と net.ipv4.tcp_rmem を，デフォルトの値の 87380 バイトから 129024 バイトの約 1.5 倍に変更する．このパラメータの値は，1 ソケットあたりのデータ送受信の 際に利用するメモリの使用量で，システムに他の AP などの処理（以降，負荷と呼ぶ）がかかって いない状態での割り当て量である．また負荷がある場合は，OS によってそのメモリの使用量が 自動に調整される．最大 2Gbps の NW 帯域でデータの書き込みを行い，効果が高いデフォルト の 1.5 倍に設定する．さらにバッファの最大値の net.core.wmem_max と net.core.rmem_max をデ フォルトの 131071 バイトから 4194304 バイト（許容されている最大値）に変更して，受信したデー タを最大限処理可能にする．その結果，提案手法によって，1.5 倍の書き込みスループットを確 保することが可能となる．

 ディスク I/O チューニング方式：

ディスク I/O のチューニングは，プロダクトが制御しているディスク I/O に対するチューニング により実施する．プロダクトが制御しているディスク I/O に対するチューニングにより，安定した性 能が得られる．詳細について以下に記述する．

プロダクトが制御しているディスク I/O に関しては，データ登録時にバッファリングされたデー タをディスクに書き出す Compaction の処理がある．Compaction が処理性能への影響の支配項 になっていることが分かったため，原因となっている Merge Compaction の実行をデフォルトの設 定値以上になったときの実行から，設定値に乱数値を足してランダムな実行に変更し，複数の マシンで同時に Merge Compaction が発生しないようにする²．複数のマシンにおいて Merge Compaction の同時発生を回避したことにより，ディスク書き込みのボトルネックが解消できる．

以上のように，TCP バッファのサイズのチューニングによって，性能要件の 1.5 倍の書き込みス ループットを実現する．またプロダクトのディスク書き込み制御の設定変更によって， 図 14 に示す とおり書き込みスループットを性能要件から常に超えるスループットとなるように安定させる．

1 一般的にソケットのバッファサイズを大きくすると，スループットを上げる効果がある．（参考：

http://d.hatena.ne.jp/tt_clown/20091130/1259567150）

2 商用の運用条件では，データ投入のスループットが事前投入と比べて低く，データは各サーバへ不 均衡に蓄積されるため Merge Compaction が同時に発生することはない．また，設定値の変更としたの は，機能追加では設計からやり直す必要があるためである． プロダクトの通常処理に Merge

Compaction のランダムな実行の処理を加えることは，ランダム化したことによりバッファがオーバーフロ ーしないよう閾値を超える前に実行するなど，実行条件を検討して機能追加をするため時間を要する．

0 172,800 345,600 518,400

15:30 0:00 12:00 0:00 12:00 0:00

（2日目） （3日目） （4日目）

時間

図 14. データ投入例（書き込みスループット一定）

スループット（件/分）

性能要件 ▲