SlideShare a Scribd company logo
負荷テストを行う際に
知っておきたいこと
初心者編
まべ☆てっく vol.2
株式会社マーベラス 森 正一 <morim@marv.jp>
 1. ストレージのシンプロビジョニングについて
 2. ロードバランサの負荷について
 3. jmeterのチューニングについて
今日お話しすること
ストレージの
シンプロビジョニング
 ストレージは最初にまるっと確保しちゃいましょう
結論から言うと
 クラウド環境でなければ、あまり関係ない話かも
 でも、知っておけばいずれ役立つ (と思いたい)
ちなみに
 ・物理ストレージを仮想化し、論理ストレージとして管理する手法
 ・例えばユーザーが100GBのストレージを作成しても、
 実際に物理ストレージが100GB確保されるわけではない
 - ユーザーからは100GBのストレージとして普通に認識される
 ・実際に確保された物理ストレージの残容量が少なくなると拡張
される
ストレージのシンプロビジョニングとは
 ・ストレージ作成時に、全ての領域が確保されないということは
 - 拡張時にオーバヘッドが生ずる
 ・ベンチマークによると、極端に遅くはならないようだ
 ・かなり大きいファイル(数GB~数十GB)をコピーすると、
 拡張が繰り返されることがあるようだ
 - 拡張された領域に初めて書き込みする際に0埋めされる
 (らしい)
シンプロビジョニングの問題
 ・パブリックのクラウド環境だと、拡張時に遅延が生じたりするかも
 - 最悪、ヘルスチェックに失敗して、フェイルオーバーしたり
 - 仮想マシンごとにI/Oのパフォーマンスが異なる

 →最初から全ての領域を確保しておいた方が無難
シンプロビジョニングの問題
 負荷テストの際は、余計な問題は潰しておきましょう
何れにせよ
 ex.
 dd if=/dev/zero of=warm.`date '+%Y%m%dT%H%M%S'` bs=1M count=10000
 bs(1Mbytes)*(count)10,000回 = 10Gbytesのファイルが
作成される
まるっと確保する
オプション 内容
if 入力ファイル
of 出力ファイル
bs 1回のread/writeの単位(bytes)
count 要するに回数
 ・100GBの契約をしているユーザーが100人
 →100G*100人=10TBの物理ストレージが必要…
 とはならないのでコスト削減になる
 ・クラウドの場合、ストレージのシンプロビジョニングを採
用しているところが多い (らしい)
クラウド業者側には都合が良い仕組み
ルータ(ロードバランサ)
の負荷
 ・クラウドの場合、最初から用意されている
 - 各アカウントがVLANで分かれているような構成
 ・クラウド業者によって仮想ルータだったり物理ルータ
だったり
ルータ(ロードバランサ)
 ・VLAN内に仮想ルータ用のマシンが存在
 ・冗長構成になっている
 ・中でkeepalivedが動いていたり
仮想ルータの場合
 ・仮想ルータの負荷が問題になる場合がある
 - CPU負荷とか帯域とか
 - 過負荷によるフェイルオーバーで通信断が発生したり
 - 直接見えないところなので分かりづらい
仮想ルータの問題
 ・pv4,500~5,000/sec、1リクエスト辺りの処理時間が
 60~80msec程度の負荷
 - 仮想ルータのCPU過負荷によるフェイルオーバー
 - 負荷を受ける側ではなく、負荷をかける側の
 アカウントで発生 (両方クラウド環境)
 - 小さいパケットを大量に送るとCPU負荷が
 上がりやすかったりする
仮想ルータの問題::実例
 ・負荷をかける側のアカウントを分散
 - 2アカウントに分散。1アカウント辺り10~15台。
 - 1台辺りjmeterで100スレッド程度
 ・仮想ルータをスペックアップ
 ・アプリケーション(PHP)のpersistent接続をoff
仮想ルータの問題::対処
 ・自動でスケールするような仮想ルータでも、急に負荷が上がった
場合は間に合わない場合も
 - 商用サービスの場合「間に合わなかった」では済まない
 - 事前にスペックを上げておく
仮想ルータの問題::事前の対応
 ・場合によっては複数のアカウントを使う、専用線を引
いてnatでLVSを立てたり…等の対応も必要
 - 対応に数営業日かかるので、早めの見極めが大事
 ・明確なしきい値を用意しておく等
 - サービスオープン後だと大変なことに…
仮想ルータの問題::事前の対応
jmeterのチューニング
 数秒に渡ってwebサーバへのアクセスが途絶える
発生した事象
Time pv/sec
20:23:18 1189
20:23:19 0
20:23:20 0
20:23:21 0
20:23:22 0
20:23:23 1715
Time pv/sec
20:24:44 1029
20:24:45 0
20:24:46 0
20:24:47 0
20:24:48 0
20:24:49 1202
Time pv/sec
20:24:50 954
20:24:51 0
20:24:52 0
20:24:53 0
20:24:54 0
20:24:55 765
 ・jmeterでフルガベージコレクションが発生していた
 ・ログを取った結果
発生した事象
 2015年 12月 17日 木曜日 20:23:19 JST
 [Full GC (Ergonomics) 1453552K->1318639K(2040320K), 4.6455914 secs]
 ~
 2015年 12月 17日 木曜日 20:24:44 JST
 [Full GC (Ergonomics) 1453399K->1355673K(2040320K), 4.8516675 secs]
 ~
 2015年 12月 17日 木曜日 20:24:51 JST
 [Full GC (Ergonomics) 1449802K->1202556K(2011136K), 4.7977979 secs]
 javaのメモリ管理ってどうなってるの
何とかしなければ…
 ガベージコレクションのログ出力オプション
jmeterチューニング前準備::ログ出力
Option 説明
-verbose:gc 詳細情報。stdoutに出力
-Xloggc:filename ファイル出力
-XX:+PrintGCDetails Young/Old Generation領域詳
細情報を出力
-XX:+PrintGCDateStamps 日付表示
 java7のメモリ管理
 - 新規に確保したオブジェクトは基本的にEdenに格納される
 - ある程度時間が経過するとSurvivor Spaceに移動される
 ・更に、From/Toを相互に移動する
 ・メモリのフラグメンテーションを少なくするための仕組み
 - ある程度時間が経過すると、Old Generationに移動される
jmeterチューニング前準備::ヒープの仕組み
 ・上記に加えてPermanent Generationが存在する
 - Java8ではMetaspaceに変更されている
 - クラスやメソッド等のメタデータ
 (java7ではstatic変数等も)が格納される
 ・Old Generation/Permanent Generation(Metaspace)が不足す
るとFull GCが行われる。
jmeterチューニング前準備::ヒープの仕組み
Option 説明
-Xmsn ヒープの初期サイズ(bytes)。Young Generation + Old
Generation
-Xmxn ヒープの最大サイズ(bytes)。Young Generation + Old
Generation
-XX:MaxTenuringThreshold Young GenerationからOld Generationに移動するまでの
しきい値(最大値)。GC時にFrom/Toを行き来する回数
jmeterチューニング前準備::ヒープ設定オプション
jmeterチューニング前準備::ヒープの仕組み
 パスは環境依存
 ex. /usr/local/apache-jmeter-2.13/bin/jmeter
Option 説明
-XX:PermSize=n Permanent領域の初期値(java8ではMetaspaceに変更されて
いる)
-XX:MaxPermSize=n Permanent 領域の最大値(java8ではMetaspaceに変更されて
いる)
-XX:NewRatio Young GenerationとOld Generationの割合
-XX:SurvivorRatio EdenとSurvivor Spacesの割合
 実際は他にもいろいろとオプションがあります。
