CSSのDataBrowserのパフォーマンスチューニング

CSSのDataBrowserで長期間のグラフあるいは多数のグラフを描かせようとしたときに グラフを描き終わるまで非常に長時間掛かったりエラーになったりしてしまうことが良く起こる。

これはグラフを描くためのデータを格納するメモリが不足することが原因で起こるが、 メモリに関するパラメータをチューニングすることでどのようにパフォーマンスが改善されるか ベンチマークテストにより確認する。

はじめに

CSSではJavaが使用されている。 Javaで使用するメモリにはヒープ(Javaヒープ)と非ヒープがあり、 CSSのDataBrowserでグラフを描くためのデータはヒープに格納される。

参考

• ​JVMとGCのしくみ - ITエンジニアとして生きる
  
• ​Javaパフォーマンスチューニング（3）：Javaのヒープ・メモリ管理の仕組み (1/2) - ＠IT
  
• ​Javaパフォーマンスチューニング（6）：HotSpot VMの特性を知る (2/2) - ＠IT
  

CSSの設定ファイルcss.ini内の-vmargs行以降でJavaで使用するメモリに関するパラメータが設定されている。

-Xmx1024m
-XX:MaxPermSize=128M

このうち非ヒープであるPermanent領域の最大サイズを指定しているパラメータ-XX:MaxPermSize=128M については今回は変更しない。

ベンチマークの条件

• 使用したPCは、64bit版Windows7 Pro、Core i5(4core)、実装メモリ8GB、利用可能メモリ7.9GB、ネットワーク100Mbps
• 使用したCSSはkek版3.1.2 64bit。使用したJavaは64bit Java SE 7 Update 55(1.7.0_55)。
• 使用するデータは1つ。(PFROP:BEAM:FAST_CURR 0.1秒毎の更新)
• データの開始日時を固定。(2014/05/10 00:00:00)
• 何日分のグラフを描くプロットファイルを多数用意しておく。(1日分、2日分、、、)
• プロットファイルを開いた時からグラフを描き終わるまでの時間を測定する。
• 時間の測定にはストップウォッチを使い、1秒未満はすべて切り捨てる。
• 時間測定は最大10分とし10分を超えた場合は中断して、結果なしとする。
• 1つの測定毎にCSSを再起動する。

このような条件でメモリに関するパラメータを変化させてベンチマークを行った。

グラフの横軸は処理したデータ量[日]、縦軸は処理時間[秒]を表わす。

ヒープサイズを増やす

Xmxパラメータはヒープの最大サイズを指定するパラメータである。

あくまでも最大サイズを指定するものであり、実際のヒープサイズはデータ量により変わり、 データ量に応じて最大サイズまで自動的に拡張される。
初期設定ではヒープの最大サイズが1GB(1024MB)に指定されている。

まずXmxパラメータでヒープの最大サイズを初期設定の1GB、4GB、6GB、8GBと増やした。(図1)

ヒープサイズを増やせば処理可能な日数が増え、処理時間もデータ量(日数)に比例する。(Xmx近似の点線)
ヒープサイズはデータの読み込みが進むにつれ次第に最大サイズ近くまで拡張されていった。

次にXmsパラメータをXmxと同じ値にして測定した。(図2)

Xmsはヒープの初期サイズ指定で、Xmxと同じ値を指定すればヒープサイズは固定される。
ただしヒープサイズを大きなサイズに固定したからといって、 実際にデータ量が増えなければOSがメモリを割り当てることはないのでPCのメモリを無駄に占有するわけではない。

ヒープサイズを固定した場合にXmx近似より処理時間が短く完了する比例関係部分がある。(Xms近似の点線)
データ量がヒープのOld領域の不足が起こらないで済む場合はXms近似で処理が完了するが、 !Old領域が不足してFull GCが起こり始めるとXmx近似になっていく。

ヒープサイズを固定しない場合はヒープの拡張とともにFull GCが行われていると思われる。

処理時間については、ヒープサイズを固定した場合のほうが処理時間が短縮されることが多く、 Xms近似で処理が完了する場合はXmx近似に比較して約1.38倍の高速化となる。(図3、4、5)
8GBの20日分の処理時間を比較すると215秒から156秒へと59秒短縮されている。

処理可能な日数については、ヒープサイズを固定した場合に改善したというよりも、 ヒープサイズが可変の場合、ヒープを拡張する際にメモリの断片化が起き、 GCを行っても断片化が完全には解消できずにメモリの利用効率が悪化しているのではないだろうか。

ヒープのOld領域を大きくする

ヒープのOld領域が不足してFull GCが起こると処理時間が掛かるようになることが分かったので、 Old領域を大きくするためにNewRatioパラメータを変更してみる。

