wiki:css/memorytunig

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

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

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

はじめに

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

参考

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

参考

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.1%(45MB)しか変わらないからだろう。

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

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

今回のベンチマークテストでは確認していないが、ヒープサイズが6GBや8GB(あるいは16GBなどもっと大きなヒープサイズ)の場合、NewRatioの指定を大きくすればもう少し改善するだろう。
たとえばヒープサイズ8GBでNewRatioが16と20では1.1%の違いで91MBだが、16と32では2.8%の違いで233MBになる。さらに16GBでNewRatioが16と32では2.8%の違いは467MBになる。

ただしヒープサイズが小さい場合にNewRatioの指定を大きくすると、反対にNew領域が小さくなりすぎる可能性があるため注意が必要だ。
たとえば32bit OSでメモリチューニングを行わない場合、ヒープサイズ1GB(CSSの初期値)でNewRatio=8(32bit Java、クライアントVMの初期値)となり、New領域の大きさが113MBであるので、目安としてNew領域の大きさが128MBより小さくならないようにするのが良いだろう。

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

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

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

どこがボトルネックか

今回このベンチマークテストを行っているときに、処理時間のうちそのほとんどがネットワーク経由でのデータ転送に掛かっていることが分かった。
ベンチマークで使用した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 横軸は処理時間[秒])

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

まとめ

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

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

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

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

処理時間の短縮にはネットワークの速度がかなり重要である。今回のベンチマークテストではネットワークの速度が100Mbpsと1Gbpsとでは処理時間が半分になった。無線LANの54Mbpsでは100Mbps比で2倍、1Gbps比では4倍の処理時間が掛かるのではないだろうか。

設定の一例

CSSに多くのヒープ(メモリ)を割り当てる必要があることは分かったが、実際にどのくらいのヒープサイズにするのが良いのだろうか。

PCの利用可能メモリ量や使い方によって変わるだろうが目安としてPCの利用可能メモリ量からOSが使用する分として1GB程度を除いた量を指定するのが良いだろう。

CSSに割り当てるヒープサイズを大きくしたからといって、実際に使用するヒープ(データ量)が増えなければOSがメモリを割り当てることはないのでPCのメモリを無駄に占有するわけではない。

それでも、使用しないのにそんなに大きなヒープを割り当てるのが気持ちが悪いのであれば、利用可能メモリの1/2~2/3程度に減らしても良いだろう。

ベンチマークテストで使用したPCは実装メモリ8GB、利用可能メモリ7.9GBであるが、CSSに割り当てるヒープサイズを8GBに指定して38日分のデータを読み込み、ヒープのほとんどを使用した際の空きメモリ量は300MB程になり、PCのレスポンス低下を感じた。

Windowsの場合、バージョンの違い(Vista、7、8など)とエディションの違い(Home Premium、Professionalなど)によって物理メモリサイズの制限がある。

参考

32bit OSおよび32bit Javaの場合、OSとJavaそれぞれにメモリサイズの制限がある。

参考

設定の一例

  • 32bit Windowsの場合、利用可能メモリ量にかかわらずヒープサイズの制限があるので1GB。また、ヒープサイズ1GBでNewRaito=16だとNew領域が小さすぎる可能性があるのでNewRatio=8。
    -Xmx1G
    -Xms1G
    -XX:NewRatio=8
    -XX:MaxPermSize=128M
    
  • 利用可能メモリ量が2.5GB程度の場合。
    -Xmx1280M
    -Xms1280M
    -XX:NewRatio=10
    -XX:MaxPermSize=128M
    
  • 利用可能メモリ量が3GB程度の場合。
    -Xmx2G
    -Xms2G
    -XX:NewRatio=14
    -XX:MaxPermSize=128M
    
  • 利用可能メモリ量が3.5GB程度の場合。
    -Xmx2560M
    -Xms2560M
    -XX:NewRatio=16
    -XX:MaxPermSize=128M
    
  • 利用可能メモリ量が4GB程度の場合。
    -Xmx3G
    -Xms3G
    -XX:NewRatio=20
    -XX:MaxPermSize=128M
    
  • 利用可能メモリ量が6GB程度の場合。
    -Xmx5G
    -Xms5G
    -XX:NewRatio=28
    -XX:MaxPermSize=128M
    
  • 利用可能メモリ量が8GB程度の場合。
    -Xmx7G
    -Xms7G
    -XX:NewRatio=32
    -XX:MaxPermSize=128M
    
  • 利用可能メモリ量が16GB程度の場合。
    -Xmx15G
    -Xms15G
    -XX:NewRatio=32
    -XX:MaxPermSize=128M
    

測定データ

図1、2、3、4、5

Xmx1GXmx4GXmx6GXmx8GXms1GXms4GXms6GXms8GXmx近似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.096301.496

図6

Xms4GXms4G NR2Xms4G NR8Xms4G NR10Xms4G NR12Xms4G NR14Xms4G NR16Xms4G NR20Xmx近似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.096301.496

図7、8

Xms6GXms6G NR8Xms6G NR12Xms6G NR16Xms6G NR20Xms8GXms8G NR8Xms8G NR12Xms8G NR16Xms8G NR20Xmx近似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 326415.096301.496

図9、10、11、12

Xmx4GXms4G NR16Xmx6GXms6G NR16Xmx8GXms8G NR16Xmx近似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 356415.096301.496

図13

100Mbps1Gbps100Mbps近似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
Last modified 10 years ago Last modified on 07/07/14 09:44:34

Attachments (16)

Download all attachments as: .zip