高負荷試験で得た経験談

1,671 views

Published on

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

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,671
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
29
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

高負荷試験で得た経験談

  1. 1. WebLogic Server 高負荷試験で得た経験談 性能改善の一例 2013/11/27 サクラシステムサービス株式会社 ソリューションサービス本部・モバイルビジネスセクション テクニカルマネージャー 王 鈺(おう ぎょく)
  2. 2. プロフィール 会社概要 サクラシステムサービス株式会社 (http://www.sakurasystem.co.jp) 自己紹介 通信業界の会社の某サービスシステムに対し、品質担 保用テストシステムの提案・開発・構築及び開発サポート を担当 Team WebLogic: 「やっぱり、WebLogic !」コミュニティ @Facebook に所属
  3. 3. はじめに 本日はJRockit R28をベースで動作するWeblogicの 高負荷状態をJVMのオプション設定により、改善する1 事例を紹介します。 今後JRockit JVMとJava HotSpot VMがHotRockit に統合する方向なので、役に立たないのではないかと の意見が出るかもしれません。アンケートでトラブル シューティングの事例紹介を求めた皆さんは同一事象 が出た場合の対処を望んでいるのではないかと思いま す。
  4. 4. Weblogicを取り巻く環境 凡例 問い合わせ系サーバ 外部WEBサービス FTP SOAP HTTP 独自プロトコル SIP RTP OracleDB 発信者 WEB ブラウザ メッセンジャー ストレージ WebLogicクラスタを中心とした 大規模なエンタプライズシステム Weblogicクラスタ Weblogicクラスタ ※守秘義務がある為、内部詳細について Weblogicクラスタ はブラックボックスとさせてください 【規模】: メール制御エンジン WEBページ: 秒間340ページビュー 電話 : 秒間40コール 電話制御エンジン ※同時3000回線以上の通話を対応 着信者 WEB ブラウザ メッセンジャー IP電話 IP電話 電話会議システム
  5. 5. 負荷試験の環境 凡例 (外部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
  6. 6. 事例について 目標としたシステム負荷をかけた場合、WeblogicSer verのCPU使用率が高く、プラットフォームの自己保護機 能で規制モードに入る事象が発生。 ↓ (Flight記録を取得する) Flight記録を確認、GC発生頻度は多くないので、 ヒープサイズの拡張等により、CPU使用率を下げる効 果は小さいと判断。 ホットメソッドを確認した結果、通常サービスで使用す るオブジェクトが上位を占めており、CPU実行時間を独 占するオブジェクトはない。 ※最上位は jrockit.vm.Locks.waitForThinRelease ↓ (スレッドダンプを取得する)
  7. 7. FlightRecorderの結果
  8. 8. 事例について(2) 5秒間隔で4回スレッドダンプを取得し、「侍」を使って内 容を確認。CPUを長時間占有するメソッドはなく、たくさん のスレッドが実行待ちの状態で止まっていることを確認。 ↓ (ネイティブ環境のCPU使用状況を確認) 高負荷をかけた状態でコマンド (vmstat –a 5 10)を投入、 ネイティブ環境においても、CPU待ちが多発していることを 確認。 ↓ (対処について考える) プログラムの設計及び設計ロジックを見直す時間がなく、 「システムの限界なのか?もう少し改善すれば、規制状態 に入ることを回避できるが」と悩む ↓ (スレッドダンプを再確認)
  9. 9. 確認内容 コマンド実行例: ランタイム待ちのプロセス数が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
  10. 10. 事例について(3) 「ホットメソッドの最上位waitForThinReleaseについ て何とかしないと」に戻る。そういえば、「fat lockに入る 前のthin lockはCPUを解放しないよね、ロック処理を 減らせば、CPU使用率が下げられる」と考えた。 ↓ (ロックを保持する処理の最適化可否を確認) ロジック上ロック処理の短縮は困難と判断。 ↓ (JRockitマニュアルを確認) 見つけた!! ( http://docs.oracle.com/cd/E22646_01/doc.40/b614 39/locktuning.htm)
  11. 11. 事例について(4) -xx-UseFatSpin オプション 「Javaのファット・ロック・スピン・コードを無効にし、ファッ ト・ロックを取得しようとするスレッドが直接スリープ状態に 入れるようにします。」 ↓ (早速使ってみた) 約5%程度CPU使用率を下げる効果があった。APLのロ ジックを改修せず、システムが規制モードに入ることの回 避ができた。 ★★ 目的達成!! ★★ ※ APLの内容にもよりますので、一概には言えないが、同じ状 況になった場合、一度試してみる価値はあると思います。
  12. 12. 終わりに Weblogicのトラブルシューティングについて ・サーバログ、APLログの確認 ・Flight記録の確認 ・スレッドダンプの確認 ・ネイティブマシンの状況確認 上記確認の技術を身につけることは重要です。 WebLogic勉強会に参加することは勉強する近道と思います。

×