• Share
  • Email
  • Embed
  • Like
  • Private Content
高負荷試験で得た経験談
 

高負荷試験で得た経験談

on

  • 984 views

2013年11月27日に開催されたWebLogic Server勉強会@東京のLTセッションで ...

2013年11月27日に開催されたWebLogic Server勉強会@東京のLTセッションで
サクラシステムサービス株式会社の王 鈺(ぎょく)氏が使用した「高負荷試験で得た体験談」資料です。

Statistics

Views

Total Views
984
Views on SlideShare
983
Embed Views
1

Actions

Likes
2
Downloads
18
Comments
0

1 Embed 1

http://s.deeeki.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    高負荷試験で得た経験談 高負荷試験で得た経験談 Presentation Transcript

    • WebLogic Server 高負荷試験で得た経験談 性能改善の一例 2013/11/27 サクラシステムサービス株式会社 ソリューションサービス本部・モバイルビジネスセクション テクニカルマネージャー 王 鈺(おう ぎょく)
    • プロフィール 会社概要 サクラシステムサービス株式会社 (http://www.sakurasystem.co.jp) 自己紹介 通信業界の会社の某サービスシステムに対し、品質担 保用テストシステムの提案・開発・構築及び開発サポート を担当 Team WebLogic: 「やっぱり、WebLogic !」コミュニティ @Facebook に所属
    • はじめに 本日はJRockit R28をベースで動作するWeblogicの 高負荷状態をJVMのオプション設定により、改善する1 事例を紹介します。 今後JRockit JVMとJava HotSpot VMがHotRockit に統合する方向なので、役に立たないのではないかと の意見が出るかもしれません。アンケートでトラブル シューティングの事例紹介を求めた皆さんは同一事象 が出た場合の対処を望んでいるのではないかと思いま す。
    • Weblogicを取り巻く環境 凡例 問い合わせ系サーバ 外部WEBサービス FTP SOAP HTTP 独自プロトコル SIP RTP OracleDB 発信者 WEB ブラウザ メッセンジャー ストレージ WebLogicクラスタを中心とした 大規模なエンタプライズシステム Weblogicクラスタ Weblogicクラスタ ※守秘義務がある為、内部詳細について Weblogicクラスタ はブラックボックスとさせてください 【規模】: メール制御エンジン WEBページ: 秒間340ページビュー 電話 : 秒間40コール 電話制御エンジン ※同時3000回線以上の通話を対応 着信者 WEB ブラウザ メッセンジャー IP電話 IP電話 電話会議システム
    • 負荷試験の環境 凡例 (外部WEBサービス) Glassfish 発信者 Glassfish JMeter FTPサーバ 独自開発APL mobicent 独自開発APL (問い合わせ系サーバ) tomcat OracleDB ストレージ WebLogicクラスタを中心とした 大規模なエンタプライズシステム Weblogicクラスタ Weblogicクラスタ ※守秘義務がある為、内部詳細について Weblogicクラスタ はブラックボックスとさせてください メール制御エンジン 【規模】: WEBページ: 秒間340ページビュー 電話 電話制御エンジン : 秒間40コール ※同時3000回線以上の通話を対応 電話会議システム 状態監視(Zabbix+Glassfishベース) 統合制御 FTP SOAP HTTP 独自プロトコル SIP RTP 着信者 Glassfish JMeter FTPサーバ 独自開発APL mobicent 独自開発APL
    • 事例について 目標としたシステム負荷をかけた場合、WeblogicSer verのCPU使用率が高く、プラットフォームの自己保護機 能で規制モードに入る事象が発生。 ↓ (Flight記録を取得する) Flight記録を確認、GC発生頻度は多くないので、 ヒープサイズの拡張等により、CPU使用率を下げる効 果は小さいと判断。 ホットメソッドを確認した結果、通常サービスで使用す るオブジェクトが上位を占めており、CPU実行時間を独 占するオブジェクトはない。 ※最上位は jrockit.vm.Locks.waitForThinRelease ↓ (スレッドダンプを取得する)
    • FlightRecorderの結果
    • 事例について(2) 5秒間隔で4回スレッドダンプを取得し、「侍」を使って内 容を確認。CPUを長時間占有するメソッドはなく、たくさん のスレッドが実行待ちの状態で止まっていることを確認。 ↓ (ネイティブ環境のCPU使用状況を確認) 高負荷をかけた状態でコマンド (vmstat –a 5 10)を投入、 ネイティブ環境においても、CPU待ちが多発していることを 確認。 ↓ (対処について考える) プログラムの設計及び設計ロジックを見直す時間がなく、 「システムの限界なのか?もう少し改善すれば、規制状態 に入ることを回避できるが」と悩む ↓ (スレッドダンプを再確認)
    • 確認内容 コマンド実行例: ランタイム待ちのプロセス数がCPUのスレッド 処理数を超える状態が続く場合、CPUの数が 足りないと考えて良いと個人的に思います。 [root@xxxx000 ~]# vmstat -a 3 50 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----r b swpd free inact active si so bi bo in cs us sy id wa st 6 0 540400 3444224 12139480 36479760 0 0 0 46 9151 33128 17 11 72 3 0 540400 3444092 12139472 36479744 0 0 0 373 8913 32070 16 11 73 10 5 540400 3568608 12138296 36356684 0 0 0 166 9371 34475 18 11 71 5 0 540400 3483372 12138704 36440640 0 0 0 92 8095 31612 22 20 58 14 3 540400 3442620 12140288 36480764 0 0 0 303 9249 32744 18 10 71 4 0 540400 3442596 12140360 36480296 0 0 0 60 9071 33029 16 11 73 スレッドダンプの例 スレッドが待ち状態である 0 1 1 1 1 0 0 0 0 0 0 0 待っているもの "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'" id=19 idx=0x60 tid=6772 prio=5 alive, waiting, native_blocked, daemon -- Waiting for notification on: weblogic/work/ExecuteThread@0x109229b58[fat lock] at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method) at jrockit/vm/Locks.wait(Locks.java:1973)[inlined] at java/lang/Object.wait(Object.java:485)[inlined] at weblogic/work/ExecuteThread.waitForRequest(ExecuteThread.java:157)[optimized] ^-- Lock released while waiting: weblogic/work/ExecuteThread@0x109229b58[fat lock] at weblogic/work/ExecuteThread.run(ExecuteThread.java:178) at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method) -- end of trace
    • 事例について(3) 「ホットメソッドの最上位waitForThinReleaseについ て何とかしないと」に戻る。そういえば、「fat lockに入る 前のthin lockはCPUを解放しないよね、ロック処理を 減らせば、CPU使用率が下げられる」と考えた。 ↓ (ロックを保持する処理の最適化可否を確認) ロジック上ロック処理の短縮は困難と判断。 ↓ (JRockitマニュアルを確認) 見つけた!! ( http://docs.oracle.com/cd/E22646_01/doc.40/b614 39/locktuning.htm)
    • 事例について(4) -xx-UseFatSpin オプション 「Javaのファット・ロック・スピン・コードを無効にし、ファッ ト・ロックを取得しようとするスレッドが直接スリープ状態に 入れるようにします。」 ↓ (早速使ってみた) 約5%程度CPU使用率を下げる効果があった。APLのロ ジックを改修せず、システムが規制モードに入ることの回 避ができた。 ★★ 目的達成!! ★★ ※ APLの内容にもよりますので、一概には言えないが、同じ状 況になった場合、一度試してみる価値はあると思います。
    • 終わりに Weblogicのトラブルシューティングについて ・サーバログ、APLログの確認 ・Flight記録の確認 ・スレッドダンプの確認 ・ネイティブマシンの状況確認 上記確認の技術を身につけることは重要です。 WebLogic勉強会に参加することは勉強する近道と思います。