PowerPoint Presentation

Size: px

Start display at page:

Download "PowerPoint Presentation"

みずきまつかた
4 years ago
Views:

1 1

2 データベースの症状からアプリの問題点を見つけるパフォーマンスドクター日本オラクル株式会社テクノロジー製品事業統括本部ソリューション本部基盤技術部プリンシパルエンジニア柴田竜典

3 以下の事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供を唯一の目的とするものでありいかなる契約にも組み込むことはできません以下の事項はマテリアルやコード機能を提供することをコミットメント ( 確約 ) するものではないため購買決定を行う際の判断材料になさらないで下さいオラクル製品に関して記載されている機能の開発リリースおよび時期については弊社の裁量により決定されます Oracle と Java は Oracle Corporation 及びその子会社関連会社の米国及びその他の国における登録商標です文中の社名商品名等は各社の商標または登録商標である場合があります 3

4 シバタツって誰? 日本オラクル株式会社テクノロジー製品事業統括本部ソリューション本部基盤技術部プリンシパルエンジニア柴田竜典 Oracle Technology Network にて全 5 回でシバタツ流! DWH チューニングの極意を連載これを読めば DWH デザインを間違わない! すべての回に似顔絵がついている! シバタツ検索 4

5 もう少しプロフィール Oracle Exadata リリース当初からお客様の SQL やデータを使用した PoC (Proof of Concept) を実施本番稼働しているたくさんのシステムのパフォーマンスチューニングを経験 2010 年には米オラクルの開発部門の一員としてサンフランシスコのヘッドクォーターで勤務米国のお客様の PoC を実施しつつそこから見えてきた Oracle Database のパフォーマンス課題の解決に取り組む 5

6 アプリケーションコードがシステムパフォーマンスに与える影響 6

7 アプリケーションコードがシステムパフォーマンスに与える影響アプリケーションコードがシステムパフォーマンスにどのくらい影響するかは無視できないこの事実は昔からよく知られている一方でこの事実は昔から無視されている悪いアプリケーションコードはハードウェアやソフトウェアへの投資を無意味にする Developer は悪いアプリケーションコードを書かない DBA は悪いアプリケーションコードを素早く見つけることが重要 7

8 本日紹介するパフォーマンスドクターの診断症例症例その1: 負荷が掛からない症例その2: 共有プールの具合が良くない症例その3: カーソルがいくつあっても足りない症例その4: しばらくすると負荷が止まりはじめる症例その5: 突然のサービス停止 8

9 症例その 1: 負荷が掛からない 9

10 症例その 1: 負荷が掛からない症状このアプリケーションではまったく負荷が掛からないレスポンス時間もスループットも良くない DBAはコネクション数を増やしたが改善しないデータベースがバグってるんじゃないの? 冬のボーナス商戦に向けてこのアプリケーションは悪くてもレスポンス時間 5ms スループット 3 万 tps を実現しないといけない 10

11 症例その 1: 負荷が掛からない診察レスポンス時間 : 150ms スループット : 300tps CPU 使用率の user と sys が同じくらい出ている 11

12 症例その 1: 負荷が掛からない原因 : 多発性ログイン = ログアウト症病名はフィクションです 12

13 症例その 1: 負荷が掛からない原因 for (i = 0; i < ; i++) { conn = ds.getconnection(userid, password); pstmt = conn.preparestatement("select name FROM employees WHERE id = " + i); rset = pstmt.executequery(); }... conn.close(); SQL 文実行のたびにログイン / ログアウトしている 13

