Changes between Version 2 and Version 3 of css/memorytunig

Timestamp:

07/01/14 19:36:32 (11 years ago)

Author:

Takashi Nogami

Comment:

--

css/memorytunig

@@ -45 +45 @@
 
 まずXmxパラメータでヒープの最大サイズを初期設定の1GB、4GB、6GB、8GBと増やした。(図1)[[BR]]
-ヒープサイズを増やせば処理可能な日数が増え、処理時間もデータ量(日数)に比例する(Xmx近似の点線)。[[BR]]
+ヒープサイズを増やせば処理可能な日数が増え、処理時間もデータ量(日数)に比例する。(Xmx近似の点線)[[BR]]
 ヒープサイズはデータの読み込みが進むにつれ次第に最大サイズ近くまで拡張されていった。
 
@@ -53 +53 @@
 OSがメモリを割り当てることはないので、PCのメモリを無駄に占有するわけではない。
 
-ヒープサイズを固定した場合にXmx近似より処理時間が短く完了する比例関係部分がある(Xms近似の点線)。[[BR]]
+ヒープサイズを固定した場合にXmx近似より処理時間が短く完了する比例関係部分がある。(Xms近似の点線)[[BR]]
 データ量がヒープのOld領域の不足が起こらないで済む場合はXms近似で処理が完了するが、
 !Old領域が不足してFull GCが起こり始めるとXmx近似になっていく。
@@ -87 +87 @@
 
 Xms4Gとしてヒープサイズを4GBに固定して、NewRatio指定なし、!NewRatio=2、8、10、12、14、16、20と変化させた。(図6)[[BR]]
-!NewRatio指定なしとNewRatio=2の結果は同じであることが確認できた(64bit Javaを使用)。[[BR]]
+!NewRatio指定なしとNewRatio=2の結果は同じであることが確認できた。(64bit Javaを使用)[[BR]]
 NewRatioを増やすにつれてXms近似の範囲で処理完了する日数が増えていくが、
 次第に改善幅が小さくなっていき、16と20では同じ結果になった。[[BR]]
@@ -132 +132 @@
 Old領域の割合を大きくすることで同じヒープサイズでもパフォーマンスを改善することができる。
 
+== 追加情報 ==
+
+今回このベンチマークテストを行っているときに、処理完了までに掛かる時間のうち
+そのほとんどがネットワーク経由でのデータ転送に掛かっていることが分かった。
+
+ベンチマークで使用したPCは100MbpsのHUBに繋がっていたが、
+データ転送中は100Mbpsのうち98%近い帯域を使用しており、
+ネットワークの速度がボトルネックになっていることが明らかだった。
+
+そこでHUBを1Gbps(GbE)のものに交換してXms8G NR16時のベンチマークを行ってみたところ、
+処理完了までの時間はほぼ半分になった。(図13)
+
+[[Image(GbE_fig13.png, 40%)]]
+
+処理完了までの時間を次の3つに分けて詳しく測定した。
+ * プロットファイルを開いてからデータ転送が始まるまでの時間。(データベース側でのクエリ処理の時間と考えられる。)
+ * データ転送に掛かる時間。
+ * データ転送が終了してグラフ描画が終了するまでの時間。
+
+38日分ではFull GCが発生しているためグラフ描画時間がかかっているが、
+それを除けば3つとも日数に比例した時間がかかっている。(図14)
+
+[[Image(GbE_fig14.png, 40%)]]
+
+36日分の処理時間の内訳を100Mbpsと1Gbpsを比較すると、クエリ処理とグラフ描画の時間に差はなく、
+データ転送にかかる時間が233秒から85秒へと148秒短縮された。(約2.7倍高速化)(図15-1,15-2)
+
+[[Image(GbE_fig15-1.png, 40%)]]
+[[Image(GbE_fig15-2.png, 40%)]]
+
+この時ネットワーク帯域のうち25%～30%を使用していた。[[BR]]
+このボトルネックがPC、データベース、ネットワークのどこにあるのかまでは検証していない。