Changes between Version 3 and Version 4 of css/memorytunig
- Timestamp:
- 07/01/14 21:10:19 (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
css/memorytunig
v3 v4 14 14 CSSのDataBrowserでグラフを描くためのデータはヒープに格納される。 15 15 16 CSSの設定ファイルcss.ini内の {{{-vmargs}}}行以降でJavaで使用するメモリに関するパラメータが設定されている。16 CSSの設定ファイルcss.ini内の'''{{{-vmargs}}}'''行以降でJavaで使用するメモリに関するパラメータが設定されている。 17 17 18 18 {{{ … … 21 21 }}} 22 22 23 このうち非ヒープであるPermanent領域の最大サイズを指定しているパラメータ {{{-XX:MaxPermSize=128M}}}23 このうち非ヒープであるPermanent領域の最大サイズを指定しているパラメータ'''{{{-XX:MaxPermSize=128M}}}''' 24 24 については今回は変更しない。 25 25 26 26 ベンチマークの条件 27 27 * 使用したPCは、64bit版Windows7 Pro、Core i5(4core)、実装メモリ8GB、利用可能メモリ7.9GB、ネットワーク100Mbps 28 * 使用したCSSはkek版3.1.2 64bit。使用したJavaは Java SE 7 Update 55(1.7.0_55)。28 * 使用したCSSはkek版3.1.2 64bit。使用したJavaは64bit Java SE 7 Update 55(1.7.0_55)。 29 29 * 使用するデータは1つ。(PFROP:BEAM:FAST_CURR 0.1秒毎の更新) 30 30 * データの開始日時を固定。(2014/05/10 00:00:00) … … 36 36 このような条件でメモリに関するパラメータを変化させてベンチマークを行った。 37 37 38 グラフの横軸は処理したデータ量[日]、縦軸は処理時間[秒]を表わす。 38 39 39 40 == ヒープサイズを増やす == 40 41 41 Xmxパラメータはヒープの最大サイズを指定するパラメータである。[[BR]] 42 Xmxパラメータはヒープの最大サイズを指定するパラメータである。 43 42 44 あくまでも最大サイズを指定するものであり、実際のヒープサイズはデータ量により変わり、 43 データ量に応じて ヒープサイズは最大サイズまで自動的に拡張される。45 データ量に応じて最大サイズまで自動的に拡張される。[[BR]] 44 46 初期設定ではヒープの最大サイズが1GB(1024MB)に指定されている。 45 47 46 まずXmxパラメータでヒープの最大サイズを初期設定の1GB、4GB、6GB、8GBと増やした。(図1)[[BR]] 48 まずXmxパラメータでヒープの最大サイズを初期設定の1GB、4GB、6GB、8GBと増やした。(図1) 49 47 50 ヒープサイズを増やせば処理可能な日数が増え、処理時間もデータ量(日数)に比例する。(Xmx近似の点線)[[BR]] 48 51 ヒープサイズはデータの読み込みが進むにつれ次第に最大サイズ近くまで拡張されていった。 49 52 50 次にXmsパラメータをXmxと同じ値にして測定した。(図2)[[BR]] 53 次にXmsパラメータをXmxと同じ値にして測定した。(図2) 54 51 55 Xmsはヒープの初期サイズ指定で、Xmxと同じ値を指定すればヒープサイズは固定される。[[BR]] 52 ただしヒープサイズを大きなサイズに固定したからといって 実際にデータ量が増えなければ53 OSがメモリを割り当てることはないので、PCのメモリを無駄に占有するわけではない。56 ただしヒープサイズを大きなサイズに固定したからといって、 57 実際にデータ量が増えなければOSがメモリを割り当てることはないのでPCのメモリを無駄に占有するわけではない。 54 58 55 59 ヒープサイズを固定した場合にXmx近似より処理時間が短く完了する比例関係部分がある。(Xms近似の点線)[[BR]] … … 57 61 !Old領域が不足してFull GCが起こり始めるとXmx近似になっていく。 58 62 59 ヒープサイズを固定しない場合はヒープ サイズの拡張とともにFull GCが行われていると思われる。63 ヒープサイズを固定しない場合はヒープの拡張とともにFull GCが行われていると思われる。 60 64 61 65 [[Image(memorytuning_fig1.png, 40%)]] … … 63 67 64 68 処理時間については、ヒープサイズを固定した場合のほうが処理時間が短縮されることが多く、 65 8GBの20日分の処理時間を比較すると215秒から156秒へと59秒短縮されている。(図3,4,5) 69 Xms近似で処理が完了する場合はXmx近似に比較して約1.38倍の高速化となる。(図3,4,5)[[BR]] 70 8GBの20日分の処理時間を比較すると215秒から156秒へと59秒短縮されている。 66 71 67 72 処理可能な日数については、ヒープサイズを固定した場合に改善したというよりも、 68 ヒープサイズが可変の場合、ヒープ サイズを拡張する際にメモリの断片化が起き、73 ヒープサイズが可変の場合、ヒープを拡張する際にメモリの断片化が起き、 69 74 GCを行っても断片化が完全には解消できずにメモリの利用効率が悪化しているのではないだろうか。 70 75 … … 75 80 == ヒープのOld領域を大きくする == 76 81 77 次にNewRatioパラメータを変更してみる。[[BR]] 82 ヒープのOld領域が不足してFull GCが起こると処理時間が掛かるようになることが分かったので、 83 Old領域を大きくするためにNewRatioパラメータを変更してみる。 84 78 85 NewRatioパラメータはヒープのNew領域の大きさに対するOld領域の大きさの比率を指定する。[[BR]] 79 86 !NewRatio=2とした場合New1:Old2になり、New領域の大きさはヒープサイズの1/3、Old領域の大きさは2/3になる。 80 87 (似たパラメータとしてNew領域の大きさを指定する、!NewSize、MaxNewSizeというパラメータもある。) 81 88 82 Java !HotSpot VMにはクライアントVMとサーバVMのチューニングの異なる2種類のVMがあり、 83 NewRatioパラメータの初期値はクライアントVMが8、サーバVMが2となっている。[[BR]] 84 PCの構成によってどちらを使用するか決定される。自分のPCでどちらのVMが使用されるかは 85 {{{java -version}}}コマンドの出力で確認できる。[[BR]] 86 Windowsの場合、32bit JavaではクライアントVM、64bit JavaではサーバVMが使用される。 89 Java !HotSpot VMにはクライアントVMとサーバVMのチューニングの異なる2種類のVMがあり、 90 NewRatioパラメータの初期値はクライアントVMが8、サーバVMが2となっている。 91 92 PCの構成によってどちらを使用するか決定される。自分のPCでどちらのVMが使用されるかは 93 '''{{{java -version}}}'''コマンドの出力で確認できる。[[BR]] 94 Windowsの場合、32bit JavaではクライアントVM、64bit JavaではサーバVMが使用される。 87 95 88 96 Xms4Gとしてヒープサイズを4GBに固定して、NewRatio指定なし、!NewRatio=2、8、10、12、14、16、20と変化させた。(図6)[[BR]] 89 !NewRatio指定なしとNewRatio=2の結果は同じであることが確認できた。(64bit Javaを使用)[[BR]] 97 !NewRatio指定なしとNewRatio=2の結果は同じであることが確認できた。(64bit Javaを使用) 98 90 99 NewRatioを増やすにつれてXms近似の範囲で処理完了する日数が増えていくが、 91 次第に改善幅が小さくなっていき、16と20では同じ結果になった。[[BR]] 100 次第に改善幅が小さくなっていき、16と20では同じ結果になった。 101 92 102 これは、NewRatioが16の場合はOld領域の大きさがヒープの94.1%(16/17)、20の場合は95.2%(20/21)と、 93 103 Old領域の大きさが1%(45MB)しか変わらないからだろう。 … … 96 106 97 107 Xms6G、Xms8Gの場合も似たような結果になった。(図7,8)[[BR]] 98 NewRatioが16と20の場合の1%の違いは、6GBでは69MB、8GBでは91MBにすぎないが多少の改善が見られた。[[BR]] 108 NewRatioが16と20の場合の1%の違いは、6GBでは69MB、8GBでは91MBにすぎないが多少の改善が見られた。 109 99 110 4GBの場合でも1日分のデータ量の違いでは結果に差がなかったが、半日や1/4日分のデータ量の違いだとしたら 100 111 多少なりとも結果に差がでたことだろう。 … … 105 116 以上の結果から同じヒープサイズで、最大ヒープサイズを指定しただけの場合(Xmx)と、 106 117 ヒープサイズを固定かつOld領域を大きくした場合(Xms NR16)とを比較すると、 107 処理 完了までの時間と日数(データ量)がかなり改善され、118 処理時間と日数(データ量)がかなり改善され、 108 119 Xmx8GとXms8G NR16の場合では同等の処理時間で10日分多いデータが表示できるようになった。(図9,10,11) 109 120 110 121 さらに、少しズルい比較になるが、Xmx4GとXms8G NR16を比較すると 111 22日分多いデータが表示できるようになり、2.5倍に改善された。(図12)[[BR]] 112 処理時間についてはデータ量が多いためそれなりにかかるがXms近似から外れてはいない。 122 22日分多いデータが表示できるようになり、2.5倍に改善された。(図12) 123 124 処理時間についてはデータ量が多いためそれなりに掛かるがXms近似から外れてはいない。 113 125 114 126 [[Image(memorytuning_fig9.png, 40%)]] … … 121 133 122 134 CSSのDataBrowserで長期間のグラフあるいは多数のグラフを描かせるためには 123 CSSに多くのヒープ(メモリ)を割り当てる必要がある。[[BR]] 135 CSSに多くのヒープ(メモリ)を割り当てる必要がある。 136 124 137 データ量が増えるため必要なヒープも多くなるのは当然である。 125 138 … … 127 140 ヒープサイズを固定しOld領域の割合を大きくし、 128 141 Full GCをなるべく起こさないようにチューニングすることで 129 パフォーマンス(グラフの日数や数、処理 完了時間)はかなり改善される。142 パフォーマンス(グラフの日数や数、処理時間)はかなり改善される。 130 143 131 144 また、PCの利用可能メモリの制限からCSSに割り当てられるヒープサイズが制限される場合でも、 132 Old領域の割合を大きくすることで同じヒープサイズで もパフォーマンスを改善することができる。145 Old領域の割合を大きくすることで同じヒープサイズであってもパフォーマンスを改善することができる。 133 146 134 147 == 追加情報 == 135 148 136 今回このベンチマークテストを行っているときに、処理完了までに掛かる時間のうち 137 そのほとんどがネットワーク経由でのデータ転送に掛かっていることが分かった。 138 149 今回このベンチマークテストを行っているときに、処理時間のうちそのほとんどが 150 ネットワーク経由でのデータ転送に掛かっていることが分かった。[[BR]] 139 151 ベンチマークで使用したPCは100MbpsのHUBに繋がっていたが、 140 152 データ転送中は100Mbpsのうち98%近い帯域を使用しており、 … … 142 154 143 155 そこでHUBを1Gbps(GbE)のものに交換してXms8G NR16時のベンチマークを行ってみたところ、 144 処理 完了までの時間はほぼ半分になった。(図13)156 処理時間はほぼ半分になった。(図13) 145 157 146 158 [[Image(GbE_fig13.png, 40%)]] … … 151 163 * データ転送が終了してグラフ描画が終了するまでの時間。 152 164 153 38日分ではFull GCが発生しているためグラフ描画時間が かかっているが、154 それを除けば3つとも日数に比例した時間が かかっている。(図14)165 38日分ではFull GCが発生しているためグラフ描画時間が掛かっているが、 166 それを除けば3つとも日数に比例した時間が掛かっている。(図14) 155 167 156 168 [[Image(GbE_fig14.png, 40%)]] 157 169 158 170 36日分の処理時間の内訳を100Mbpsと1Gbpsを比較すると、クエリ処理とグラフ描画の時間に差はなく、 159 データ転送にかかる時間が233秒から85秒へと148秒短縮され た。(約2.7倍高速化)(図15-1,15-2)171 データ転送にかかる時間が233秒から85秒へと148秒短縮され、約2.74倍高速化となった。(図15-1,15-2 横軸は処理時間[秒]) 160 172 161 173 [[Image(GbE_fig15-1.png, 40%)]]
