-
- いいね！0
Tatsuno Yasuhiro
@exoego
JavaOne2013でTwitterの中の人がJavaでパフォーマンスならって紹介してた本の訳書 #jdt54 #JavaDayTokyo
2015-04-08 16:19:05
hiroisojp
@hiroisojp
スケーラビリティ重要、ピーキー対応重要 -> AWS。だけど、そんな簡単に全部持っていけるか？じゃあどうしようがこのセッション #jdt54 #JavaDayTokyo
2015-04-08 16:21:52
Toshiaki Maki 💉💉
@making
AWSに移行できない人に向けた話 #JavaDayTokyo #jdt54 pic.twitter.com/IVcWPNnjJ2
2015-04-08 16:22:47
拡大
hiroisojp
@hiroisojp
暫定対処（低コスト）-> 根本解決（高コスト）の順で アクセス数の制限、問題箇所の性能改善、ログ収集と可視化、インフラの改善 #jdt54 #JavaDayTokyo
2015-04-08 16:28:18
hiroisojp
@hiroisojp
アクセス数の制限、予約処理まで行ってるひとは制限せず、検索しに来た人を制限した。（予約しようとしてくれてる人を残す） #jdt54 #JavaDayTokyo
2015-04-08 16:29:40
きむち
@kimuchi583
予約処理に入った人は、続けられるは重要。最後の最後の確定実行ででエラーは最悪。 とあるサイトで起きたし… #jdt54 #JavaDayTokyo
2015-04-08 16:30:19
hiroisojp
@hiroisojp
AP、DBのCPU使用率 -> top、APのスレッドダンプ（遅い時に複数回） -> jstack #jdt54 #JavaDayTokyo
2015-04-08 16:31:42
Tatsuno Yasuhiro
@exoego
計測重要って完全に同意なんですけど、でしたら現状のログなりから性能可視化するほうが、問題箇所の改善より先じゃないのかな？ #jdt54 #JavaDayTokyo
2015-04-08 16:31:54
Keisuke.K
@Ewigkeit
遅い時に jstack 取るの重要。情報取得の際に本番だからシステムの負荷がーとか言うの非常にナンセンス。 #jdt54
2015-04-08 16:32:12
hiroisojp
@hiroisojp
CPU使用率が高い場合は、スレッドごとのCPU使用率を取ることが重要。（top -H or ps auxww -L | grep java ）#jdt54 #JavaDayTokyo
2015-04-08 16:35:23
hiroisojp
@hiroisojp
重い処理が「VM Thread」以外 -> スタックトレースに出てる処理が問題箇所 「VM Thread」でない場合、GCが怪しい #jdt54 #JavaDayTokyo
2015-04-08 16:39:49
Tatsuno Yasuhiro
@exoego
アプリサーバのCPU負荷が高いときはスレッドごとの負荷を見る。JavaのVMスレッドが重い→GC頻発してるおそれ。それ以外のJavaスレッドが重い→そのスタックトレースのロジックが悪い #jdt54 #JavaDayTokyo
2015-04-08 16:40:20
hiroisojp
@hiroisojp
GC頻発の可能性がある場合、ヒープ、GCの発生回数を確認する。（jstat -gc <PID> 1000） #jdt54 #JavaDayTokyo
2015-04-08 16:42:32