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

1 © NEC Corporation 2018
性能問題を起こしにくい
強いDBシステムの作り方（Ver. 2018.9）
２０１８年９月２１日
ＮＥＣソリューションイノベータ
太田智行
#dbts2018

自己紹介
太田智行（おおたともゆき）
これまで：リレーショナルデータベースひと筋１５年超
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

お伝えすること
テーマ
リレーショナルデータベースの性能
焦点
性能劣化予防（快適に走行させ＆維持すること）
※ DBにとっての性能
✓ 単位時間当たりの処理量（スループット）
✓ ある処理に要す処理時間（レイテンシ）

性能劣化予防 ⊂ 性能チューニング
性能チューニング
 起きてしまった問題の消火活動
（≒クエリチューニング）
 問題を起こしにくい強いDBシステムを作る
（しっかりした土台にまともなアプリを載せる）
本セッションの対象は“予防”
観点をリストアップします。個々の詳細や製品ごとの実装方法は別の機会に。

お伝えすること
初～中級者
これから作るシステムのチェックリストとして
上級者
頭の中にある過去経験の棚卸として

性能問題を起こしにくい
強いDBシステムの作り方（Ver. 2018.9）
２０１８年９月２１日
ＮＥＣソリューションイノベータ
太田智行
#dbts2018

もくじ
設計・製造フェーズ
先人の知恵を駆使してシステムに問題を組み込まない
評価フェーズ
実運用相当のデータとワークロードで評価する
運用フェーズ
定期的な走行チェックとメンテナンスで快適走行を維持する

設計、製造フェーズ
インフラ（足回り、パラメータ）

インフラ／足回り（おさらい）
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デバイス
ストレージ装置に装填された単一のドライブ（ハードディスクドライブやフラッシュドライブ）
を示す。
設計/製造評価運用

インフラ／足回り
用意されたI/Oデバイス群は全員しっかり働かせる
SQL ServerやOracleにはパーティショニング以外にもデバイス群を抽象化し負荷を平
準化する仕組みあり。PostgreSQLやMySQL InnoDBはストレージ設計に依存するか、
パーティショニングを利用する。
ファイルグループやASM
テーブルテーブル
・・・
ストライピング
例）SQL Server ファイルグループや Oracle
ASMはデバイス群をストライピングし負
荷を平準化する。

ファイルアクセスパターンや性能要件を考慮し配置する
• ログファイルへのWrite性能はDB性能にとって重要（可用性の観点でも）。
✓ データのDurabilityはログの書込みによって保証する仕組み（WAL）であるため。
• ログファイルは高性能（＆高可用）なデバイスに配置し、かつログファイル（シーク
I/O）とはアクセスパターンの異なるデータファイル（ランダムI/O）とは配置を分け
るのが望ましい。
✓ フラッシュデバイスだとアクセスパターン混合による性能影響が小さくなる。
✓ 分けすぎると管理煩雑＆利用効率悪化になるので注意（ASMはそこを担ってくれたりする）
データベースファイルはあらかじめ必要サイズ確保する
• コストを要すファイル拡張は構築時に済ませておく。
✓ PostgreSQLやMySQL InnoDBは初期サイズの概念は無く常時拡張。

SQL Server固有の留意点
• tempdbのデータファイルを分割する
• tempdbの混合エクステントは無効化する
• データファイルの瞬時初期化を有効化する
• 複数データファイル構成時は同時拡張を有効化する
• DWH用途の場合はスタートアップ-Eを有効化する
• ログファイルは単一ファイルで構成する
その理由や効果など詳細はWebで
http://bit.ly/2xmHRD8

基礎はとても大事
出典) https://twitter.com/hashtag/傾いたマンション

インフラ／パラメータ
ＤＢメモリサイズ調整
例えば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, …

ＤＢバッファの物理メモリへのピン止め
ＤＢバッファを優遇しスワップ対象外にする。
✓ SQL Server：Lock Page in Memory
✓ Oracle：lock_pga, use_large_pages
✓ PostgreSQL：huge_pages
✓ MySQL InnoDB：large-pages