14 症例その 1: 負荷が掛からない処方箋 conn = ds.getconnection(userid, password); for (i = 0; i < ; i++) { { pstmt = conn.preparestatement("select name FROM employees WHERE id = " + i); rset = pstmt.executequery(); }... conn.close(); 必要最小限のログイン / ログアウト 14

15 症例その 1: 負荷が掛からない症状多発性ログイン = ログアウト症が完治したことでレスポンス時間とスループットは多少良くなったが目標にはだいぶ遠い Concurrency の待機イベントがたくさん出ており共有プールの具合が良くない 15

16 症例その 1: 負荷が掛からない診察レスポンス時間 : 20ms スループット : 3,000tps latch: shared pool 16

17 症例その 1: 負荷が掛からない原因 : 慢性ハードパース病病名はフィクションです 17

18 症例その 1: 負荷が掛からない原因 conn = ds.getconnection(userid, password); for (i = 0; i < ; i++) { { pstmt = conn.preparestatement("select name FROM employees WHERE id = " + i); rset = pstmt.executequery(); }... conn.close(); 毎回ハードパースしている 18

19 症例その 1: 負荷が掛からない処方箋 conn = ds.getconnection(userid, password); for (i = 0; i < ; i++) { { pstmt = conn.preparestatement("select name FROM employees WHERE id =?"); pstmt.setint(1, i); rset = pstmt.executequery(); }... conn.close(); プレースホルダーを使うことで毎回ハードパースしない 19

20 症例その 1: 負荷が掛からない診察レスポンス時間 : 1ms スループット : 25,000tps 競合が解消したことで CPU がよく動いてる 20

21 症例その 1: 負荷が掛からないアドバイス conn = ds.getconnection(userid, password); pstmt = conn.preparestatement("select name FROM employees WHERE id =?"); for (i = 0; i < ; i++) { { pstmt.setint(1, i); rset = pstmt.executequery(); }... conn.close(); ソフトパースすらも毎回しない 21

22 症例その 1: 負荷が掛からない診察レスポンス時間 : 1ms スループット : 34,000tps スループットがさらに向上 22

23 症例その 1: 負荷が掛からない Logon/Transaction Hard Parse Soft Parse No Parse Transaction Rate x 1000 Response time(ms) 23

24 症例その 2: 共有プールの具合が良くない 24

25 症例その 2: 共有プールの具合が良くない症状本番環境同等の検証環境を持っている検証環境での性能が本番環境だとまったく出ない DBA は共有プール競合が多発していることを見つけアプリのソースコードをくまなく確認したが不必要な構文解析は起きていない Developer は本番環境とテスト環境で全く同じコードが動いていると主張している 25

26 症例その 2: 共有プールの具合が良くない診察スループットが検証環境に比べて大幅に悪い共有プール競合が多発 V$SYSSTAT ビューの parse count (failures) が増えていないかどうか確認 26

27 症例その 2: 共有プールの具合が良くない診察 SQL> SELECT name, value FROM v$sysstat 2> WHERE name = 'parse count (failures)'; NAME VALUE parse count (failures)

28 症例その 2: 共有プールの具合が良くない原因 : 構文解析障害症候群病名はフィクションです 28

29 症例その 2: 共有プールの具合が良くない原因本番環境でだけページ再読込み時のトリガーが存在しない隠しパラメーターをセットしようとしていた ALTER SESSION SET _INSTANT_TUNING = AUTO; すべてのユーザーがこの SQL を構文解析しようとしてすべてのセッションが共有プールでシリアライズされていた SQL*Net break/reset to client 待機イベントの数からも診断することができる 29

30 症例その 3: カーソルがいくつあっても足りない 30

31 症例その 3: カーソルがいくつあっても足りない症状 ORA-01000: 最大オープンカーソル数を超えましたが発生しアプリケーションが動作しなくなりアプリケーションの再起動が必要になる Developer は DBA にカーソル数を増やすことを依頼し DBA は初期化パラメータの OPEN_CURSOR に十分と思われるをセットしたエラーが出るまでの時間は延びたが結局しばらくすると ORA が発生してしまう 31

32 症例その 3: カーソルがいくつあっても足りない診察エラーが発生すると処理が停止 SQL*Net break/reset to client が多発オープン中のカーソルを確認 32

33 症例その 3: カーソルがいくつあっても足りない診察回数が 1 より大きいものは正しく閉じられていない可能性 33

34 症例その 3: カーソルがいくつあっても足りない原因 : カーソル閉鎖機能障害 [ 三大リーク病のひとつ ] 病名はフィクションです 34

35 症例その 3: カーソルがいくつあっても足りない原因 try {... rset = pstmt.executequery();... rset.close(); pstmt.close(); } catch (SQLException e) { e.printstacktrace(); } 例外処理に行ってしまうと pstmt をクローズしていない 35

36 症例その 3: カーソルがいくつあっても足りない処方箋 try { finallyで必ず... rset = pstmt.executequery(); pstmtをクローズする... rset.close(); } catch (SQLException e) { e.printstacktrace(); } finally { if (pstmt!= null) try {pstmt.close();} catch (SQLException e) {...} } 36

37 症例その 4: しばらくすると負荷が止まりはじめる 37

38 症例その 4: しばらくすると負荷が止まりはじめる症状アプリケーションを動かしてからしばらく経つとスループットが突然落ち始めるアプリケーションのログではタイムアウトが記録されている DBA はデータベースに問題がなくアプリケーションからの接続を増やして負荷を高めることを Developer に要求初期化パラメータの PROCESSES はすでにで十分 38

39 症例その 4: しばらくすると負荷が止まりはじめる診察スループットがゼロに近づいていく負荷もゼロに近づいていく OS のリソース使用量もゼロに近づいていく 39

40 症例その 4: しばらくすると負荷が止まりはじめる原因 : セッション閉鎖機能障害 [ 三大リーク病のひとつ ] 病名はフィクションです 40

41 症例その 4: しばらくすると負荷が止まりはじめる原因 try {... rset = pstmt.executequery();... rset.close(); pstmt.close(); conn.close(); } catch (SQLException e) { e.printstacktrace(); } 例外処理に行ってしまうと conn をクローズしていない 41

42 症例その 4: しばらくすると負荷が止まりはじめる処方箋 try {... rset = pstmt.executequery();... rset.close(); } catch (SQLException e) { e.printstacktrace(); } finally { } finally で必ず conn をクローズする if (pstmt!= null) try {pstmt.close();} catch (SQLException e) {...} if (conn!= null) try {conn.close();} catch (SQLException e) {...} 42

43 症例その 5: 突然のサービス停止 43

44 症例その 5: 突然のサービス停止症状何の前触れもなくデータベースがハングしたような状態になり同時にアプリケーションもタイムアウトしはじめた DBA はアクティブではない 1 個のセッションが取得しているロックを残りすべてのセッションが待っていることを確認したこの問題が起きるたびに DBA はロックを取得しているセッションを kill することでシステムを再稼働している 44

45 症例その 5: 突然のサービス停止診察ロック待ちによりすべてのセッションが待機 45

46 症例その 5: 突然のサービス停止診察 1 個のセッションが残りすべてのロック待ちを引き起こしていることが確認できる 46

47 症例その 5: 突然のサービス停止原因 : ロック解放機能障害 [ 三大リーク病のひとつ ] 病名はフィクションです 47

48 症例その 5: 突然のサービス停止原因ロックリークはセッションリークと同時に起きやすく例外処理内での COMMIT / ROLLBACK の処理に問題があることが多いコネクションプーリングをしているとリークしているセッションはロックを獲得したままコネクションを返却してしまいデータベースは COMMIT も ROLLBACK もされないまま放置される 48

49 症例その 5: 突然のサービス停止原因 try {... rset = pstmt.executeupdate();... conn.commit(); pstmt.close(); conn.close(); } catch (SQLException e) { e.printstacktrace(); } 例外処理に行ってしまうと COMMIT していないしかもセッションリークしている 49

50 症例その 5: 突然のサービス停止処方箋 try {... rset = pstmt.executupdate();... conn.commit(); } catch (SQLException e) { 失敗したときには ROLLBACK if (conn!= null ) try {conn.rollback();} catch (SQLException e) {...} e.printstacktrace(); } finally { if (pstmt!= null) try {pstmt.close();} catch (SQLException e) {...} if (conn!= null) try {conn.close();} catch (SQLException e) {...} } 50

51 本セッションのまとめ 51

52 本セッションのまとめアプリケーションコードがシステムパフォーマンスに与える影響これらの原因の多くは一般的によく知られている問題であるしかし無視されていることが現実には多いこれらの問題が引き起こす影響は DBA の視点からは不可解 _ 人人人人人人 _ > 問題の長期化 < Y^Y^Y^Y^Y^Y Developer は悪いアプリケーションコードを書かない DBA は悪いアプリケーションコードを素早く見つけることが重要 52

53 Database Oracle Database 11g : SQL チューニングワークショップ Oracle Database 11g で SQL を効率的にチューニングするための知識とノウハウを習得! 本コースではチューニング方法のみならずチューニングの方法論までも理解できます使用する Oracle の診断ツールおよび機能は自動 SQL チューニングコンポーネント EXPLAIN SQL Trace および TKPROF SQL*Plus AUTOTRACE ですまた物理的なスキーマおよび SQL 構文を変更することによるオプティマイザの動作への影響についても習得できます本コース修了時には以前のリリースで行っていた手動でのチューニング方法と比較した上で現在のリリースで提供される自動 SQL チューニング機能を使用できるようになります受講者は Oracle オプティマイザの概念を理解し体系化されたマシン演習を通じて講義内容をより深く理解できますコース内容 Oracle Database アーキテクチャの検討 SQL チューニングの概要オプティマイザの概要オプティマイザ演算子オプティマイザヒントの使用 SQL チューニングの自動化実行計画の解釈ケーススタディ : スター型変換オプティマイザ統計バインド変数の使用アプリケーショントレース ToD トレーニングオンデマンドにて提供中対象者データベースアプリケーション開発者受講料 (2012 年 9 月現在 ) 定価 218,295( 税込 ) Oracle PartnerNetwork 会員様はパートナー割引価格で受講いただけます集合研修教室での集合研修も絶賛開催中集合研修の日程は左上コース検索にてチューニングで検索頂けますお申込みお問合せオラクルユニバーシティ Tel:

54 54

55 55

MySQL研修コース & 資格のご案内

MySQL研修コース & 資格のご案内 < 写真欄 > MySQL 研修コース & 資格のご案内 2011/2/25 日本オラクル株式会社オラクルユニバーシティ以下の事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供を唯一の目的とするものでありいかなる契約にも組み込むことはできません以下の事項はマテリアルやコード機能を提供することをコミットメント ( 確約 ) するものではないため購買決定を行う際の判断材料になさらないで下さい