分散キーバリューストアokuyamaの性能をまともなマシンで測ってみた

kvs java okuyama 性能 qps キーバリューストア

いままで分散キーバリューストアのokuyamaの性能を計測していたのは
Dellのノートパソコンか、10年くらい前のPCか、AMD2Coreのデスクトップだった。
自由に触れるマシンがその程度しかなかったんだけど、今回DellのXeon搭載のマシン(PowerEdgeT110)を
触る機会があったので、okuyamaの性能を測定してみました。

マシンスペックと構成は以下

本当はもう1台一番右のマシンと同スペックのマシンが用意できればDataNodeとSlaveDataNodeを
別々で配置したかったが、マシンがないので、同居させた。
後は、スイッチが100Mなのが残念。。。orz

key値は20〜25byte、valueは100byte〜105byteのスレッド単位でユニークな値
この構成でクライアントで1分間にset出来る値と、get出来る値を同時実行数(Thread)を
上げながら計測した。
okuyamaが持つ永続化の2モードそれぞれで計測
結果としては以下となった。


★トランザクションログでの永続化モード(稼動中はインメモリ)
[set]
40スレッド同時実行と45スレッド同時実行で
ほぼ同様の結果となりそれ以上は総登録件数に伸びが見られなかった

■1分当たりの総登録件数
->登録数:1782000 件

■1秒当たりのクエリー実行数(QPS)
->QPS:29700 QPS


[get]
50スレッド同時実行と60スレッド同時実行で
ほぼ同様の結果となりそれ以上は総取得件数に伸びが見られなかった

■1分当たりの総取得件数
->登録数:2946000 件

■1秒当たりのクエリー実行数(QPS)
->QPS:49400QPS

上記の2つの場合は両方ともMasterNode、DataNode(Slave含む)ともCPUは約50%程度の使用状況であった。
クライアント側のCPUはほぼ100%のため、これ以上の計測は出来なかった。



★トランザクションログ＋データファイルでの永続化モード(稼動中はKey値のみインメモリ、Valueはファイル)
[set]
50スレッド同時実行と60スレッド同時実行で
ほぼ同様の結果となりそれ以上は総登録件数に伸びが見られなかった

■1分当たりの総登録件数
->登録数:1560000 件

■1秒当たりのクエリー実行数(QPS)
->QPS:26000 QPS


[get]
50スレッド同時実行と60スレッド同時実行で
ほぼ同様の結果となりそれ以上は総取得件数に伸びが見られなかった

■1分当たりの総取得件数
->登録数:3057000 件

■1秒当たりのクエリー実行数(QPS)
->QPS:50950PS

上記の場合はset,get共にMasterNodeの負荷はトランザクションモードとかわらずCPU使用率50%程度。
DataNode(Slave含む)はset時はCPUは約30%程度の使用状況であったが、ディスクのI/O状況がかなり高くなった。
topコマンドのiowaitがcpu単位で50%程度
get時はCPU負荷が50%程度、ディスクのI/Oがほとんどなくなった。
これはおそらく、ＯＳのキャッシュにファイルイメージが乗ってしまっているので、起こる現象だと思われる。
そのことを示すかのように、QPS値がメモリ時を超えてしまっている。

set時の性能差が完全ファイルモードとインメモリモードで3000QPS程度なので、保存できるデータ容量を考えると、
完全ファイルモードの方がサーバリソースの効率化は図れそうです。
しかしメモリに乗り切らないファイルサイズになると、get性能が落ちる可能性がある。(後日試す予定)


こんな感じの性能になりました。
実際はDataNodeが1台のマシンに乗ってしまっているので、これを複数台に分けた場合の性能は調べたいな〜。
後は、スイッチはせめてギガが欲しい〜〜。欲を出すならSSDとかも!!

と夢は膨らみますが、実際は1台のクライアントマシンでスレッド数を増加させているので、これを複数台にした場合の性能を
まずは調べて見ないと一概にどこがネックなのかわかりません。
まあでも、8〜9万円程度のサーバ2台でこれだけの性能が出せたので、少し満足。

7月のOSC京都でセミナーもすることになったし、そのネタ(デモ??)にも使えるかな〜