ＣＰＵの振る舞い調整
• 省電力機能：省エネ 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 はパラレルクエリがプレビューで提供されている）

チェックポイント頻度調整
チェックポイントにともなう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量
経過時間経過時間

インデックスFILLFACTOR調整 Oracle用語はPCTFREE、他DBはFILLFACTOR
• インデックスページのデータ充填率を下げておくこと（あらかじめページ内の空き領
域を確保しておく）でページ分割の発生を回避する。
✓ ページ分割はリソースを集中的に消費する操作＆断片化を起こし性能劣化要因。
• 充填率を下げることのトレードオフとして、ファイルサイズが大きくなのるので注意。
• インデックスリビルド頻度（=FILLFACTORリセット契機）とあわせて設計を行う。
キーポインタ
10 ・・・
20 ・・・
30 ・・・
40 ・・・
50 ・・・
60 ・・・
キーポインタ
10 ・・・
20 ・・・
21 ・・・
30 ・・・
キーポインタ
40 ・・・
50 ・・・
60 ・・・
INSERT
キー = 21
ページ分割が発生。
あらかじめメンテ時に空き
を作っておくことで運用中
のペナルティを回避。

行のバージョン管理（MVCC）の調整（SQL Server 固有）
SQL ServerはMVCCが既定で無効。これを有効にすることで共有ロックと排他ロッ
クの競合がなくなり同時実行性が向上→スループットが向上する。
バージョン管理としてストレージに対する追加負荷が生じる。
optimize for adhoc workloads （SQL Server 固有）
クエリは再利用に備えコンパイルされた形式でキャッシュされるが、アドホックなクエリ（＝
パラメータ化されていないクエリ、プロシージャ化されていないクエリ）については再利用頻
度が低く、コンパイル（CPU負荷）とキャッシュ（メモリ圧迫）が無駄になる。
このオプションはアドホッククエリの初回実行に限りコンパイルをパスするよう振る舞うこと
で、CPU、メモリの負荷軽減を図る。

アクセスパス（インデックス、ヒント）

アクセスパス
インデックスにより効率的なアクセスパスを提供する
• インデックスはあればあっただけ良いというものではない
インデックスはデータ変更処理に追加コストを要す。特にOLTPではオンライン中に追加コス
トを要すため、インデックス定義は最小限が望まししい。使われないインデックスは百害
あって一利なし。
• インデックスの構造を踏まえた適切なインデックスを利用する
B-Tree（非クラスタ化、クラスタ化、付加列）、カラムナー、ビットマップ、ハッシュ、…
• 作りっぱなしはだめ
定期メンテが必要（後述）。
• 良いパスをどうしても計画してくれなければヒント矯正
統計情報（≒計画をたてるための判断材料）のメンテが大前提

アクセスパス
インデックス（B-Tree）追加の一般的なガイドライン
• 検索条件や結合条件で頻繁に使用されている列を対象に必要な列のみ。
• 一意、非NULLな列を対象にする。
• 取りうる値の種類数（ｶｰﾃﾞｨﾅﾘﾃｨ）が大きい＆値分布に偏りがないことが望ましい。
• キー長は小さく。可変長列は避ける。
• インデックス並び順は頻繁に要求される並び順と揃える。
• 複合インデックスの場合、使用頻度の高い列や選択性（※）の低い列を先頭にする。
※ 選択性 selectivity
解釈がいくつかあり、上と下では意味がほぼ逆
全行に対する抽出条件適用によって得られる行数の割合（上記の選択性はこっちで解釈）
（count(data) where = 抽出条件）／count(data)
全行に対する取りうる値の種類数の割合
count(distinct data) ／ count(data)

アプリ（べからず）