NewRatioパラメータはヒープのNew領域の大きさに対するOld領域の大きさの比率を指定する。
NewRatio=2とした場合New1:Old2になり、New領域の大きさはヒープサイズの1/3、Old領域の大きさは2/3になる。 (似たパラメータとしてNew領域の大きさを指定する、NewSize、MaxNewSizeというパラメータもある。)

Java HotSpot VMにはクライアントVMとサーバVMのチューニングの異なる2種類のVMがあり、 NewRatioパラメータの初期値はクライアントVMが8、サーバVMが2となっている。

PCの構成によってどちらのVMを使用するか決定される。自分のPCでどちらのVMが使用されるかは java -versionコマンドの出力で確認できる。
オプション指定によりどちらのVMを使用するか指定することも可能。 Windowsの32bit Javaでオプション指定なしの場合クライアントVMが使用される。
64bit JavaにはクライアントVMが用意されていないため常にサーバVMが使用される。

参考

• ​Java 仮想マシンテクノロジ
  
• ​Java SE 7 仮想マシン (VM) 関連 API & 開発者ガイド
  
• ​Server-Class マシンの検出
  
• ​JVMのチューニング - ITエンジニアとして生きる

Xms4Gとしてヒープサイズを4GBに固定して、NewRatio指定なし、NewRatio=2、8、10、12、14、16、20と変化させた。(図6)
!NewRatio指定なしとNewRatio=2の結果は同じであることが確認できた。(64bit Javaを使用)

NewRatioを増やすにつれてXms近似の範囲で処理完了する日数が増えていくが、 次第に改善幅が小さくなっていき、16と20では同じ結果になった。

これは、NewRatioが16の場合はOld領域の大きさがヒープの94.1%(16/17)、20の場合は95.2%(20/21)と、 Old領域の大きさが1%(45MB)しか変わらないからだろう。

Xms6G、Xms8Gの場合も似たような結果になった。(図7、8)
NewRatioが16と20の場合の1%の違いは、6GBでは69MB、8GBでは91MBにすぎないが多少の改善が見られた。

4GBの場合でも1日分のデータ量の違いでは結果に差がなかったが、半日や1/4日分のデータ量の違いだとしたら 多少なりとも結果に差がでたことだろう。

以上の結果から同じヒープサイズで、最大ヒープサイズを指定しただけの場合(Xmx)と、 ヒープサイズを固定かつOld領域を大きくした場合(Xms NR16)とを比較すると、 処理時間と日数(データ量)がかなり改善され、 Xmx8GとXms8G NR16の場合では同等の処理時間で10日分多いデータが表示できるようになった。(図9、10、11)

さらに、少しズルい比較になるが、Xmx4GとXms8G NR16を比較すると 22日分多いデータが表示できるようになり、2.5倍に改善された。(図12)

処理時間についてはデータ量が多いためそれなりに掛かるがXms近似から外れてはいない。

まとめ

CSSのDataBrowserで長期間のグラフあるいは多数のグラフを描かせるためには CSSに多くのヒープ(メモリ)を割り当てる必要がある。

データ量が増えるため必要なヒープも多くなるのは当然である。

しかし単にヒープの最大サイズを多くするだけでは不十分で、 ヒープサイズを固定しOld領域の割合を大きくし、 Full GCをなるべく起こさないようにチューニングすることで パフォーマンス(グラフの日数や数、処理時間)はかなり改善される。

また、PCの利用可能メモリの制限からCSSに割り当てられるヒープサイズが制限される場合でも、 Old領域の割合を大きくすることで同じヒープサイズであってもパフォーマンスを改善することができる。

追加情報

今回このベンチマークテストを行っているときに、処理時間のうちそのほとんどが ネットワーク経由でのデータ転送に掛かっていることが分かった。
ベンチマークで使用したPCは100MbpsのHUBに繋がっていたが、 データ転送中は100Mbpsのうち98%近い帯域を使用しており、 ネットワークの速度がボトルネックになっていることが明らかだった。

そこでHUBを1Gbps(GbE)のものに交換してXms8G NR16時のベンチマークを行ってみたところ、 処理時間はほぼ半分になった。(図13)

処理完了までの時間を次の3つに分けて詳しく測定した。

• プロットファイルを開いてからデータ転送が始まるまでの時間。(データベース側でのクエリ処理の時間と考えられる。)
• データ転送に掛かる時間。
• データ転送が終了してグラフ描画が終了するまでの時間。

38日分ではFull GCが発生しているためグラフ描画時間が掛かっているが、 それを除けば3つとも日数に比例した時間が掛かっている。(図14)

