Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

性能問題を起こしにくい 強いDBシステムの作り方(Ver. 2018.9)

578 views

Published on

db tech showcase Tokyo 2018 のセッション資料です。

Published in: Data & Analytics
  • Be the first to comment

性能問題を起こしにくい 強いDBシステムの作り方(Ver. 2018.9)

  1. 1. 1 © NEC Corporation 2018 性能問題を起こしにくい 強いDBシステムの作り方(Ver. 2018.9) 2018年9月21日 NECソリューションイノベータ 太田 智行 #dbts2018
  2. 2. 3 © NEC Corporation 2018 自己紹介 太田 智行(おおた ともゆき) これまで:リレーショナルデータベースひと筋15年超 PostgreSQL 8年、 SQL Server 8年、Oracleちょこちょこ、MySQL 甘噛み程度 現在:Data Platform 全般で活動中 WebでSQL Server技術記事をゆるやかに連載中 https://enterprisezine.jp/dbonline/detail/9626 データエンジニアの会 https://data-engineer.connpass.com/ Microsoft MVP for Data Platform(2018.2~) https://mvp.microsoft.com/ja-jp/PublicProfile/5002980?fullName=Tomoyuki%20%20Oota
  3. 3. 4 © NEC Corporation 2018 お伝えすること テーマ リレーショナルデータベースの性能 焦点 性能劣化予防(快適に走行させ&維持すること) ※ DBにとっての性能 ✓ 単位時間当たりの処理量(スループット) ✓ ある処理に要す処理時間(レイテンシ)
  4. 4. 5 © NEC Corporation 2018 性能劣化予防 ⊂ 性能チューニング 性能チューニング  起きてしまった問題の消火活動 (≒クエリチューニング)  問題を起こしにくい強いDBシステムを作る (しっかりした土台 に まともなアプリ を載せる) 本セッションの対象は“予防” 観点をリストアップします。個々の詳細や製品ごとの実装方法は別の機会に。
  5. 5. 6 © NEC Corporation 2018 お伝えすること 初~中級者 これから作るシステムのチェックリストとして 上級者 頭の中にある過去経験の棚卸として
  6. 6. 7 © NEC Corporation 2018 性能問題を起こしにくい 強いDBシステムの作り方(Ver. 2018.9) 2018年9月21日 NECソリューションイノベータ 太田 智行 #dbts2018
  7. 7. 8 © NEC Corporation 2018 もくじ 設計・製造フェーズ 先人の知恵を駆使してシステムに問題を組み込まない 評価フェーズ 実運用相当のデータとワークロードで評価する 運用フェーズ 定期的な走行チェックとメンテナンスで快適走行を維持する
  8. 8. 設計、製造フェーズ インフラ(足回り、パラメータ)
  9. 9. 10 © NEC Corporation 2018 インフラ/足回り(おさらい) SQL Server インスタンス データベース ひとつ以上の複数のファイルグループとひとつ以上のトランザクションログを束ねた単一のデー タベースを示す。単一インスタンスに複数データベースを構成可能。 ファイルグループ ひとつ以上の複数のデータファイルを束ねた単一のグループを示す。テーブルやインデックスの 作成時はその保存先としてファイルグループを指定する。トランザクションログにはファイルグ ループの概念はない。 ファイル データベースを構成するファイルであるデータファイルとトランザクションログファイルを示す。 OS 論理ディスク OSが管理する単一の論理的なディスクを示す。単一の物理ディスクからひとつ以上の複数の論 理ディスクが切り出される。単一の論理ディスクで単一のファイルシステム(FAT、NTFS、ext、 xfsなど)を構成。”ボリューム”、”パーティション”、”ドライブ”などいくつかの異なる呼称あり。 物理ディスク ストレージ上のLUNをOSにマウントしたディスクを示す。OS視点の単一物理ディスクはスト レージ視点の単一論理ディスクに相当。 ストレージ LUN ストレージ装置が管理する単一の論理的なディスクを示す。単一のPoolからひとつ以上の複数の 論理ディスクが切り出される。ストレージ視点の単一論理ディスクはOS視点の単一物理ディス クに相当。LUNとはLogical Unit Numberの略称。 Pool 複数のI/Oデバイスを束ねた単一のRAID構成を示す。”RAIDグループ”などいくつかの異なる呼 称あり。 I/Oデバイス ストレージ装置に装填された単一のドライブ(ハードディスクドライブやフラッシュドライブ) を示す。 SQL Server インスタンス データベース ひとつ以上の複数のファイルグループとひとつ以上のトランザクションログを束ねた単一のデー タベースを示す。単一インスタンスに複数データベースを構成可能。 ファイルグループ ひとつ以上の複数のデータファイルを束ねた単一のグループを示す。テーブルやインデックスの 作成時はその保存先としてファイルグループを指定する。トランザクションログにはファイルグ ループの概念はない。 ファイル データベースを構成するファイルであるデータファイルとトランザクションログファイルを示す。 OS 論理ディスク OSが管理する単一の論理的なディスクを示す。単一の物理ディスクからひとつ以上の複数の論 理ディスクが切り出される。単一の論理ディスクで単一のファイルシステム(FAT、NTFS、ext、 xfsなど)を構成。”ボリューム”、”パーティション”、”ドライブ”などいくつかの異なる呼称あり。 物理ディスク ストレージ上のLUNをOSにマウントしたディスクを示す。OS視点の単一物理ディスクはスト レージ視点の単一論理ディスクに相当。 ストレージ LUN ストレージ装置が管理する単一の論理的なディスクを示す。単一のPoolからひとつ以上の複数の 論理ディスクが切り出される。ストレージ視点の単一論理ディスクはOS視点の単一物理ディス クに相当。LUNとはLogical Unit Numberの略称。 Pool 複数のI/Oデバイスを束ねた単一のRAID構成を示す。”RAIDグループ”などいくつかの異なる呼 称あり。 I/Oデバイス ストレージ装置に装填された単一のドライブ(ハードディスクドライブやフラッシュドライブ) を示す。 設計/製造 評価 運用
  10. 10. 11 © NEC Corporation 2018 インフラ/足回り 用意されたI/Oデバイス群は全員しっかり働かせる SQL ServerやOracleにはパーティショニング以外にもデバイス群を抽象化し負荷を平 準化する仕組みあり。PostgreSQLやMySQL InnoDBはストレージ設計に依存するか、 パーティショニングを利用する。 ファイルグループやASM テーブル テーブル ・・・ ストライピング 例)SQL Server ファイルグループ や Oracle ASMはデバイス群をストライピングし負 荷を平準化する。 設計/製造 評価 運用
  11. 11. 12 © NEC Corporation 2018 インフラ/足回り ファイルアクセスパターンや性能要件を考慮し配置する • ログファイルへのWrite性能はDB性能にとって重要(可用性の観点でも)。 ✓ データのDurabilityはログの書込みによって保証する仕組み(WAL)であるため。 • ログファイルは高性能(&高可用)なデバイスに配置し、かつログファイル(シーク I/O)とはアクセスパターンの異なるデータファイル(ランダムI/O)とは配置を分け るのが望ましい。 ✓ フラッシュデバイスだとアクセスパターン混合による性能影響が小さくなる。 ✓ 分けすぎると管理煩雑&利用効率悪化になるので注意(ASMはそこを担ってくれたりする) データベースファイルはあらかじめ必要サイズ確保する • コストを要すファイル拡張は構築時に済ませておく。 ✓ PostgreSQLやMySQL InnoDBは初期サイズの概念は無く常時拡張。 設計/製造 評価 運用
  12. 12. 13 © NEC Corporation 2018 インフラ/足回り SQL Server固有の留意点 • tempdbのデータファイルを分割する • tempdbの混合エクステントは無効化する • データファイルの瞬時初期化を有効化する • 複数データファイル構成時は同時拡張を有効化する • DWH用途の場合はスタートアップ-Eを有効化する • ログファイルは単一ファイルで構成する その理由や効果など詳細はWebで http://bit.ly/2xmHRD8 設計/製造 評価 運用
  13. 13. 14 © NEC Corporation 2018 インフラ/足回り 基礎はとても大事 出典) https://twitter.com/hashtag/傾いたマンション 設計/製造 評価 運用
  14. 14. 15 © NEC Corporation 2018 インフラ/パラメータ DBメモリサイズ調整 例えばSQL Serverの既定はサイズ上限なしで拡張する。OSからの返却要求時に即 座に対応できない場合はページングが発生し性能劣化を招く。これを避けるため に上限を設定し、その上限を踏まえた定期的な解放を行わせることが望ましい。 ✓ SQL Server:max server memory, min server memory, … ✓ Oracle:sga_target, pga_aggregate_target, memory_target, … ✓ PortgeSQL:shared_buffers, … ✓ MySQL InnoDB:innodb_buffer_pool_size, innodb_buffer_pool_instances, … 設計/製造 評価 運用
  15. 15. 16 © NEC Corporation 2018 インフラ/パラメータ DBバッファの物理メモリへのピン止め DBバッファを優遇しスワップ対象外にする。 ✓ SQL Server:Lock Page in Memory ✓ Oracle:lock_pga, use_large_pages ✓ PostgreSQL:huge_pages ✓ MySQL InnoDB:large-pages 設計/製造 評価 運用
  16. 16. 17 © NEC Corporation 2018 インフラ/パラメータ CPUの振る舞い調整 • 省電力機能:省エネ vs 性能 の判断。 • Hyper Threading:必ずしも効くとは限らずワークロード依存 パラレルクエリの並列度調整 並列処理はバッチ処理に有効に働くケースが多い。ただし同期オーバヘッドにも注意。 また同時実行性が求められるOLTP処理においては全体スループットが低下する場合あ り。 ✓ SQL Server:max degree of parallelism, cost threshold for parallelism ✓ Oracle:parallel_max_servers, parallel_min_servers, parallel_degree_policy, … ✓ PostgreSQL: max_parallel_workers, max_parallel_workers_per_gather, parallel_setup_cost、 parallel_tuple_cost, min_parallel_table_scan_size, min_parallel_index_scan_size ✓ MySQL InnoDB:パラレルクエリのネイティブサポートなし (Amazon Aurora MySQL はパラレルクエリがプレビューで提供されている) 設計/製造 評価 運用
  17. 17. 18 © NEC Corporation 2018 インフラ/パラメータ チェックポイント頻度調整 チェックポイントにともなうI/Oスパイクをどの程度散らすか。 I/O総量やリカバリ時間にも影響することに留意する。 ✓ SQL Server:recovery interval, TARGET_RECOVERY_TIME, -k ✓ Oracle: fast_start_mttr_target, log_checkpoint_interval, log_checkpoint_timeout ✓ PostgreSQL:max_wal_size, checkpoint_completion_target, checkpoint_timeout ✓ MySQL InnoDB:innodb_flush_neighbors, innodb_lru_scan_depth, innodb_adaptive_flushing, innodb_adaptive_flushing_lwm, innodb_max_dirty_pages_pct, innodb_max_dirty_pages_pct_lwm, innodb_io_capacity_max, innodb_flushing_avg_loops 間隔 短 長 I/Oスパイク 小 大 I/O総量 増 減 リカバリ時間 短 長 A C D B A B C B C A C D B A B C 間隔:短 スパイク:最大2 総量:9 間隔:長 スパイク:最大4 総量:7 チェックポイントI/O量 チェックポイントI/O量 経過時間 経過時間 設計/製造 評価 運用
  18. 18. 19 © NEC Corporation 2018 インフラ/パラメータ インデックスFILLFACTOR調整 Oracle用語はPCTFREE、他DBはFILLFACTOR • インデックスページのデータ充填率を下げておくこと(あらかじめページ内の空き領 域を確保しておく)でページ分割の発生を回避する。 ✓ ページ分割はリソースを集中的に消費する操作&断片化を起こし性能劣化要因。 • 充填率を下げることのトレードオフとして、ファイルサイズが大きくなのるので注意。 • インデックスリビルド頻度(=FILLFACTORリセット契機)とあわせて設計を行う。 キー ポインタ 10 ・・・ 20 ・・・ 30 ・・・ 40 ・・・ 50 ・・・ 60 ・・・ キー ポインタ 10 ・・・ 20 ・・・ 21 ・・・ 30 ・・・ キー ポインタ 40 ・・・ 50 ・・・ 60 ・・・ INSERT キー = 21 ページ分割が発生。 あらかじめメンテ時に空き を作っておくことで運用中 のペナルティを回避。 設計/製造 評価 運用
  19. 19. 20 © NEC Corporation 2018 インフラ/パラメータ 行のバージョン管理(MVCC)の調整(SQL Server 固有) SQL ServerはMVCCが既定で無効。これを有効にすることで共有ロックと排他ロッ クの競合がなくなり同時実行性が向上→スループットが向上する。 バージョン管理としてストレージに対する追加負荷が生じる。 optimize for adhoc workloads (SQL Server 固有) クエリは再利用に備えコンパイルされた形式でキャッシュされるが、アドホックなクエリ(= パラメータ化されていないクエリ、プロシージャ化されていないクエリ)については再利用頻 度が低く、コンパイル(CPU負荷)とキャッシュ(メモリ圧迫)が無駄になる。 このオプションはアドホッククエリの初回実行に限りコンパイルをパスするよう振る舞うこと で、CPU、メモリの負荷軽減を図る。 設計/製造 評価 運用
  20. 20. 設計、製造フェーズ アクセスパス(インデックス、ヒント)
  21. 21. 22 © NEC Corporation 2018 アクセスパス インデックスにより効率的なアクセスパスを提供する • インデックスはあればあっただけ良いというものではない インデックスはデータ変更処理に追加コストを要す。特にOLTPではオンライン中に追加コス トを要すため、インデックス定義は最小限が望まししい。使われないインデックスは百害 あって一利なし。 • インデックスの構造を踏まえた適切なインデックスを利用する B-Tree(非クラスタ化、クラスタ化、付加列)、カラムナー、ビットマップ、ハッシュ、… • 作りっぱなしはだめ 定期メンテが必要(後述)。 • 良いパスをどうしても計画してくれなければヒント矯正 統計情報(≒計画をたてるための判断材料)のメンテが大前提 設計/製造 評価 運用
  22. 22. 23 © NEC Corporation 2018 アクセスパス インデックス(B-Tree)追加の一般的なガイドライン • 検索条件や結合条件で頻繁に使用されている列を対象に必要な列のみ。 • 一意、非NULLな列を対象にする。 • 取りうる値の種類数(カーディナリティ)が大きい & 値分布に偏りがないことが望ましい。 • キー長は小さく。可変長列は避ける。 • インデックス並び順は頻繁に要求される並び順と揃える。 • 複合インデックスの場合、使用頻度の高い列や選択性(※)の低い列を先頭にする。 設計/製造 評価 運用 ※ 選択性 selectivity 解釈がいくつかあり、上と下では意味がほぼ逆 全行 に対する 抽出条件適用によって得られる行数の割合(上記の選択性はこっちで解釈) (count(data) where = 抽出条件)/count(data) 全行 に対する 取りうる値の種類数の割合 count(distinct data) / count(data)
  23. 23. 設計、製造フェーズ アプリ(べからず)
  24. 24. 25 © NEC Corporation 2018 アプリ インデックスが利かないかもしれないケース例 • 検索条件句内で関数 DEMO • 検索条件句内で演算 DEMO • 検索条件値の否定 • 検索条件値のor • 検索条件値のNULL • 後方一致や中間一致のLIKE(全文検索機能を検討) 意図しないフルスキャンかもしれないケース例 • %指定のTOP DEMO • ORDER BY NEWID()、ORDER BY RAND() DEMO 設計/製造 評価 運用
  25. 25. 26 © NEC Corporation 2018 アプリ 一般的なガイドライン • トランザクションスコープは極力絞る • リモートクエリは必要性を見極める • 入れ子ビューや複雑難解クエリは極力避ける • SELECT * はやめたほうがいい • 結合条件の付け忘れに注意 • OLTPにおいてデータ量に依存したクエリに注意 • アドホッククエリを避けパラメータ化する • パラメータの型やサイズは厳密に指定する • パラメータに応じた性能の揺れに留意する • ストアドプロシージャは引数のパラメータに対して計画が最適化される DEMO • クエリの検索条件句内で変数参照しない 設計/製造 評価 運用
  26. 26. 27 © NEC Corporation 2018 アプリ 厄介ケース例:パラメータスニッフィング問題 • 問題点:同じクエリでも与えるパラメータによって性能に揺れがでる。 • 原因:計画は初回に渡されたパラメータに対して最適化されるため、その後に渡るパラメータに 対しては必ずしも最適であるとは限らないため。 • 改善策 ✓ 実行の都度計画を立て直す(リコンパイル) ✓ 汎用的な計画になるようヒントで計画を矯正する ✓ 汎用的な計画になるような計画用のパラメータを渡す、もしくは統計に基づく最適パラメータ をDBに決めさせる ➢ SQL Server:OPTMIZE FOR, TF4136(, Adaptive Query Processing) ※ Oracle言葉だとバインドピーク問題 ➢ Oracle:_OPTIM_PEEK_USER_BINDS, Adaptive Cursor Sharing, Adaptive Plans, Adaptive Statistics 設計/製造 評価 運用 DEMO
  27. 27. 28 © NEC Corporation 2018 アプリ 厄介ケース例:条件値の型不一致 • 問題点:暗黙型変換のオーバヘッド や 非効率なアクセスパス • 解決策:条件値の型をDB側の定義に厳密一致させる • 原因: ✓ 設計時の考慮漏れ(要規約化) ✓ 実装時のケアレスミス(SQL Server) ➢ decimal/numeric型に対する小数点指定忘れ。 ➢ unicode型に対するNプレフィックス忘れ。 ✓ 厄介なケース(SQL Server) ➢ JDBC上の文字は既定でunicode型となる(sendStringParametersAsUnicodeの設定値に依存)。以下のよ うに実際の型(VARCHAR)に一致させていてもSQL Serverにはunicode型としてわたってしまい暗黙の型 変換が起きる。 pStmt.setObject(index, "文字列", Types.VARCHAR) 型不一致のプラン 型一致のプラン sendStringParametersAsUnicode setObject(非unicode) setObject(unicode) setString setNString true(既定) unicode unicode unicode unicode false 非unicode unicode 非unicode unicode 設計/製造 評価 運用 DEMO
  28. 28. 29 © NEC Corporation 2018 アプリ 厄介ケース例:条件値の型サイズ不一致 • 問題点:不必要なキャッシュ圧迫 • 解決策:条件値の型サイズをDB側の定義に厳密一致させる • 原因: ✓ 設計時の考慮漏れ(要規約化) ✓ 実装時のケアレスミス ✓ 厄介なケース(SQL Server) ➢ .NETの場合、パラメータのサイズが未指定だと与えられたパラメータのサイズが自動指定される。一方でDB 側はわたってくるパラメータのサイズごとに計画が作成される振る舞いになるため、これが非効率なキャッ シュ利用によるキャッシュ圧迫となる。  計画が不適切になる(クエリが遅い)わけではないので表面上問題がみえない点が厄介。 ➢ キャッシュ圧迫によるプランキャッシュ落ちとパラメータスニッフィング(前述)問題が重なると、性能の揺 れが激しくなり、かなり厄介なことになる。 設計/製造 評価 運用
  29. 29. 評価フェーズ
  30. 30. 31 © NEC Corporation 2018 評価 性能評価は実運用相当のデータとワークロードを用いる • 性能が良い≒真に必要なデータを可能な限り最小の労力・時間でピックアップする こと。その計画はデータの状態(量や種類)と欲しいデータの条件(クエリ)に基 づく。ゆえに性能評価にはできる限り実運用相当の条件を再現するのが望ましい。 ✓ 遅いかもしれないことに気がつける程度量のテストデータを製造段階で提供できると望ま しい。 • ワークロード(負荷量、多重度、参照・更新パターンなどシナリオ)の再現も重要。 ✓ 同じ処理の繰り返しでキャッシュが利いてしまう ✓ DMLなどの冪等でない処理は工夫が必要 ✓ テストデータ作成は外部キー制約などの整合やアプリ側の条件値との整合をとらねばいけ ない。 ✓ Etc 計画に組み込み、ツールの手をかりつつ地道&確実にやる 設計/製造 評価 運用
  31. 31. 運用フェーズ 定期メンテナンス
  32. 32. 33 © NEC Corporation 2018 定期メンテ 統計情報 統計情報の精度・鮮度は性能に直結。統計情報のメンテナンス挙動把握が大事。 ✓ SQL Serverの場合は 統計情報は自動的に作成/更新される。 作成:Indexが作成された列WHERE句やJOIN句の条件となった列に対して自動作成 (手動作成も可)。 更新:ざっくり目安としてレコード数の20%に相当するレコードが変更されたタイ ミングで自動更新(レコード数増加に応じて20%閾値は自動調整される)。 ただし計画的な手動更新も必要となる場合もある。 一定のデータ量 手動更新不要 一貫した増加傾向 基本的には自動更新に任せておけばよい 一定間隔の増減反復 バッチ処理のような大量更新を行う場合は手動更新とセットで実施(初回クエリが犠牲にならないように) データの分布変化 自動更新しきい値未満でもデータ分布に影響を与える変更を行う場合は手動更新をセットで実施 新しいデータの参照 新しいデータのみ参照したい場合は手動更新をセットで実施 設計/製造 評価 運用
  33. 33. 34 © NEC Corporation 2018 定期メンテ 参考:クエリ実行にともなう統計情報更新 ① クエリプラン キャッシュの検索 . ② 関連する統計情報 のロード 成功 ③b 古い統計情報 はあるか Yes No ③a 更新が必要な統計情報すべてを更新 ④ クエリプラン生成とリコンパイル閾値の設定 ⑤ クエリプランのテスト(スキーマチェック) ⑥ スキーマ は有効か Yes ⑦ 新しい統計情報 を使用できるか ⑧ 古い統計情報 はあるか ⑨ クエリ 実行 Yes Yes No No ⑩ リコンパイル 設計/製造 評価 運用 No 失敗 . S E クエリ 実行開始 クエリ 実行終了
  34. 34. 35 © NEC Corporation 2018 定期メンテ デフラグ 変更に伴うデータ断片化→I/O量やインストラクション増大→性能劣化、これを解消・ 予防するために、インデックスを監視しデフラグ(リビルド)を行う。 ※. PostgreSQLはヒープ内で追記型MVCCするため、ヒープもデフラグ(VACUUM FULL)が必要(追記型MVCCゆえにインデックス更新頻度も高いがHOTという仕組み で改善されている)。 ✓ ページ密度(内部断片化) ページ内データ装填率。未使用領域分の余計なI/Oによるアクセス効率低下。データ変更に伴 う装填率低下だけではなく、FILLFACTORで装填率をコントロールしているケースも。 同じデータ量に対して装填率100%と 50%ではI/Oページ量に2倍の差がでる装填率 100% 装填率 50% vs 設計/製造 評価 運用
  35. 35. 36 © NEC Corporation 2018 定期メンテ デフラグ ✓ 断片の大きさや断片化率 データの並びが不連続状態になることでのアクセス効率低下。 10 - 11 index record 11 10 20 index record 12 p n index record 13 p n index record 14 p n index record 15 26 16 index record 16 15 17 index record 17 16 18 index record 18 p n index record 19 p n index record 20 11 23 index record 21 p n index record 22 p n index record 23 20 24 index record 24 23 15 index record 25 p n index record ~ ファイル内の物理番地 → インデックスの論理順 → インデックスAの断片 大きさ=2 インデックスAの断片 大きさ=3 インデックスAの断片 大きさ=1 インデックスAの断片 大きさ=2 インデックスAの断片化率 = =37.5% 3(赤線ホップ数) 8(総ページ数) 設計/製造 評価 運用
  36. 36. 37 © NEC Corporation 2018 定期メンテ デフラグ ✓ B-Treeインデックスの高さ(深さ) 欲しいデータの番地を得るまでに辿らねばならないインデックスページが増えることでのア クセス効率低下 1階 4階 3階 2階 最上階から1階に下るまでのコストを 4階建と3階建で比較すると単純計算で 1.3倍強になる(3階までなら階段で上 がってもいいけど4階となると…)。 vs ※ デフラグに関わる御法度(SQL Server) インデックス再構築 (REBUILD)は100%精度の統計情報更新を伴うため、REBUILD直 後の統計情報更新は無意味。サンプリングの場合精度も下がる。 設計/製造 評価 運用
  37. 37. 38 © NEC Corporation 2018 定期メンテ ログファイルの再構築(SQL Server固有) ログファイルはその内部に仮想ログを追加することで拡張するが、その仮想ログ が増殖しすぎると性能に影響を与えるため、ログファイルの再構築を行う。 ✓ 詳細はWebで http://bit.ly/2CXK3XX 定期診断と最適化 DBは生き物なので状態は変わる。当初の設計が必ずしも最適であるとは限らない。 定期的に点検を行い必要に応じて最適化することが望ましい。 ✓ 問題予兆の早期検出と余裕を持った適切な未然対処。 ✓ 更改タイミング見極め、サイジング目安(設備投資最適化)。 ➢ クラウドなら即時アクション 設計/製造 評価 運用
  38. 38. 運用フェーズ 定期走行チェック
  39. 39. 40 © NEC Corporation 2018 走行チェック 性能スローダウン要因 • リソースが飽和 • 待機が多発 • アクセスパスが不適切 ※ 問題視されやすいのはレイテンシ。 「この遅い処理をなんとかせよ!当然アプリロジックの改修やインフラ増強は不可!」 インフラのパラメータチューニングでどうにかなることも稀。 設計/製造 評価 運用
  40. 40. 41 © NEC Corporation 2018 走行チェック まずはアクセスパスを疑う(=クエリチューニング) そもそも適切にリソースを使えているのか??まずはここを疑ってこそDBA。 アクセスパスが不適切ゆえのリソース飽和や待機多発であるケースは多い。 クラウドによって敷居は下がってはいてもスケールアップは容易ではない。まし てやDBコストの支配項であるCPUパワーの追加はありえない。 同時にインフラがメンテされているか確認 クエリチューニング=真に必要なデータをいかに少ない労力でピックアップする か。その計画は土台の状態に依存。腐った土台の上でのクエリチューニングはモ グラ叩きになりがち(腐った土台は状態が変化しやすい=クエリチューニングの 前提が崩れやすい)。 設計/製造 評価 運用
  41. 41. 42 © NEC Corporation 2018 走行チェック 走行チェックのポイント • クエリ実行統計 問題視されやすいのはレイテンシ。クエリの実行時間をチェックする。 • インフラのメンテ状態 断片化の進行度合や統計情報の鮮度、インデックスの統計をチェックする。 • リソース利用や待機の推移 リソース負荷の閾値、過去と現在のトレンド差や傾きをチェック。 ベースラインを把握しておくことで問題が起きた際にその差がヒントになり える。また性能以前にオーバーフロー停止してはダメなのでキャパシティ観 点もあわせてチェック。 設計/製造 評価 運用
  42. 42. 43 © NEC Corporation 2018 走行チェック 走行チェックのポイント • クエリ実行統計 ✓ 実行時間 ✓ 実行回数 ✓ CPU時間 ✓ I/O量(物理Read、論理Read、論理Write) ✓ レコード量 ✓ 実行プラン ✓ 待機統計 設計/製造 評価 運用
  43. 43. 44 © NEC Corporation 2018 走行チェック 走行チェックのポイント • インフラのメンテ状態 ✓ インデックス状態 ➢ ページ密度 ➢ 断片化率、断片の大きさ ➢ B-Treeの高さ ✓ 統計情報 ➢ 更新日 ➢ 精度、鮮度(列の変更カウンタ) ✓ トランザクションログ(SQL Server固有) ➢ VLF数 設計/製造 評価 運用
  44. 44. 45 © NEC Corporation 2018 走行チェック 走行チェックのポイント • インフラのメンテ状態 ✓ インデックス利用統計 ➢ 未使用 ➢ 不足(オプティマイザが欲したインデックス) ➢ Read回数(シーク、スキャン回数、ルックアップ回数) ➢ Write回数 ➢ ページ分割回数 設計/製造 評価 運用
  45. 45. 46 © NEC Corporation 2018 走行チェック 走行チェックのポイント • リソース利用や待機統計の推移 ✓ CPU ➢ CPU時間(ユーサー、カーネル、アイドル、割り込み) ➢ コンテキストスイッチ ➢ キュー長 ✓ Memory ➢ 使用量 ➢ ページング ➢ 負荷(各種状態値) 設計/製造 評価 運用
  46. 46. 47 © NEC Corporation 2018 走行チェック 走行チェックのポイント • リソース利用や待機統計の推移 ✓ Disk ➢ 性能(スループット、レイテンシー、IOPS) ➢ 負荷(キュー長) ➢ 使用量 ✓ Network ➢ 性能(スループット) ➢ 負荷(接続数、キュー長) 設計/製造 評価 運用
  47. 47. 48 © NEC Corporation 2018 走行チェック 走行チェックのポイント • リソース利用や待機統計の推移 ✓ DB Process ➢ CPU時間 ➢ メモリ使用 ➢ データ量 ➢ レコード量 ➢ スループット ➢ コネクション数 ➢ リクエスト数 ➢ クエリ処理統計 ➢ ストレージ処理統計 ➢ トランザクション処理統計 ➢ バッファ処理統計 ➢ アクセスパス処理統計 ➢ I/O統計 ➢ 待機統計 設計/製造 評価 運用
  48. 48. まとめ
  49. 49. 50 © NEC Corporation 2018 お伝えしたこと 設計・製造フェーズ 先人の知恵を駆使してシステムに問題を組み込まない 評価フェーズ 実運用相当のデータとワークロードで評価する 運用フェーズ 定期的な走行チェックとメンテナンスで快適走行を維持する すべてをやるやりきることは難しいのも現状。 費用・時間との兼ね合いでできる限りのベストを!
  50. 50. 51 © NEC Corporation 2018 さいごに 消火活動や設計後戻りは大変。 最初にケアしておくことが大事。 その重要性をしっかり訴求して 費用と時間と安息を勝ち取ろう!

×