アプリ
インデックスが利かないかもしれないケース例
• 検索条件句内で関数 DEMO
• 検索条件句内で演算 DEMO
• 検索条件値の否定
• 検索条件値のor
• 検索条件値のNULL
• 後方一致や中間一致のLIKE（全文検索機能を検討）
意図しないフルスキャンかもしれないケース例
• ％指定のTOP DEMO
• ORDER BY NEWID()、ORDER BY RAND() DEMO

アプリ
一般的なガイドライン
• トランザクションスコープは極力絞る
• リモートクエリは必要性を見極める
• 入れ子ビューや複雑難解クエリは極力避ける
• SELECT * はやめたほうがいい
• 結合条件の付け忘れに注意
• OLTPにおいてデータ量に依存したクエリに注意
• アドホッククエリを避けパラメータ化する
• パラメータの型やサイズは厳密に指定する
• パラメータに応じた性能の揺れに留意する
• ストアドプロシージャは引数のパラメータに対して計画が最適化される DEMO
• クエリの検索条件句内で変数参照しない

アプリ
厄介ケース例：パラメータスニッフィング問題
• 問題点：同じクエリでも与えるパラメータによって性能に揺れがでる。
• 原因：計画は初回に渡されたパラメータに対して最適化されるため、その後に渡るパラメータに
対しては必ずしも最適であるとは限らないため。
• 改善策
✓ 実行の都度計画を立て直す（リコンパイル）
✓ 汎用的な計画になるようヒントで計画を矯正する
✓ 汎用的な計画になるような計画用のパラメータを渡す、もしくは統計に基づく最適パラメータ
をDBに決めさせる
➢ SQL Server：OPTMIZE FOR, TF4136（, Adaptive Query Processing）
※ Oracle言葉だとバインドピーク問題
➢ Oracle：_OPTIM_PEEK_USER_BINDS, Adaptive Cursor Sharing, Adaptive Plans, Adaptive Statistics
DEMO

アプリ
厄介ケース例：条件値の型不一致
• 問題点：暗黙型変換のオーバヘッドや非効率なアクセスパス
• 解決策：条件値の型を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

アプリ
厄介ケース例：条件値の型サイズ不一致
• 問題点：不必要なキャッシュ圧迫
• 解決策：条件値の型サイズをDB側の定義に厳密一致させる
• 原因：
✓ 設計時の考慮漏れ（要規約化）
✓ 実装時のケアレスミス
✓ 厄介なケース（SQL Server）
➢ .NETの場合、パラメータのサイズが未指定だと与えられたパラメータのサイズが自動指定される。一方でDB
側はわたってくるパラメータのサイズごとに計画が作成される振る舞いになるため、これが非効率なキャッ
シュ利用によるキャッシュ圧迫となる。
 計画が不適切になる（クエリが遅い）わけではないので表面上問題がみえない点が厄介。
➢ キャッシュ圧迫によるプランキャッシュ落ちとパラメータスニッフィング(前述)問題が重なると、性能の揺
れが激しくなり、かなり厄介なことになる。

評価
性能評価は実運用相当のデータとワークロードを用いる
• 性能が良い≒真に必要なデータを可能な限り最小の労力・時間でピックアップする
こと。その計画はデータの状態（量や種類）と欲しいデータの条件（クエリ）に基
づく。ゆえに性能評価にはできる限り実運用相当の条件を再現するのが望ましい。
✓ 遅いかもしれないことに気がつける程度量のテストデータを製造段階で提供できると望ま
しい。
• ワークロード（負荷量、多重度、参照・更新パターンなどシナリオ）の再現も重要。
✓ 同じ処理の繰り返しでキャッシュが利いてしまう
✓ DMLなどの冪等でない処理は工夫が必要
✓ テストデータ作成は外部キー制約などの整合やアプリ側の条件値との整合をとらねばいけ
ない。
✓ Etc
計画に組み込み、ツールの手をかりつつ地道＆確実にやる

運用フェーズ
定期メンテナンス