Full GCが発生していない36日分の処理時間の内訳を100Mbpsと1Gbpsを比較すると、クエリ処理とグラフ描画の時間に差はなく、 データ転送にかかる時間が233秒から85秒へと148秒短縮され、約2.74倍高速化となった。(図15-1、15-2 横軸は処理時間[秒])

この時ネットワーク帯域のうち25%～30%を使用していた。
このボトルネックがPC、データベース、ネットワークのどこにあるのかまでは検証していない。

測定データ

図1、2、3、4、5

	Xmx1G	Xmx4G	Xmx6G	Xmx8G	Xms1G	Xms4G	Xms6G	Xms8G	Xmx近似	Xms近似
1	11	12	9	9	8	9	9	8	4.766	7.2833
2	19	19	18	18	18	18	18	18
3	30	29	30	30	30	27	27	27
4	71	40	41	39	44	33	33	36
5		48	48	48	92	42	42	39
6		60	62	62		48	48	48
8		80	79	79		63	63	66
10		102	102	102		78	79	78
12		125	125	126		124	94	96
14		142	144	144		146	111	111
16			166	166		171	151	126
18			189	190		219	181	139
20			212	215			207	156
22			237	233			233	205
24			263	265			253	246
26				291			308	286
28								450
30
32
34
36
38									415.096	301.496

図6

	Xms4G	Xms4G NR2	Xms4G NR8	Xms4G NR10	Xms4G NR12	Xms4G NR14	Xms4G NR16	Xms4G NR20	Xmx近似	Xms近似
1	9	9	9						4.766	7.2833
2	18	18	17
3	27	24	24
4	33	33	33
5	42	42	42
6	48	48	48
8	63	63	63
10	78	78	78
12	124	123	96
14	146	147	111
16	171	172	126
18	219	219	144	145	145	148	145	147
20			200	163	163	163	163	162
21				283	182	171	171	172
22						309	194	194
24
26
28
30
32
34
36
38									415.096	301.496

図7、8

	Xms6G	Xms6G NR8	Xms6G NR12	Xms6G NR16	Xms6G NR20	Xms8G	Xms8G NR8	Xms8G NR12	Xms8G NR16	Xms8G NR20	Xmx近似	Xms近似
1	9	8				8	8				4.766	7.2833
2	18	18				18	18
3	27	24				27	24
4	33	33				36	33
5	42	42				39	42
6	48	48				48	48
8	63	63				66	63
10	79	81				78	78
12	94	96				96	93
14	111	111				111	108
16	151	126				126	126
18	181	144				139	139
20	207	159				156	156
22	233	174				205	172
24	253	191				246	186
26	308	208				286	205
28		226	226			450	223
30		307	244	245	247		236
32			401	279	260		253
34							269	273
36							335	294	293	294
38							431	412	356	326	415.096	301.496

図9、10、11、12

	Xmx4G	Xms4G NR16	Xmx6G	Xms6G NR16	Xmx8G	Xms8G NR16	Xmx近似	Xms近似
1	12	9	9	8	9	8	4.766	7.2833
2	19	17	18	18	18	18
3	29	24	30	24	30	24
4	40	33	41	33	39	33
5	48	42	48	42	48	42
6	60	48	62	48	62	48
8	80	63	79	63	79	63
10	102	78	102	81	102	78
12	125	96	125	96	126	93
14	142	111	144	111	144	108
16		126	166	126	166	126
18		145	189	144	190	139
20		163	212	159	215	156
22		194	237	174	233	172
24			263	191	265	186
26				208	291	205
28				226		223
30				245		236
32				279		253
34						273
36						93
38						356	415.096	301.496

図13

	100Mbps	1Gbps	100Mbps近似	1Gbps近似
1	8	6	7.2833	4.5904
2	18	8
3	24	15
4	33	17
5	42	20
6	48	26
8	63	33
10	78	39
12	93	48
14	108	57
16	126	63
18	139	69
20	156	78
22	172	88
24	186	94
26	205	106
28	223	112
30	236	121
32	253	130
34	273	136
36	293	146
38	356	192	301.4962	152.0983

図14

	クエリ処理	データ転送	グラフ描画	クエリ近似	転送近似	描画近似
1	2	3	1	2.7657	0.4549	1.2293
2	2	4	2
3	5	6	4
4	6	9	2
5	8	10	2
6	9	13	4
8	11	16	6
10	13	20	6
12	15	24	9
14	17	29	11
16	18	35	10
18	21	39	9
20	22	45	11
22	24	51	13
24	26	54	14
26	29	60	17
28	31	64	17
30	33	68	20
32	36	73	21
34	38	78	19
36	40	85	21
38	42	90	60	41.797	87.7638	22.8891

図15-1、15-2

	クエリ処理	データ転送	グラフ描画
1Gbps	40	85	21
100Mbps	40	233	20