jmeterチューニング前準備::Metadetaについて
Option 説明
MinMetaspaceExpansion Metaspace拡張時の最小値(bytes)
MaxMetaspaceExpansion Metaspace拡張時の最大値(bytes)
MinMetaspaceFreeRatio Metaspaceの容量調整の基準となる%(最小値)
MaxMetaspaceFreeRatio Metaspaceの容量調整の基準となる%(最大値)
MetaspaceSize Metaspace領域に起因するFull GCの基準値(byte)
MaxMetaspaceSize Metaspace領域のサイズ最大値(byte)
 jmeterの設定はデフォルトのままシナリオを廻してみる
 まずはログを出力
 ex. -Xloggc:/tmp/gc.log -XX:+PrintGCDetails
jmeterチューニング::その1
300.625: [GC (Allocation Failure) [PSYoungGen: 167052K->4811K(168448K)] 228720K->68993K(518144K), 0.0072286 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
301.320: [GC (Allocation Failure) [PSYoungGen: 167115K->4860K(168448K)] 231297K->71642K(518144K), 0.0062726 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
301.432: [GC (Metadata GC Threshold) [PSYoungGen: 30915K->1997K(168448K)] 97697K->71411K(518144K), 0.0042318 secs] [Times: user=0.01 sys=0.00, real=0.00 s
301.436: [Full GC (Metadata GC Threshold) [PSYoungGen: 1997K->0K(168448K)] [ParOldGen: 69414K->38678K(349696K)] 71411K->38678K(518144K), [Metaspace:
82360K->21400K(1110016K)], 0.0548297 secs] [Times: user=0.11 sys=0.00, real=0.06 secs]
302.169: [GC (Allocation Failure) [PSYoungGen: 162304K->5229K(167424K)] 200982K->43908K(517120K), 0.0042335 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
302.889: [GC (Allocation Failure) [PSYoungGen: 166509K->4420K(167936K)] 205188K->45720K(517632K), 0.0061693 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
303.635: [GC (Allocation Failure) [PSYoungGen: 165700K->4201K(168448K)] 207000K->48056K(518144K), 0.0062849 secs] [Times: user=0.02 sys=0.00, real=0.01 sec
304.391: [GC (Allocation Failure) [PSYoungGen: 166505K->4644K(168448K)] 210360K->51043K(518144K), 0.0077471 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
305.127: [GC (Allocation Failure) [PSYoungGen: 166948K->4623K(168448K)] 213347K->53656K(518144K), 0.0063692 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
305.804: [GC (Allocation Failure) [PSYoungGen: 166927K->4882K(168448K)] 215960K->56501K(518144K), 0.0064685 secs] [Times: user=0.02 sys=0.00, real=0.01 sec
306.553: [GC (Allocation Failure) [PSYoungGen: 167186K->4742K(168448K)] 218805K->58971K(518144K), 0.0065102 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
307.250: [GC (Allocation Failure) [PSYoungGen: 167046K->4540K(168448K)] 221275K->61398K(518144K), 0.0064846 secs] [Times: user=0.03 sys=0.00, real=0.01 secs]
307.992: [GC (Allocation Failure) [PSYoungGen: 166844K->4882K(168448K)] 223702K->64292K(518144K), 0.0064639 secs] [Times: user=0.03 sys=0.00, real=0.00 sec
 毎秒以上の間隔で勢いよくGCが発生している
 GCに要している時間を確認してみる
 jstatコマンドを使用
 ex. jstat -gccause -h5 -t 9789 1000
jmeterチューニング::その2
Timestamp S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC
300.7 0.00 78.31 17.36 18.35 75.99 87.98 459 3.317 37 2.172 5.490 Allocation Failure No GC
301.7 0.00 0.00 37.52 11.06 33.63 65.81 461 3.328 38 2.227 5.555 Metadata GC Threshold No GC
302.7 85.12 0.00 77.12 11.06 41.39 67.71 462 3.332 38 2.227 5.559 Allocation Failure No GC
303.7 68.38 0.00 13.62 12.54 57.14 71.74 464 3.345 38 2.227 5.572 Allocation Failure No GC
304.7 0.00 75.60 44.51 13.27 64.90 73.76 465 3.352 38 2.227 5.579 Allocation Failure No GC
305.7 75.25 0.00 89.48 14.02 73.10 75.83 466 3.359 38 2.227 5.586 Allocation Failure No GC
306.7 77.20 0.00 33.95 15.51 78.12 79.97 468 3.371 38 2.227 5.599 Allocation Failure No GC
307.7 0.00 73.90 60.39 16.26 77.40 81.93 469 3.378 38 2.227 5.605 Allocation Failure No GC
308.7 79.47 0.00 82.88 16.99 76.98 84.00 470 3.384 38 2.227 5.612 Allocation Failure No GC
309.7 83.74 0.00 25.91 18.48 75.98 88.03 472 3.397 38 2.227 5.624 Allocation Failure No GC
項目 説明
S0, S1 Survivor Spaceの使用率(%)
E Edenの使用率(%)
O Old Generationの使用率(%)
M Metaspaceの使用率(%)
YGC Young GenerationのGC回数
項目 説明
YGCT YGCに要した時間(sec)
FGC Full GC回数
FGCT Full GCに要した時間(sec)
GCT GC総時間(YGCT + FGCT)
 ・ヒープサイズを増やしてみる
 ex. -Xms4096m -Xmx4096m
 - ヒープの初期サイズ/最大サイズともに4G
jmeterチューニング::その3
300.470: [GC (Allocation Failure) [PSYoungGen: 1304064K->32019K(1336320K)] 1342797K->70752K(4132864K), 0.0317416 secs] [Times: user=0.11 sys=0.00,
real=0.03 s
303.093: [GC (Metadata GC Threshold) [PSYoungGen: 606193K->14041K(1350656K)] 644926K->66275K(4147200K), 0.0363289 secs] [Times: user=0.12 sys=0.00, real
303.130: [Full GC (Metadata GC Threshold) [PSYoungGen: 14041K->0K(1350656K)] [ParOldGen: 52234K->38488K(2796544K)] 66275K->38488K(4147200K),
[Metaspace: 79290K->21255K(1103872K)], 0.0476072 secs] [Times: user=0.09 sys=0.00, real=0.05 secs]
308.982: [GC (Allocation Failure) [PSYoungGen: 1303040K->31014K(1350144K)] 1341528K->69510K(4146688K), 0.0266850 secs] [Times: user=0.12 sys=0.00, real=0.02
311.482: [GC (Metadata GC Threshold) [PSYoungGen: 614958K->14282K(1351168K)] 653454K->65675K(4147712K), 0.0303426 secs] [Times: user=0.11 sys=0.00, real=0.
311.512: [Full GC (Metadata GC Threshold) [PSYoungGen: 14282K->0K(1351168K)] [ParOldGen: 51392K->38656K(2796544K)] 65675K->38656K(4147712K), [Metaspace:
79286K->21249K(1107968K)], 0.0497781 secs] [Times: user=0.09 sys=0.00, real=0.05 secs]
 頻度はだいぶ減った
 YGCおよびYGCTは明らかに減った。それにより総GC時
間も短くなった。Full GCが若干増えているが…
 ログからOld GenerationよりYoung Generationが問題に
なっていることが窺える
jmeterチューニング::その3
Timestamp S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC
300.1 0.00 0.00 91.30 1.39 37.08 65.67 76 2.115 40 2.302 4.417 Metadata GC Threshold No GC
301.1 0.00 99.27 10.59 1.39 77.45 81.90 77 2.147 40 2.302 4.449 Allocation Failure No GC
302.1 0.00 99.27 27.69 1.39 77.45 81.90 77 2.147 40 2.302 4.449 Allocation Failure No GC
303.1 0.00 99.27 43.43 1.39 77.45 81.90 77 2.147 40 2.302 4.449 Allocation Failure No GC
304.1 0.00 0.00 16.75 1.38 37.08 65.66 78 2.183 41 2.349 4.533 Metadata GC Threshold No GC
305.1 0.00 0.00 33.10 1.38 37.08 65.66 78 2.183 41 2.349 4.533 Metadata GC Threshold No GC
306.1 0.00 0.00 50.44 1.38 37.08 65.66 78 2.183 41 2.349 4.533 Metadata GC Threshold No GC
307.1 0.00 0.00 67.35 1.38 37.08 65.66 78 2.183 41 2.349 4.533 Metadata GC Threshold No GC
308.1 0.00 0.00 84.67 1.38 37.08 65.66 78 2.183 41 2.349 4.533 Metadata GC Threshold No GC
309.1 0.00 65.84 2.75 1.38 77.45 81.85 79 2.210 41 2.349 4.559 Allocation Failure No GC
 更に頻度が減った
jmeterチューニング::その4
280.679: [Full GC (Metadata GC Threshold) [PSYoungGen: 40522K->0K(2050560K)] [ParOldGen: 51260K->50886K(2097152K)] 91783K->50886K(4147712K),
[Metaspace: 79234K->21477K(1105920K)], 0.0613836 secs] [Times: user=0.15 sys=0.00, real=0.06 secs]
288.897: [GC (Metadata GC Threshold) [PSYoungGen: 1860458K->40765K(2051072K)] 1911345K->91651K(4148224K), 0.0472159 secs] [Times: user=0.14 sys=0.01, real=
288.944: [Full GC (Metadata GC Threshold) [PSYoungGen: 40765K->0K(2051072K)] [ParOldGen: 50886K->51279K(2097152K)] 91651K->51279K(4148224K),
[Metaspace: 79277K->21381K(1105920K)], 0.0632846 secs] [Times: user=0.12 sys=0.00, real=0.07 secs]
297.318: [GC (Metadata GC Threshold) [PSYoungGen: 1872530K->40540K(2051072K)] 1923809K->91827K(4148224K), 0.0376583 secs] [Times: user=0.11 sys=0.00, real
297.355: [Full GC (Metadata GC Threshold) [PSYoungGen: 40540K->0K(2051072K)] [ParOldGen: 51287K->51313K(2097152K)] 91827K->51313K(4148224K), [Metaspace:
79305K->21404K(1105920K)], 0.0536986 secs] [Times: user=0.11 sys=0.00, real=0.06 secs]
305.855: [GC (Metadata GC Threshold) [PSYoungGen: 1873542K->40245K(2051072K)] 1924856K->91559K(4148224K), 0.0400885 secs] [Times: user=0.18 sys=0.00, re
305.895: [Full GC (Metadata GC Threshold) [PSYoungGen: 40245K->0K(2051072K)] [ParOldGen: 51313K->50980K(2097152K)] 91559K->50980K(4148224K),
[Metaspace: 79236K->21339K(1105920K)], 0.0509746 secs] [Times: user=0.12 sys=0.00, real=0.05 secs]
 Young Generation領域を調整してみる
 ex. -XX:NewRatio=1 -XX:SurvivorRatio=8
 - Young Generation:Old Generation = 1:1
 - Eden:Survivor Space = 8:1
 YGCは更に減った。総GC時間も短くなった。
jmeterチューニング::その4
Timestamp S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC
300.1 0.00 0.00 30.94 2.45 36.12 65.78 41 1.370 41 2.311 3.681 Metadata GC Threshold No GC
301.1 0.00 0.00 41.52 2.45 36.12 65.78 41 1.370 41 2.311 3.681 Metadata GC Threshold No GC
302.1 0.00 0.00 52.49 2.45 36.12 65.78 41 1.370 41 2.311 3.681 Metadata GC Threshold No GC
303.1 0.00 0.00 63.66 2.45 36.12 65.78 41 1.370 41 2.311 3.681 Metadata GC Threshold No GC
304.1 0.00 0.00 75.24 2.45 36.12 65.78 41 1.370 41 2.311 3.681 Metadata GC Threshold No GC
305.1 0.00 0.00 85.61 2.45 36.12 65.78 41 1.370 41 2.311 3.681 Metadata GC Threshold No GC
306.1 0.00 0.00 3.33 2.43 36.01 65.67 42 1.410 42 2.362 3.772 Metadata GC Threshold No GC
307.1 0.00 0.00 14.09 2.43 36.01 65.67 42 1.410 42 2.362 3.772 Metadata GC Threshold No GC
308.1 0.00 0.00 25.84 2.43 36.01 65.67 42 1.410 42 2.362 3.772 Metadata GC Threshold No GC
309.1 0.00 0.00 36.42 2.43 36.01 65.67 42 1.410 42 2.362 3.772 Metadata GC Threshold No GC
 Metadata領域を調整してみる
 ex. -XX:MetaspaceSize=3072m
 -XX:MaxMetaspaceSize=4096m
 - MetaspaceSize…Metaspace領域に起因する
 Full GCの基準値(bytes)
 - MaxMetaspaceSize…Metaspace領域のサイズ最大値
jmeterチューニング::その5
256.643: [GC (Allocation Failure) [PSYoungGen: 2042812K->40697K(2050048K)] 2122592K->123926K(4147200K), 0.0223751 secs] [Times: user=0.08 sys=0.01, real=0.0
266.073: [GC (Allocation Failure) [PSYoungGen: 2043641K->42246K(2050048K)] 2126870K->128055K(4147200K), 0.0213952 secs] [Times: user=0.07 sys=0.00, real=0.
275.462: [GC (Allocation Failure) [PSYoungGen: 2045190K->42083K(2051072K)] 2130999K->130455K(4148224K), 0.0227541 secs] [Times: user=0.07 sys=0.01, real=0.02
284.956: [GC (Allocation Failure) [PSYoungGen: 2046563K->41545K(2050560K)] 2134935K->133136K(4147712K), 0.0217961 secs] [Times: user=0.08 sys=0.01, real=0.02
294.342: [GC (Allocation Failure) [PSYoungGen: 2046025K->41711K(2051584K)] 2137616K->135994K(4148736K), 0.0232748 secs] [Times: user=0.08 sys=0.01, real=0.02
303.911: [GC (Allocation Failure) [PSYoungGen: 2047215K->41708K(2051072K)] 2141498K->138524K(4148224K), 0.0235565 secs] [Times: user=0.04 sys=0.00, real=0.03
 若干頻度が減った程度だが…
 FGCが激減(1回だけ)
 総GC時間も短くなった
jmeterチューニング::その5
Timestamp S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC
300.5 90.52 0.00 64.03 4.50 60.36 83.05 34 1.411 1 0.036 1.447 Allocation Failure No GC
301.5 90.52 0.00 74.92 4.50 60.36 83.05 34 1.411 1 0.036 1.447 Allocation Failure No GC
302.5 90.52 0.00 85.05 4.50 60.36 83.05 34 1.411 1 0.036 1.447 Allocation Failure No GC
303.6 90.52 0.00 96.15 4.50 60.36 83.05 34 1.411 1 0.036 1.447 Allocation Failure No GC
304.6 0.00 91.53 7.94 4.62 60.25 83.01 35 1.434 1 0.036 1.470 Allocation Failure No GC
305.6 0.00 91.53 17.61 4.62 60.25 83.01 35 1.434 1 0.036 1.470 Allocation Failure No GC
306.6 0.00 91.53 27.51 4.62 60.25 83.01 35 1.434 1 0.036 1.470 Allocation Failure No GC
307.6 0.00 91.53 39.25 4.62 60.25 83.01 35 1.434 1 0.036 1.470 Allocation Failure No GC
308.6 0.00 91.53 49.96 4.62 60.25 83.01 35 1.434 1 0.036 1.470 Allocation Failure No GC
309.6 0.00 91.53 60.89 4.62 60.25 83.01 35 1.434 1 0.036 1.470 Allocation Failure No GC
 ・最初にFull GCが1発かかる (System.gc())
 ・-XX:MetaspaceSize=3072mにしてもMetaspaceのサイズ自体が変
わってないのが確認できる
jmeterチューニング::補足
0.631: [GC (System.gc()) [PSYoungGen: 203448K->9720K(1887744K)] 203448K->9736K(3984896K),
0.0070194 secs] [Times: user=0.02 sys=0.01, real=0.01 secs]
0.638: [Full GC (System.gc()) [PSYoungGen: 9720K->0K(1887744K)] [ParOldGen: 16K-
>9402K(2097152K)] 9736K->9402K(3984896K), [Metaspace: 9492K->9492K(1058816K)], 0.0309553
secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
 jcmdで確認するとMetaspaceのサイズが変わってる
 みたい (動的に変化)
 - ex. jcmd 8749 PerfCounter.print | grep meta
jmeterチューニング::補足
sun.gc.metaspace.capacity=2364276736
sun.gc.metaspace.maxCapacity=3403677696
sun.gc.metaspace.minCapacity=0
sun.gc.metaspace.used=1416081480
 ・Full-GCを無くすというよりは、スループットを一定にする方が大事
 ・ヒープを大きくすれば頻度を下げられるが、GC(Full GC)が発生し
たときの停止時間も長くなる
 ・今回のチューニングは一例に過ぎない。ケースバイケース
おわり

More Related Content

What's hot

Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
 
Vacuum徹底解説
Vacuum徹底解説Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
 
さくっと理解するSpring bootの仕組み
さくっと理解するSpring bootの仕組みさくっと理解するSpring bootの仕組み
さくっと理解するSpring bootの仕組み
Takeshi Ogawa
 
「書ける」から「できる」になれる! ~Javaメモリ節約ノウハウ話~
「書ける」から「できる」になれる! ~Javaメモリ節約ノウハウ話~「書ける」から「できる」になれる! ~Javaメモリ節約ノウハウ話~
「書ける」から「できる」になれる! ~Javaメモリ節約ノウハウ話~
JustSystems Corporation
 
Java でつくる 低レイテンシ実装の技巧
Java でつくる低レイテンシ実装の技巧Java でつくる低レイテンシ実装の技巧
Java でつくる 低レイテンシ実装の技巧
Ryosuke Yamazaki
 
Java ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsugJava ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsug
Masatoshi Tada
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
 
Prometheus入門から運用まで徹底解説
Prometheus入門から運用まで徹底解説Prometheus入門から運用まで徹底解説
Prometheus入門から運用まで徹底解説
貴仁 大和屋
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
 
ヤフー発のメッセージキュー「Pulsar」のご紹介
ヤフー発のメッセージキュー「Pulsar」のご紹介ヤフー発のメッセージキュー「Pulsar」のご紹介
ヤフー発のメッセージキュー「Pulsar」のご紹介
Yahoo!デベロッパーネットワーク
 
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTT DATA Technology & Innovation
 
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
onozaty
 
Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6
Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6
Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6
Yuji Kubota
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
Etsuji Nakai
 
Apache Kafka 0.11 の Exactly Once Semantics
Apache Kafka 0.11 の Exactly Once SemanticsApache Kafka 0.11 の Exactly Once Semantics
Apache Kafka 0.11 の Exactly Once Semantics
Yoshiyasu SAEKI
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
 
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
NTT DATA OSS Professional Services
 
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
NTT DATA Technology & Innovation
 
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
AdvancedTechNight
 
AWS で Presto を徹底的に使いこなすワザ
AWS で Presto を徹底的に使いこなすワザAWS で Presto を徹底的に使いこなすワザ
AWS で Presto を徹底的に使いこなすワザ
Noritaka Sekiyama
 

What's hot (20)

Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
 
Vacuum徹底解説
Vacuum徹底解説Vacuum徹底解説
Vacuum徹底解説
 
さくっと理解するSpring bootの仕組み
さくっと理解するSpring bootの仕組みさくっと理解するSpring bootの仕組み
さくっと理解するSpring bootの仕組み
 
「書ける」から「できる」になれる! ~Javaメモリ節約ノウハウ話~
「書ける」から「できる」になれる! ~Javaメモリ節約ノウハウ話~「書ける」から「できる」になれる! ~Javaメモリ節約ノウハウ話~
「書ける」から「できる」になれる! ~Javaメモリ節約ノウハウ話~
 
Java でつくる 低レイテンシ実装の技巧
Java でつくる低レイテンシ実装の技巧Java でつくる低レイテンシ実装の技巧
Java でつくる 低レイテンシ実装の技巧
 
Java ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsugJava ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsug
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Prometheus入門から運用まで徹底解説
Prometheus入門から運用まで徹底解説Prometheus入門から運用まで徹底解説
Prometheus入門から運用まで徹底解説
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
 
ヤフー発のメッセージキュー「Pulsar」のご紹介
ヤフー発のメッセージキュー「Pulsar」のご紹介ヤフー発のメッセージキュー「Pulsar」のご紹介
ヤフー発のメッセージキュー「Pulsar」のご紹介
 
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
 
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
 
Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6
Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6
Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
 
Apache Kafka 0.11 の Exactly Once Semantics
Apache Kafka 0.11 の Exactly Once SemanticsApache Kafka 0.11 の Exactly Once Semantics
Apache Kafka 0.11 の Exactly Once Semantics
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
 
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
 
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
 
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
 
AWS で Presto を徹底的に使いこなすワザ
AWS で Presto を徹底的に使いこなすワザAWS で Presto を徹底的に使いこなすワザ
AWS で Presto を徹底的に使いこなすワザ
 

Similar to 負荷テストを行う際に知っておきたいこと 初心者編

JDK付属ツールにパッチを出しまくったワケ
JDK付属ツールにパッチを出しまくったワケJDK付属ツールにパッチを出しまくったワケ
JDK付属ツールにパッチを出しまくったワケ
Yasumasa Suenaga
 
CPUから見たG1GC
CPUから見たG1GCCPUから見たG1GC
CPUから見たG1GC
Kenji Kazumura
 
第六回渋谷Java Java8のJVM監視を考える
第六回渋谷Java Java8のJVM監視を考える第六回渋谷Java Java8のJVM監視を考える
第六回渋谷Java Java8のJVM監視を考えるchonaso
 
Versatil Javaチューニング
Versatil JavaチューニングVersatil Javaチューニング
Versatil Javaチューニング
Kenji Kazumura
 
TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望
Kohei KaiGai
 
Concurrent Mark-Sweep Garbage Collection #jjug_ccc
Concurrent Mark-Sweep Garbage Collection #jjug_cccConcurrent Mark-Sweep Garbage Collection #jjug_ccc
Concurrent Mark-Sweep Garbage Collection #jjug_ccc
Yuji Kubota
 
Maatkit で MySQL チューニング
Maatkit で MySQL チューニングMaatkit で MySQL チューニング
Maatkit で MySQL チューニングKensuke Nagae
 
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
Kohei KaiGai
 
GPGPU deいろんな問題解いてみた
GPGPU deいろんな問題解いてみたGPGPU deいろんな問題解いてみた
GPGPU deいろんな問題解いてみたRyo Sakamoto
 
Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
[db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c...
[db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c...[db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c...
[db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c...Insight Technology, Inc.
 
【関東GPGPU勉強会#4】GTX 1080でComputer Vision アルゴリズムを色々動かしてみる
【関東GPGPU勉強会#4】GTX 1080でComputer Visionアルゴリズムを色々動かしてみる【関東GPGPU勉強会#4】GTX 1080でComputer Visionアルゴリズムを色々動かしてみる
【関東GPGPU勉強会#4】GTX 1080でComputer Vision アルゴリズムを色々動かしてみる
Yasuhiro Yoshimura
 
大規模な負荷でもドキドキしない為のJava EE
大規模な負荷でもドキドキしない為のJava EE大規模な負荷でもドキドキしない為のJava EE
大規模な負荷でもドキドキしない為のJava EE
Taiichilow Nagase
 
20161121 open hyperscale#6
20161121 open hyperscale#620161121 open hyperscale#6
20161121 open hyperscale#6
ManaMurakami1
 
プロファイラGuiを用いたコード分析 20160610
プロファイラGuiを用いたコード分析 20160610プロファイラGuiを用いたコード分析 20160610
プロファイラGuiを用いたコード分析 20160610
HIDEOMI SUZUKI
 
MySQLerの7つ道具 plus
MySQLerの7つ道具 plusMySQLerの7つ道具 plus
MySQLerの7つ道具 plus
yoku0825
 
RとStanでクラウドセットアップ時間を分析してみたら #TokyoR
RとStanでクラウドセットアップ時間を分析してみたら #TokyoRRとStanでクラウドセットアップ時間を分析してみたら #TokyoR
RとStanでクラウドセットアップ時間を分析してみたら #TokyoR
Shuyo Nakatani
 
そうだ 検証、しよう。
そうだ 検証、しよう。そうだ 検証、しよう。
そうだ 検証、しよう。
健一 三原
 
MySQLerの7つ道具
MySQLerの7つ道具MySQLerの7つ道具
MySQLerの7つ道具
yoku0825
 
HandlerSocket plugin for MySQL
HandlerSocket plugin for MySQLHandlerSocket plugin for MySQL
HandlerSocket plugin for MySQLakirahiguchi
 

Similar to 負荷テストを行う際に知っておきたいこと 初心者編 (20)

JDK付属ツールにパッチを出しまくったワケ
JDK付属ツールにパッチを出しまくったワケJDK付属ツールにパッチを出しまくったワケ
JDK付属ツールにパッチを出しまくったワケ
 
CPUから見たG1GC
CPUから見たG1GCCPUから見たG1GC
CPUから見たG1GC
 
第六回渋谷Java Java8のJVM監視を考える
第六回渋谷Java Java8のJVM監視を考える第六回渋谷Java Java8のJVM監視を考える
第六回渋谷Java Java8のJVM監視を考える
 
Versatil Javaチューニング
Versatil JavaチューニングVersatil Javaチューニング
Versatil Javaチューニング
 
TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望
 
Concurrent Mark-Sweep Garbage Collection #jjug_ccc
Concurrent Mark-Sweep Garbage Collection #jjug_cccConcurrent Mark-Sweep Garbage Collection #jjug_ccc
Concurrent Mark-Sweep Garbage Collection #jjug_ccc
 
Maatkit で MySQL チューニング
Maatkit で MySQL チューニングMaatkit で MySQL チューニング
Maatkit で MySQL チューニング
 
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
 
GPGPU deいろんな問題解いてみた
GPGPU deいろんな問題解いてみたGPGPU deいろんな問題解いてみた
GPGPU deいろんな問題解いてみた
 
Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
[db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c...
[db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c...[db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c...
[db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c...
 
【関東GPGPU勉強会#4】GTX 1080でComputer Vision アルゴリズムを色々動かしてみる
【関東GPGPU勉強会#4】GTX 1080でComputer Visionアルゴリズムを色々動かしてみる【関東GPGPU勉強会#4】GTX 1080でComputer Visionアルゴリズムを色々動かしてみる
【関東GPGPU勉強会#4】GTX 1080でComputer Vision アルゴリズムを色々動かしてみる
 
大規模な負荷でもドキドキしない為のJava EE
大規模な負荷でもドキドキしない為のJava EE大規模な負荷でもドキドキしない為のJava EE
大規模な負荷でもドキドキしない為のJava EE
 
20161121 open hyperscale#6
20161121 open hyperscale#620161121 open hyperscale#6
20161121 open hyperscale#6
 
プロファイラGuiを用いたコード分析 20160610
プロファイラGuiを用いたコード分析 20160610プロファイラGuiを用いたコード分析 20160610
プロファイラGuiを用いたコード分析 20160610
 
MySQLerの7つ道具 plus
MySQLerの7つ道具 plusMySQLerの7つ道具 plus
MySQLerの7つ道具 plus
 
RとStanでクラウドセットアップ時間を分析してみたら #TokyoR
RとStanでクラウドセットアップ時間を分析してみたら #TokyoRRとStanでクラウドセットアップ時間を分析してみたら #TokyoR
RとStanでクラウドセットアップ時間を分析してみたら #TokyoR
 
そうだ 検証、しよう。
そうだ 検証、しよう。そうだ 検証、しよう。
そうだ 検証、しよう。
 
MySQLerの7つ道具
MySQLerの7つ道具MySQLerの7つ道具
MySQLerの7つ道具
 
HandlerSocket plugin for MySQL
HandlerSocket plugin for MySQLHandlerSocket plugin for MySQL
HandlerSocket plugin for MySQL
 

Recently uploaded

LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアルLoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
CRI Japan, Inc.
 
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
Toru Tamaki
 
Generating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language ModelsGenerating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language Models
harmonylab
 
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライドHumanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
tazaki1
 
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
t m
 
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
Osaka University
 
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
Matsushita Laboratory
 
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援しますキンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
Takayuki Nakayama
 
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
嶋 是一 (Yoshikazu SHIMA)
 
This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.
chiefujita1
 

Recently uploaded (10)

LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアルLoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
 
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
 
Generating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language ModelsGenerating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language Models
 
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライドHumanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
 
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
 
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
 
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
 
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援しますキンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
 
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
 
This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.
 

負荷テストを行う際に知っておきたいこと 初心者編

  • 2.  1. ストレージのシンプロビジョニングについて  2. ロードバランサの負荷について  3. jmeterのチューニングについて 今日お話しすること
  • 6.  ・物理ストレージを仮想化し、論理ストレージとして管理する手法  ・例えばユーザーが100GBのストレージを作成しても、  実際に物理ストレージが100GB確保されるわけではない  - ユーザーからは100GBのストレージとして普通に認識される  ・実際に確保された物理ストレージの残容量が少なくなると拡張 される ストレージのシンプロビジョニングとは
  • 7.  ・ストレージ作成時に、全ての領域が確保されないということは  - 拡張時にオーバヘッドが生ずる  ・ベンチマークによると、極端に遅くはならないようだ  ・かなり大きいファイル(数GB~数十GB)をコピーすると、  拡張が繰り返されることがあるようだ  - 拡張された領域に初めて書き込みする際に0埋めされる  (らしい) シンプロビジョニングの問題
  • 8.  ・パブリックのクラウド環境だと、拡張時に遅延が生じたりするかも  - 最悪、ヘルスチェックに失敗して、フェイルオーバーしたり  - 仮想マシンごとにI/Oのパフォーマンスが異なる   →最初から全ての領域を確保しておいた方が無難 シンプロビジョニングの問題
  • 10.  ex.  dd if=/dev/zero of=warm.`date '+%Y%m%dT%H%M%S'` bs=1M count=10000  bs(1Mbytes)*(count)10,000回 = 10Gbytesのファイルが 作成される まるっと確保する オプション 内容 if 入力ファイル of 出力ファイル bs 1回のread/writeの単位(bytes) count 要するに回数
  • 11.  ・100GBの契約をしているユーザーが100人  →100G*100人=10TBの物理ストレージが必要…  とはならないのでコスト削減になる  ・クラウドの場合、ストレージのシンプロビジョニングを採 用しているところが多い (らしい) クラウド業者側には都合が良い仕組み
  • 13.  ・クラウドの場合、最初から用意されている  - 各アカウントがVLANで分かれているような構成  ・クラウド業者によって仮想ルータだったり物理ルータ だったり ルータ(ロードバランサ)
  • 14.  ・VLAN内に仮想ルータ用のマシンが存在  ・冗長構成になっている  ・中でkeepalivedが動いていたり 仮想ルータの場合
  • 15.  ・仮想ルータの負荷が問題になる場合がある  - CPU負荷とか帯域とか  - 過負荷によるフェイルオーバーで通信断が発生したり  - 直接見えないところなので分かりづらい 仮想ルータの問題
  • 16.  ・pv4,500~5,000/sec、1リクエスト辺りの処理時間が  60~80msec程度の負荷  - 仮想ルータのCPU過負荷によるフェイルオーバー  - 負荷を受ける側ではなく、負荷をかける側の  アカウントで発生 (両方クラウド環境)  - 小さいパケットを大量に送るとCPU負荷が  上がりやすかったりする 仮想ルータの問題::実例
  • 17.  ・負荷をかける側のアカウントを分散  - 2アカウントに分散。1アカウント辺り10~15台。  - 1台辺りjmeterで100スレッド程度  ・仮想ルータをスペックアップ  ・アプリケーション(PHP)のpersistent接続をoff 仮想ルータの問題::対処
  • 18.  ・自動でスケールするような仮想ルータでも、急に負荷が上がった 場合は間に合わない場合も  - 商用サービスの場合「間に合わなかった」では済まない  - 事前にスペックを上げておく 仮想ルータの問題::事前の対応
  • 19.  ・場合によっては複数のアカウントを使う、専用線を引 いてnatでLVSを立てたり…等の対応も必要  - 対応に数営業日かかるので、早めの見極めが大事  ・明確なしきい値を用意しておく等  - サービスオープン後だと大変なことに… 仮想ルータの問題::事前の対応
  • 21.  数秒に渡ってwebサーバへのアクセスが途絶える 発生した事象 Time pv/sec 20:23:18 1189 20:23:19 0 20:23:20 0 20:23:21 0 20:23:22 0 20:23:23 1715 Time pv/sec 20:24:44 1029 20:24:45 0 20:24:46 0 20:24:47 0 20:24:48 0 20:24:49 1202 Time pv/sec 20:24:50 954 20:24:51 0 20:24:52 0 20:24:53 0 20:24:54 0 20:24:55 765
  • 22.  ・jmeterでフルガベージコレクションが発生していた  ・ログを取った結果 発生した事象  2015年 12月 17日 木曜日 20:23:19 JST  [Full GC (Ergonomics) 1453552K->1318639K(2040320K), 4.6455914 secs]  ~  2015年 12月 17日 木曜日 20:24:44 JST  [Full GC (Ergonomics) 1453399K->1355673K(2040320K), 4.8516675 secs]  ~  2015年 12月 17日 木曜日 20:24:51 JST  [Full GC (Ergonomics) 1449802K->1202556K(2011136K), 4.7977979 secs]
  • 24.  ガベージコレクションのログ出力オプション jmeterチューニング前準備::ログ出力 Option 説明 -verbose:gc 詳細情報。stdoutに出力 -Xloggc:filename ファイル出力 -XX:+PrintGCDetails Young/Old Generation領域詳 細情報を出力 -XX:+PrintGCDateStamps 日付表示
  • 25.  java7のメモリ管理  - 新規に確保したオブジェクトは基本的にEdenに格納される  - ある程度時間が経過するとSurvivor Spaceに移動される  ・更に、From/Toを相互に移動する  ・メモリのフラグメンテーションを少なくするための仕組み  - ある程度時間が経過すると、Old Generationに移動される jmeterチューニング前準備::ヒープの仕組み
  • 26.  ・上記に加えてPermanent Generationが存在する  - Java8ではMetaspaceに変更されている  - クラスやメソッド等のメタデータ  (java7ではstatic変数等も)が格納される  ・Old Generation/Permanent Generation(Metaspace)が不足す るとFull GCが行われる。 jmeterチューニング前準備::ヒープの仕組み
  • 27. Option 説明 -Xmsn ヒープの初期サイズ(bytes)。Young Generation + Old Generation -Xmxn ヒープの最大サイズ(bytes)。Young Generation + Old Generation -XX:MaxTenuringThreshold Young GenerationからOld Generationに移動するまでの しきい値(最大値)。GC時にFrom/Toを行き来する回数 jmeterチューニング前準備::ヒープ設定オプション
  • 28. jmeterチューニング前準備::ヒープの仕組み  パスは環境依存  ex. /usr/local/apache-jmeter-2.13/bin/jmeter Option 説明 -XX:PermSize=n Permanent領域の初期値(java8ではMetaspaceに変更されて いる) -XX:MaxPermSize=n Permanent 領域の最大値(java8ではMetaspaceに変更されて いる) -XX:NewRatio Young GenerationとOld Generationの割合 -XX:SurvivorRatio EdenとSurvivor Spacesの割合
  • 29.  実際は他にもいろいろとオプションがあります。 jmeterチューニング前準備::Metadetaについて Option 説明 MinMetaspaceExpansion Metaspace拡張時の最小値(bytes) MaxMetaspaceExpansion Metaspace拡張時の最大値(bytes) MinMetaspaceFreeRatio Metaspaceの容量調整の基準となる%(最小値) MaxMetaspaceFreeRatio Metaspaceの容量調整の基準となる%(最大値) MetaspaceSize Metaspace領域に起因するFull GCの基準値(byte) MaxMetaspaceSize Metaspace領域のサイズ最大値(byte)
  • 30.  jmeterの設定はデフォルトのままシナリオを廻してみる  まずはログを出力  ex. -Xloggc:/tmp/gc.log -XX:+PrintGCDetails jmeterチューニング::その1 300.625: [GC (Allocation Failure) [PSYoungGen: 167052K->4811K(168448K)] 228720K->68993K(518144K), 0.0072286 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 301.320: [GC (Allocation Failure) [PSYoungGen: 167115K->4860K(168448K)] 231297K->71642K(518144K), 0.0062726 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 301.432: [GC (Metadata GC Threshold) [PSYoungGen: 30915K->1997K(168448K)] 97697K->71411K(518144K), 0.0042318 secs] [Times: user=0.01 sys=0.00, real=0.00 s 301.436: [Full GC (Metadata GC Threshold) [PSYoungGen: 1997K->0K(168448K)] [ParOldGen: 69414K->38678K(349696K)] 71411K->38678K(518144K), [Metaspace: 82360K->21400K(1110016K)], 0.0548297 secs] [Times: user=0.11 sys=0.00, real=0.06 secs] 302.169: [GC (Allocation Failure) [PSYoungGen: 162304K->5229K(167424K)] 200982K->43908K(517120K), 0.0042335 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 302.889: [GC (Allocation Failure) [PSYoungGen: 166509K->4420K(167936K)] 205188K->45720K(517632K), 0.0061693 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 303.635: [GC (Allocation Failure) [PSYoungGen: 165700K->4201K(168448K)] 207000K->48056K(518144K), 0.0062849 secs] [Times: user=0.02 sys=0.00, real=0.01 sec 304.391: [GC (Allocation Failure) [PSYoungGen: 166505K->4644K(168448K)] 210360K->51043K(518144K), 0.0077471 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 305.127: [GC (Allocation Failure) [PSYoungGen: 166948K->4623K(168448K)] 213347K->53656K(518144K), 0.0063692 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 305.804: [GC (Allocation Failure) [PSYoungGen: 166927K->4882K(168448K)] 215960K->56501K(518144K), 0.0064685 secs] [Times: user=0.02 sys=0.00, real=0.01 sec 306.553: [GC (Allocation Failure) [PSYoungGen: 167186K->4742K(168448K)] 218805K->58971K(518144K), 0.0065102 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 307.250: [GC (Allocation Failure) [PSYoungGen: 167046K->4540K(168448K)] 221275K->61398K(518144K), 0.0064846 secs] [Times: user=0.03 sys=0.00, real=0.01 secs] 307.992: [GC (Allocation Failure) [PSYoungGen: 166844K->4882K(168448K)] 223702K->64292K(518144K), 0.0064639 secs] [Times: user=0.03 sys=0.00, real=0.00 sec  毎秒以上の間隔で勢いよくGCが発生している
  • 31.  GCに要している時間を確認してみる  jstatコマンドを使用  ex. jstat -gccause -h5 -t 9789 1000 jmeterチューニング::その2 Timestamp S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC 300.7 0.00 78.31 17.36 18.35 75.99 87.98 459 3.317 37 2.172 5.490 Allocation Failure No GC 301.7 0.00 0.00 37.52 11.06 33.63 65.81 461 3.328 38 2.227 5.555 Metadata GC Threshold No GC 302.7 85.12 0.00 77.12 11.06 41.39 67.71 462 3.332 38 2.227 5.559 Allocation Failure No GC 303.7 68.38 0.00 13.62 12.54 57.14 71.74 464 3.345 38 2.227 5.572 Allocation Failure No GC 304.7 0.00 75.60 44.51 13.27 64.90 73.76 465 3.352 38 2.227 5.579 Allocation Failure No GC 305.7 75.25 0.00 89.48 14.02 73.10 75.83 466 3.359 38 2.227 5.586 Allocation Failure No GC 306.7 77.20 0.00 33.95 15.51 78.12 79.97 468 3.371 38 2.227 5.599 Allocation Failure No GC 307.7 0.00 73.90 60.39 16.26 77.40 81.93 469 3.378 38 2.227 5.605 Allocation Failure No GC 308.7 79.47 0.00 82.88 16.99 76.98 84.00 470 3.384 38 2.227 5.612 Allocation Failure No GC 309.7 83.74 0.00 25.91 18.48 75.98 88.03 472 3.397 38 2.227 5.624 Allocation Failure No GC 項目 説明 S0, S1 Survivor Spaceの使用率(%) E Edenの使用率(%) O Old Generationの使用率(%) M Metaspaceの使用率(%) YGC Young GenerationのGC回数 項目 説明 YGCT YGCに要した時間(sec) FGC Full GC回数 FGCT Full GCに要した時間(sec) GCT GC総時間(YGCT + FGCT)
  • 32.  ・ヒープサイズを増やしてみる  ex. -Xms4096m -Xmx4096m  - ヒープの初期サイズ/最大サイズともに4G jmeterチューニング::その3 300.470: [GC (Allocation Failure) [PSYoungGen: 1304064K->32019K(1336320K)] 1342797K->70752K(4132864K), 0.0317416 secs] [Times: user=0.11 sys=0.00, real=0.03 s 303.093: [GC (Metadata GC Threshold) [PSYoungGen: 606193K->14041K(1350656K)] 644926K->66275K(4147200K), 0.0363289 secs] [Times: user=0.12 sys=0.00, real 303.130: [Full GC (Metadata GC Threshold) [PSYoungGen: 14041K->0K(1350656K)] [ParOldGen: 52234K->38488K(2796544K)] 66275K->38488K(4147200K), [Metaspace: 79290K->21255K(1103872K)], 0.0476072 secs] [Times: user=0.09 sys=0.00, real=0.05 secs] 308.982: [GC (Allocation Failure) [PSYoungGen: 1303040K->31014K(1350144K)] 1341528K->69510K(4146688K), 0.0266850 secs] [Times: user=0.12 sys=0.00, real=0.02 311.482: [GC (Metadata GC Threshold) [PSYoungGen: 614958K->14282K(1351168K)] 653454K->65675K(4147712K), 0.0303426 secs] [Times: user=0.11 sys=0.00, real=0. 311.512: [Full GC (Metadata GC Threshold) [PSYoungGen: 14282K->0K(1351168K)] [ParOldGen: 51392K->38656K(2796544K)] 65675K->38656K(4147712K), [Metaspace: 79286K->21249K(1107968K)], 0.0497781 secs] [Times: user=0.09 sys=0.00, real=0.05 secs]  頻度はだいぶ減った
  • 33.  YGCおよびYGCTは明らかに減った。それにより総GC時 間も短くなった。Full GCが若干増えているが…  ログからOld GenerationよりYoung Generationが問題に なっていることが窺える jmeterチューニング::その3 Timestamp S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC 300.1 0.00 0.00 91.30 1.39 37.08 65.67 76 2.115 40 2.302 4.417 Metadata GC Threshold No GC 301.1 0.00 99.27 10.59 1.39 77.45 81.90 77 2.147 40 2.302 4.449 Allocation Failure No GC 302.1 0.00 99.27 27.69 1.39 77.45 81.90 77 2.147 40 2.302 4.449 Allocation Failure No GC 303.1 0.00 99.27 43.43 1.39 77.45 81.90 77 2.147 40 2.302 4.449 Allocation Failure No GC 304.1 0.00 0.00 16.75 1.38 37.08 65.66 78 2.183 41 2.349 4.533 Metadata GC Threshold No GC 305.1 0.00 0.00 33.10 1.38 37.08 65.66 78 2.183 41 2.349 4.533 Metadata GC Threshold No GC 306.1 0.00 0.00 50.44 1.38 37.08 65.66 78 2.183 41 2.349 4.533 Metadata GC Threshold No GC 307.1 0.00 0.00 67.35 1.38 37.08 65.66 78 2.183 41 2.349 4.533 Metadata GC Threshold No GC 308.1 0.00 0.00 84.67 1.38 37.08 65.66 78 2.183 41 2.349 4.533 Metadata GC Threshold No GC 309.1 0.00 65.84 2.75 1.38 77.45 81.85 79 2.210 41 2.349 4.559 Allocation Failure No GC
  • 34.  更に頻度が減った jmeterチューニング::その4 280.679: [Full GC (Metadata GC Threshold) [PSYoungGen: 40522K->0K(2050560K)] [ParOldGen: 51260K->50886K(2097152K)] 91783K->50886K(4147712K), [Metaspace: 79234K->21477K(1105920K)], 0.0613836 secs] [Times: user=0.15 sys=0.00, real=0.06 secs] 288.897: [GC (Metadata GC Threshold) [PSYoungGen: 1860458K->40765K(2051072K)] 1911345K->91651K(4148224K), 0.0472159 secs] [Times: user=0.14 sys=0.01, real= 288.944: [Full GC (Metadata GC Threshold) [PSYoungGen: 40765K->0K(2051072K)] [ParOldGen: 50886K->51279K(2097152K)] 91651K->51279K(4148224K), [Metaspace: 79277K->21381K(1105920K)], 0.0632846 secs] [Times: user=0.12 sys=0.00, real=0.07 secs] 297.318: [GC (Metadata GC Threshold) [PSYoungGen: 1872530K->40540K(2051072K)] 1923809K->91827K(4148224K), 0.0376583 secs] [Times: user=0.11 sys=0.00, real 297.355: [Full GC (Metadata GC Threshold) [PSYoungGen: 40540K->0K(2051072K)] [ParOldGen: 51287K->51313K(2097152K)] 91827K->51313K(4148224K), [Metaspace: 79305K->21404K(1105920K)], 0.0536986 secs] [Times: user=0.11 sys=0.00, real=0.06 secs] 305.855: [GC (Metadata GC Threshold) [PSYoungGen: 1873542K->40245K(2051072K)] 1924856K->91559K(4148224K), 0.0400885 secs] [Times: user=0.18 sys=0.00, re 305.895: [Full GC (Metadata GC Threshold) [PSYoungGen: 40245K->0K(2051072K)] [ParOldGen: 51313K->50980K(2097152K)] 91559K->50980K(4148224K), [Metaspace: 79236K->21339K(1105920K)], 0.0509746 secs] [Times: user=0.12 sys=0.00, real=0.05 secs]  Young Generation領域を調整してみる  ex. -XX:NewRatio=1 -XX:SurvivorRatio=8  - Young Generation:Old Generation = 1:1  - Eden:Survivor Space = 8:1
  • 35.  YGCは更に減った。総GC時間も短くなった。 jmeterチューニング::その4 Timestamp S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC 300.1 0.00 0.00 30.94 2.45 36.12 65.78 41 1.370 41 2.311 3.681 Metadata GC Threshold No GC 301.1 0.00 0.00 41.52 2.45 36.12 65.78 41 1.370 41 2.311 3.681 Metadata GC Threshold No GC 302.1 0.00 0.00 52.49 2.45 36.12 65.78 41 1.370 41 2.311 3.681 Metadata GC Threshold No GC 303.1 0.00 0.00 63.66 2.45 36.12 65.78 41 1.370 41 2.311 3.681 Metadata GC Threshold No GC 304.1 0.00 0.00 75.24 2.45 36.12 65.78 41 1.370 41 2.311 3.681 Metadata GC Threshold No GC 305.1 0.00 0.00 85.61 2.45 36.12 65.78 41 1.370 41 2.311 3.681 Metadata GC Threshold No GC 306.1 0.00 0.00 3.33 2.43 36.01 65.67 42 1.410 42 2.362 3.772 Metadata GC Threshold No GC 307.1 0.00 0.00 14.09 2.43 36.01 65.67 42 1.410 42 2.362 3.772 Metadata GC Threshold No GC 308.1 0.00 0.00 25.84 2.43 36.01 65.67 42 1.410 42 2.362 3.772 Metadata GC Threshold No GC 309.1 0.00 0.00 36.42 2.43 36.01 65.67 42 1.410 42 2.362 3.772 Metadata GC Threshold No GC
  • 36.  Metadata領域を調整してみる  ex. -XX:MetaspaceSize=3072m  -XX:MaxMetaspaceSize=4096m  - MetaspaceSize…Metaspace領域に起因する  Full GCの基準値(bytes)  - MaxMetaspaceSize…Metaspace領域のサイズ最大値 jmeterチューニング::その5 256.643: [GC (Allocation Failure) [PSYoungGen: 2042812K->40697K(2050048K)] 2122592K->123926K(4147200K), 0.0223751 secs] [Times: user=0.08 sys=0.01, real=0.0 266.073: [GC (Allocation Failure) [PSYoungGen: 2043641K->42246K(2050048K)] 2126870K->128055K(4147200K), 0.0213952 secs] [Times: user=0.07 sys=0.00, real=0. 275.462: [GC (Allocation Failure) [PSYoungGen: 2045190K->42083K(2051072K)] 2130999K->130455K(4148224K), 0.0227541 secs] [Times: user=0.07 sys=0.01, real=0.02 284.956: [GC (Allocation Failure) [PSYoungGen: 2046563K->41545K(2050560K)] 2134935K->133136K(4147712K), 0.0217961 secs] [Times: user=0.08 sys=0.01, real=0.02 294.342: [GC (Allocation Failure) [PSYoungGen: 2046025K->41711K(2051584K)] 2137616K->135994K(4148736K), 0.0232748 secs] [Times: user=0.08 sys=0.01, real=0.02 303.911: [GC (Allocation Failure) [PSYoungGen: 2047215K->41708K(2051072K)] 2141498K->138524K(4148224K), 0.0235565 secs] [Times: user=0.04 sys=0.00, real=0.03  若干頻度が減った程度だが…
  • 37.  FGCが激減(1回だけ)  総GC時間も短くなった jmeterチューニング::その5 Timestamp S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC 300.5 90.52 0.00 64.03 4.50 60.36 83.05 34 1.411 1 0.036 1.447 Allocation Failure No GC 301.5 90.52 0.00 74.92 4.50 60.36 83.05 34 1.411 1 0.036 1.447 Allocation Failure No GC 302.5 90.52 0.00 85.05 4.50 60.36 83.05 34 1.411 1 0.036 1.447 Allocation Failure No GC 303.6 90.52 0.00 96.15 4.50 60.36 83.05 34 1.411 1 0.036 1.447 Allocation Failure No GC 304.6 0.00 91.53 7.94 4.62 60.25 83.01 35 1.434 1 0.036 1.470 Allocation Failure No GC 305.6 0.00 91.53 17.61 4.62 60.25 83.01 35 1.434 1 0.036 1.470 Allocation Failure No GC 306.6 0.00 91.53 27.51 4.62 60.25 83.01 35 1.434 1 0.036 1.470 Allocation Failure No GC 307.6 0.00 91.53 39.25 4.62 60.25 83.01 35 1.434 1 0.036 1.470 Allocation Failure No GC 308.6 0.00 91.53 49.96 4.62 60.25 83.01 35 1.434 1 0.036 1.470 Allocation Failure No GC 309.6 0.00 91.53 60.89 4.62 60.25 83.01 35 1.434 1 0.036 1.470 Allocation Failure No GC
  • 38.  ・最初にFull GCが1発かかる (System.gc())  ・-XX:MetaspaceSize=3072mにしてもMetaspaceのサイズ自体が変 わってないのが確認できる jmeterチューニング::補足 0.631: [GC (System.gc()) [PSYoungGen: 203448K->9720K(1887744K)] 203448K->9736K(3984896K), 0.0070194 secs] [Times: user=0.02 sys=0.01, real=0.01 secs] 0.638: [Full GC (System.gc()) [PSYoungGen: 9720K->0K(1887744K)] [ParOldGen: 16K- >9402K(2097152K)] 9736K->9402K(3984896K), [Metaspace: 9492K->9492K(1058816K)], 0.0309553 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
  • 39.  jcmdで確認するとMetaspaceのサイズが変わってる  みたい (動的に変化)  - ex. jcmd 8749 PerfCounter.print | grep meta jmeterチューニング::補足 sun.gc.metaspace.capacity=2364276736 sun.gc.metaspace.maxCapacity=3403677696 sun.gc.metaspace.minCapacity=0 sun.gc.metaspace.used=1416081480  ・Full-GCを無くすというよりは、スループットを一定にする方が大事  ・ヒープを大きくすれば頻度を下げられるが、GC(Full GC)が発生し たときの停止時間も長くなる  ・今回のチューニングは一例に過ぎない。ケースバイケース