定期メンテ
統計情報
統計情報の精度・鮮度は性能に直結。統計情報のメンテナンス挙動把握が大事。
✓ SQL Serverの場合は
統計情報は自動的に作成/更新される。
作成：Indexが作成された列WHERE句やJOIN句の条件となった列に対して自動作成
（手動作成も可）。
更新：ざっくり目安としてレコード数の20%に相当するレコードが変更されたタイ
ミングで自動更新（レコード数増加に応じて20％閾値は自動調整される）。
ただし計画的な手動更新も必要となる場合もある。
一定のデータ量手動更新不要
一貫した増加傾向基本的には自動更新に任せておけばよい
一定間隔の増減反復バッチ処理のような大量更新を行う場合は手動更新とセットで実施（初回クエリが犠牲にならないように）
データの分布変化自動更新しきい値未満でもデータ分布に影響を与える変更を行う場合は手動更新をセットで実施
新しいデータの参照新しいデータのみ参照したい場合は手動更新をセットで実施

定期メンテ
参考：クエリ実行にともなう統計情報更新
① クエリプラン
キャッシュの検索
.
② 関連する統計情報
のロード
成功
③b 古い統計情報
はあるか
Yes
No
③a 更新が必要な統計情報すべてを更新
④ クエリプラン生成とリコンパイル閾値の設定
⑤ クエリプランのテスト（スキーマチェック）
⑥ スキーマ
は有効か
Yes
⑦ 新しい統計情報
を使用できるか
⑧ 古い統計情報
はあるか
⑨ クエリ
実行
Yes Yes
No No
⑩ リコンパイル
No
失敗
.
S E
クエリ
実行開始
クエリ
実行終了

定期メンテ
デフラグ
変更に伴うデータ断片化→I/O量やインストラクション増大→性能劣化、これを解消・
予防するために、インデックスを監視しデフラグ（リビルド）を行う。
※. PostgreSQLはヒープ内で追記型MVCCするため、ヒープもデフラグ（VACUUM
FULL）が必要（追記型MVCCゆえにインデックス更新頻度も高いがHOTという仕組み
で改善されている）。
✓ ページ密度（内部断片化）
ページ内データ装填率。未使用領域分の余計なI/Oによるアクセス効率低下。データ変更に伴
う装填率低下だけではなく、FILLFACTORで装填率をコントロールしているケースも。
同じデータ量に対して装填率100%と
50%ではI/Oページ量に2倍の差がでる装填率
100%
装填率
50%
vs

定期メンテ
デフラグ
✓ 断片の大きさや断片化率
データの並びが不連続状態になることでのアクセス効率低下。
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
大きさ=3
大きさ=1
大きさ=2
インデックスAの断片化率＝＝３７．５％
３（赤線ホップ数）
８（総ページ数）

定期メンテ
デフラグ
✓ B-Treeインデックスの高さ（深さ）
欲しいデータの番地を得るまでに辿らねばならないインデックスページが増えることでのア
クセス効率低下
1階
4階
3階
2階
最上階から1階に下るまでのコストを
4階建と3階建で比較すると単純計算で
1.3倍強になる（3階までなら階段で上
がってもいいけど4階となると…）。
vs
※ デフラグに関わる御法度（SQL Server）
インデックス再構築 (REBUILD)は100%精度の統計情報更新を伴うため、REBUILD直
後の統計情報更新は無意味。サンプリングの場合精度も下がる。

定期メンテ
ログファイルの再構築（SQL Server固有）
ログファイルはその内部に仮想ログを追加することで拡張するが、その仮想ログ
が増殖しすぎると性能に影響を与えるため、ログファイルの再構築を行う。
✓ 詳細はWebで http://bit.ly/2CXK3XX
定期診断と最適化
DBは生き物なので状態は変わる。当初の設計が必ずしも最適であるとは限らない。
定期的に点検を行い必要に応じて最適化することが望ましい。
✓ 問題予兆の早期検出と余裕を持った適切な未然対処。
✓ 更改タイミング見極め、サイジング目安（設備投資最適化）。
➢ クラウドなら即時アクション

運用フェーズ
定期走行チェック

走行チェック
性能スローダウン要因
• リソースが飽和
• 待機が多発
• アクセスパスが不適切
※ 問題視されやすいのはレイテンシ。
「この遅い処理をなんとかせよ！当然アプリロジックの改修やインフラ増強は不可！」
インフラのパラメータチューニングでどうにかなることも稀。

走行チェック
まずはアクセスパスを疑う（＝クエリチューニング）
そもそも適切にリソースを使えているのか？？まずはここを疑ってこそDBA。
アクセスパスが不適切ゆえのリソース飽和や待機多発であるケースは多い。
クラウドによって敷居は下がってはいてもスケールアップは容易ではない。まし
てやDBコストの支配項であるCPUパワーの追加はありえない。
同時にインフラがメンテされているか確認
クエリチューニング＝真に必要なデータをいかに少ない労力でピックアップする
か。その計画は土台の状態に依存。腐った土台の上でのクエリチューニングはモ
グラ叩きになりがち（腐った土台は状態が変化しやすい＝クエリチューニングの
前提が崩れやすい）。

走行チェック
走行チェックのポイント
• クエリ実行統計
問題視されやすいのはレイテンシ。クエリの実行時間をチェックする。
• インフラのメンテ状態
断片化の進行度合や統計情報の鮮度、インデックスの統計をチェックする。
• リソース利用や待機の推移
リソース負荷の閾値、過去と現在のトレンド差や傾きをチェック。
ベースラインを把握しておくことで問題が起きた際にその差がヒントになり
える。また性能以前にオーバーフロー停止してはダメなのでキャパシティ観
点もあわせてチェック。

走行チェック
• クエリ実行統計
✓ 実行時間
✓ 実行回数
✓ CPU時間
✓ I/O量（物理Read、論理Read、論理Write）
✓ レコード量
✓ 実行プラン
✓ 待機統計

走行チェック
✓ インデックス状態
➢ ページ密度
➢ 断片化率、断片の大きさ
➢ B-Treeの高さ
✓ 統計情報
➢ 更新日
➢ 精度、鮮度（列の変更カウンタ）
✓ トランザクションログ（SQL Server固有）
➢ VLF数

走行チェック
✓ インデックス利用統計
➢ 未使用
➢ 不足（オプティマイザが欲したインデックス）
➢ Read回数（シーク、スキャン回数、ルックアップ回数）
➢ Write回数
➢ ページ分割回数

走行チェック
• リソース利用や待機統計の推移
✓ CPU
➢ CPU時間（ユーサー、カーネル、アイドル、割り込み）
➢ コンテキストスイッチ
➢ キュー長
✓ Memory
➢ 使用量
➢ ページング
➢ 負荷（各種状態値）

走行チェック
✓ Disk
➢ 性能（スループット、レイテンシー、IOPS）
➢ 負荷（キュー長）
➢ 使用量
✓ Network
➢ 性能（スループット）
➢ 負荷（接続数、キュー長）

走行チェック
✓ DB Process
➢ CPU時間
➢ メモリ使用
➢ データ量
➢ レコード量
➢ スループット
➢ コネクション数
➢ リクエスト数
➢ クエリ処理統計
➢ ストレージ処理統計
➢ トランザクション処理統計
➢ バッファ処理統計
➢ アクセスパス処理統計
➢ I/O統計
➢ 待機統計

お伝えしたこと
設計・製造フェーズ
先人の知恵を駆使してシステムに問題を組み込まない
評価フェーズ
実運用相当のデータとワークロードで評価する
運用フェーズ
定期的な走行チェックとメンテナンスで快適走行を維持する
すべてをやるやりきることは難しいのも現状。
費用・時間との兼ね合いでできる限りのベストを！

さいごに
消火活動や設計後戻りは大変。
最初にケアしておくことが大事。
その重要性をしっかり訴求して
費用と時間と安息を勝ち取ろう！

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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 性能問題を起こしにくい強いDBシステムの作り方（Ver. 2018.9）

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

Mehr von Tomoyuki Oota

Mehr von Tomoyuki Oota (9)