パフォーマンス分析の例

ビデオの指示に従うには、こちらのサンプルレポートを開いてください。

パフォーマンスレポートの解釈方法

HQbird、または別のサービスとして、cc.ib-aid.comのIBSurgeon Performance Analysisを使用すると、Firebirdトレースログからパフォーマンスレポートを生成できます。

このレポートは、FirebirdデータベースでのSQLクエリ実行に関する詳細情報を提供する強力な診断ツールです。このガイドでは、トレースレポートを解釈して使用し、パフォーマンスのボトルネックを体系的に特定して解決する方法を説明します。

1. パフォーマンスレポートの構造

Code

┌─────────────────────────────────────────┐
│         Performance Report              │
├─────────────────────────────────────────┤
│ 1. Performance Summary Graphs           │
│    ┌────────────────────────┐           │
│    │  Top queries	      │           │
│    │     Top summary	      │           │
│    │     Top frequency      │           │
│    │     Durations          │           │
│    │     Fetches  	      │           │
│    │     Reads	      │           │
│    │     Writes	      │           │
│    │  Time Series Chart     │           │
│    │     Durations          │           │
│    │     Count of queries   │           │
│    │     Fetches            │           │
│    │     Reads/Writes       │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 2. Top Queries Analysis                 │
│    ┌────────────────────────┐           │
│    │ Query Rankings         │           │
│    │                        │           │
│    │  By Duration───┐       │           │
│    │                │       │           │
│    │  By Time   ────┤       │           │
│    │  Summary       │       │           │
│    │                │       │           │
│    │  By Plan   ────┤       │           │
│    │  Summary       │       │           │
│    │                │       │           │
│    │  By Frequency ─┤       │           │
│    │                │       │           │
│    │  By Plan    ───┤       │           │
│    │  Frequency     │       │           │
│    │                │       │           │
│    │  By Fetches ───┤       │           │
│    │                │       │           │
│    │  By Reads   ───┤       │           │
│    │                │       │           │
│    │  By Writes  ───┘       │           │
│    │                        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 3. Process Summary                      │
│    ┌────────────────────────┐           │
│    │ Per Process Stats      │           │
│    │ - Execution counts     │           │
│    │ - Fetches, etc	      │           │
│    │ - Duration metrics     │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 4. Address Summary                      │
│    ┌────────────────────────┐           │
│    │Per Client Address Stats│           │
│    │ - Connection counts    │           │
│    │ - Durations  	      │           │
│    │ - Fetches,etc          │    	  │
│    │ - Process names        │ 	  │
│    └────────────────────────┘           │
└─────────────────────────────────────────┘

Query Details Structure:
┌────────────────────┐
│ Query Information  │
├────────────────────┤
│ - SQL Text         │
│ - Transaction info │
│ - Execution Plan   │
│ - Duration Stats   │
│ - Resource Stats   │
│   * Fetches        │
│   * Reads          │
│   * Writes         │
│   * Marks          │
│ - Client Info      │
└────────────────────┘

パフォーマンスレポートは、データベースアクティビティの階層ビューを提供します：

パフォーマンスサマリーグラフ

時間経過に伴う主要メトリクスの視覚的表現 - アクティビティ/負荷のピークを簡単に確認できます。（HQbirdのAdvanced Performance Monitoringでは、分単位の分析レポートも利用可能で、その短縮版はPortalツールで利用できます - 詳細はこのビデオをご覧ください）。

パターンや異常の特定に役立ちます：パフォーマンスが良好な期間（例：先週/先月）のグラフとパフォーマンス問題のある期間のグラフを比較することで、問題の特定に役立ちます。

トップクエリ分析

包括的な分析のための複数のランキング視点：最長クエリ、最も頻繁なクエリ、最も時間を消費するクエリ（テキストまたはプランでグループ化）など。

各ディメンションが異なる最適化の機会を明らかにします
各クエリの詳細な統計情報：
期間メトリクス（最小、最大、平均、中央値）
リソース消費（フェッチ、リード、ライト）
実行パターン - トップクエリの発信元の数。

プロセスサマリー

実行プロセスごとに統計をグループ化
問題のあるアプリケーションの特定に役立ちます
プロセスごとのリソース消費とデータベース操作（接続、クエリなど）およびメトリクス（フェッチ、リードなど）を表示

アドレスサマリー

クライアント接続ごとに統計をグループ化
クライアント間の負荷分散を明らかにします
接続固有の問題の特定に役立ちます

各セクションは、異なるレベルでのパフォーマンス分析をサポートします：

システム全体のパターン（グラフ） - 問題が一般的にいつ、どこで発生するかを確認します。
クエリからの最も顕著な影響（トップクエリ） - 最初に最適化すべきクエリを特定します。
アプリケーションレベルの問題（プロセスサマリー） - パフォーマンス問題を引き起こすアプリケーションを特定します。
クライアントレベルの問題（アドレスサマリー） - 最大のクエリフローを持つIPアドレス（ワークステーション、クライアントコンピュータ）を特定します。

2. 時間サマリーとプランサマリー分析

パフォーマンスの状況分析は、サマリーセクションから開始することをお勧めします。サンプルレポートのPlan-Summaryセクションを開くにはここをクリック。

時間サマリーは、各一意のSQLステートメントパターンの合計実行時間を集計します。

これは、どのクエリが時間の経過とともに最も多くのデータベースリソースを消費しているかを示す「コストセンター」レポートと考えてください。

Code

クエリがパラメータ化されていない場合、つまりSQLテキスト内にパラメータプレースホルダ（:myparam1）の代わりにパラメータの値が明示的に含まれている場合は、セクション「Plan-Summary」を使用して頻度の高いクエリを特定する必要があります。

非参数化查询示例：‘SELECT * FROM COUNTRY WHERE COUNTRYID=2’ 参数化查询示例：‘SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid’

Code


Summary 部分中的每个查询，其标题包含以下关键部分：

![](/download/trace/example_3_header.png)

- **Summary**：总时间百分比，显示该查询占整体数据库时间的比例。

- **Frequency**：查询模式出现的次数。

- **Fetch, Read, Write**：资源指标。

例如，如果有

```none hljs
Summary: 19.08% (3920272 of 20541791 ms)

这告诉我们，该查询模式消耗了总数据库时间的近 20%–这是一个相当大的比例，值得立即关注。

在标题下方的 Plan-Summary 部分，我们会看到用于分组查询的 SQL 执行计划；在 Time-Summary 中，则是查询本身的文本。

由于查询模式代表多个具体查询，因此与连接相关的具体信息取自与该模式对应的第一个查询：

在上面的截图中，您可以看到该模式示例语句的标题，它包含启动此 SQL 的应用程序名称、连接 ID 和事务 ID，以及 IP 地址和事务的详细信息。

接下来是计划（对于 Time-Summary；对于 Plan-Summary 则跳过，因为它在开头已经显示）、参数值（按出现顺序）以及每个表的统计信息：

请记住，在 Plan-Summary 中，我们使用执行计划对 SQL 进行分组，这意味着只有计划对该模式是固定的；而在 Time-Summary 中，我们使用 SQL 语句文本进行分组，其他内容（参数值、执行时间等）可能不同。请将此信息作为执行模式的示例（在 99% 的情况下，这足以重现问题）。

下面我们有一个针对此特定查询执行的单独图表。如您所见，该查询是在我们在概览图表上注意到的高负载期间启动的。

最后，我们有一个非常重要的统计集合，涵盖与该模式对应的所有查询，以及来源地址列表：

在这些统计信息中，我们可以看到最小值、最大值、平均值和中位数执行时间，以及针对 fetch、read、write 和 mark（缓存刷新操作）的相同统计信息。

2.1. 如何使用时间摘要：

首先识别消耗不成比例时间的查询（它们是此部分的前 3 名–#1、2、3）
将时间消耗与频率进行比较
在查询部分的底部查看平均执行时间（总时间 / 频率）（见下文）
寻找以下模式：
- 高时间 + 低频率 = 低效的单个查询
- 高时间 + 高频率 = 可能低效但使用频繁的查询

3. 频率分析：Frequency 和 Plan-Frequency

使用频率分析来了解查询运行的频率。可以把它想象成统计在高峰时段某条特定道路被使用了多少次。

Code

如果查询未参数化，即 SQL 文本中显式包含参数值而不是参数占位符（:myparam1），则有必要使用 "Plan-Summary" 部分来识别频率最高的查询。
非参数化查询示例：'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
参数化查询示例：'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

3.1. 理解频率影响

Frequency 查询模式的表示与 Plan/Time Summary 非常相似：

高频率查询就像繁忙的交叉路口–即使每辆车（查询）移动得很快，巨大的车流量也会导致拥堵。这会影响：

数据库连接（就像停车位–数量有限）
网络带宽（就像道路容量）
CPU 使用率（就像交通管制员不堪重负）
缓存效率（就像不得不重复访问相同的信息）

Code

要估算高频率查询的影响，请使用参数 threshold = 0 收集跟踪信息。

3.2. 频率影响类别

每秒执行次数	影响级别	潜在问题
>1000	严重	如同高峰时段的交通–系统资源不堪重负
100-1000	高	类似于稳定的车流–负载显著但可管理
10-100	中等	如同偶尔的交通–监控模式
<10	低	车流稀少–除非查询非常慢，否则影响最小


	高频率并不总是坏事–如果查询经过良好优化，它们可以频繁运行而不会出现问题。关键在于确保它们尽可能高效。实际上，这意味着前 3 个最频繁查询的查询中位数执行时间应为 0 毫秒（即小于 1 毫秒），并且不超过查询总执行次数的 50%。

3.3. 示例分析

让我们检查跟踪报告中的一个真实案例：

none

Frequency: 4,428 executions (24.43% of total)
Impact: Critical - high volume of SALES table queries
Root Cause: Repetitive customer balance checks
Optimization Priority: High

Explanation: This query is running thousands of times, similar to a
busy intersection. Even though each execution might be quick, the
cumulative impact is significant. The application might be checking
balances more often than necessary.

4. 分析 xx-Summary 和 Frequency 部分中顶级查询的统计信息

在分析 Firebird 跟踪报告时，每个查询分组都包含详细的聚合统计信息，这些信息为性能模式提供了关键见解。让我们分解每个指标并理解其对数据库优化的意义。

4.1. 聚合统计分析

让我们检查这组示例统计信息：

none

Total: 4428 items:
Durations: min: 351; max: 3919; avg: 457.70; median: 455.00; sum: 2026710 (20.29%);
Fetches: min: 7135; max: 7168; avg: 7146.86; median: 7147.00; sum: 31646289 (0.75%);
Writes: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);
Reads: min: 0; max: 6995; avg: 3.13; median: 0.00; sum: 13856 (8.22%);
Marks: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);
From 1 unique addresses: TCPv6:::1 (4428)

4.2. 执行次数分析

4.2.1. 总项目数

Total: 4428 items

这表示在跟踪期间此特定查询模式被执行的次数。

理解此数字有助于您：

计算每次执行的资源使用情况
确定查询缓存是否有益（或者简单地降低执行频率）

高执行次数可能表明存在以下机会：

实施预准备语句（和参数化）–相同频率的相同查询，在参数化并准备重复执行时，将需要更少的资源
添加结果缓存–缓存结果值以供长时间操作甚至更长时间（用户会话期间）使用，可以减少频繁执行查询的必要性
批处理操作–考虑一次执行查询以返回或处理多条记录，这将消除执行查询的开销（准备、网络传输等）。

4.3. 持续时间指标

4.3.1. 持续时间组成部分示例

none

Durations: min: 351; max: 3919; avg: 457.70; median: 455.00; sum: 2026710 (20.29%);


指标	值	意义
最小值	351ms	最佳情况执行时间，有助于理解最佳条件
最大值	3919ms	最差情况执行时间，有助于识别潜在问题
平均值	457.70ms	典型执行时间，但可能受异常值影响
中位数	455.00ms	中间值，对于偏态分布通常比平均值更具代表性
总和（%）	2026710 (20.29%)	消耗的总时间及占整个跟踪持续时间的百分比

4.3.2. 期間分析

中央値と平均値が近い（457.70 ms 対 455.00 ms）ことは、一貫したパフォーマンスを示唆します
最大/最小比（約11倍）は、ある程度の変動性を示します
合計時間の20.29%は重要です - このクエリはFrequencyまたはPlan-Frequencyセクションのトップ3に入っていますか？（はい、入っています。）

4.4. リソース使用量メトリクス

4.4.1. フェッチ操作

none

Fetches: min: 7135; max: 7168; avg: 7146.86; median: 7147.00; sum: 31646289 (0.75%);

フェッチは行の取得を表します：

一貫したフェッチ数（最小/最大の差がわずか33）は、安定した結果セットを示唆します
比較的高いフェッチ数（実行あたり7000超）は、以下を示す可能性があります：
多くのレコードが返される場合、結果セットの制限やページネーションの必要性。
クエリ最適化の可能性 - 特に、クエリがFrequency/Plan-Frequencyのトップ3に入っている場合に有効です。

4.5. 読み取り操作

none

Reads: min: 0; max: 6995; avg: 3.13; median: 0.00; sum: 13856 (8.22%);

物理読み取りはディスクアクセスを示します：

中央値がゼロで最大値が非ゼロの場合、断続的なキャッシュミスを示唆します
全読み取りの8.22%は、中程度のI/O影響を示します
最小値（0）と最大値（6995）の大きな差は、キャッシュ効果の変動性を示唆します。

4.6. 書き込み操作

none

Writes: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);

クエリが書き込みを実行しない場合、通常は読み取り専用操作です。

4.7. マーク操作

none

Marks: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);

マーク操作はデータページのキャッシュ管理に関連します：

マークがゼロの場合、フラッシュ用にマークされたデータページがないことを示し、単純なSELECTクエリで一般的です
非ゼロのマーク操作はキャッシュと関連します

4.8. クライアント接続分析

none

From 1 unique addresses: TCPv6:::1 (4428)

これはクエリの送信元分布を示します：

単一のクライアントアドレスは、アプリケーション固有のクエリを示唆します
ローカル接続（::1はIPv6のローカルホスト）
全4428回の実行が同じ送信元から

4.9. 最適化のためのこれらのメトリクスの活用

4.9.1. パフォーマンスパターン分析

実行の一貫性

最小/最大期間を比較する
リソース使用量の外れ値を探す
変動性について中央値と平均値を確認する

リソース使用パターン

フェッチが多い → 結果セットのサイズを確認する
読み取りが多い → インデックスのカバレッジを確認する
マークが多い → ロック競合を調査する

クライアント影響分析

複数クライアント → コネクションプールのサイズ設定
単一クライアント → アプリケーションの最適化

4.9.2. 最適化の優先順位

これらのメトリクスに基づいて、以下を優先します：

結果セットサイズ
実行あたり7000フェッチ
LIMIT/OFFSETの追加を検討する
SELECTの列リストを確認する

キャッシュ戦略

頻繁な実行（4428回）
一貫した結果サイズ
書き込みなし

Code

おそらく、このクエリは実行頻度を減らすことができます。

インデックス使用

変動する読み取り数
中央値の読み取りはゼロだが最大値は高い
インデックスのカバレッジを確認する

5. 実践的応用

この具体的な例の場合：

短期的な改善：

結果キャッシュの実装（高い実行回数、一貫したフェッチ）
結果セットサイズの確認（実行あたり7000フェッチ超）

中期的な最適化：

インデックス使用パターンの分析
プリペアドステートメントの使用を検討する
実行頻度に関するアプリケーションロジックの確認

長期的な考慮事項：

時間の経過に伴う実行パターンの監視
インデックスメンテナンス戦略の計画
データアクセスパターンの変更を検討する


	これらのメトリクスは単独ではなく、まとめて分析する必要があることを忘れないでください。あるカテゴリの数値が高くても、他のメトリクスが最適であれば許容できる場合があります。トレースメトリクスのこの包括的な理解により、データベース最適化戦略のための情報に基づいた意思決定が可能になります。

これらのメトリクスは単独ではなく、まとめて分析する必要があることを忘れないでください。あるカテゴリの数値が高くても、他のメトリクスが最適であれば許容できる場合があります。トレースメトリクスのこの包括的な理解により、データベース最適化戦略のための情報に基づいた意思決定が可能になります。

6. 期間分析

期間分析では、個々のクエリの実行にかかる時間を調査します。期間を各クエリを計測するストップウォッチと考えてください - クエリにかかる時間が長いほど、パフォーマンスの問題を引き起こす可能性が高くなります。

6.1. 期間メトリクスの理解

期間メトリクスは、ユーザーエクスペリエンスに直接影響するため重要です。つまり、ユーザーが「システムが遅い」と主張します。長い列に並んで待つことに顧客がイライラするように、クエリの完了に時間がかかりすぎるとユーザーはイライラします。長時間実行されるクエリは以下を引き起こします：

画面の読み込みに時間がかかりすぎる場合のユーザーエクスペリエンスの低下
システムリソースが長時間占有される
遅いクエリの後ろで他のクエリが待機する
アプリケーションでの潜在的なタイムアウト問題

6.2. 影響カテゴリ

期間範囲	影響レベル	推奨アクション
10秒超	重大	これらのクエリは高速道路の交通事故のようなものです - 後続のすべてをブロックし、即時の対応が必要です
1〜10秒	高	黄色い信号のように、これらのクエリは早急な対応が必要な警告サインです
100ms〜1秒	中	低速走行の交通と同様に、これらのクエリは監視が必要ですが重大ではありません
100ms未満	低	これらのクエリはスムーズに流れており、非常に頻繁に発生する場合のみ対応が必要です

6.3. 分析例

none

Duration: 77,793ms
Impact: Critical - single query consuming 77.7 seconds
Root Cause: Complex aggregation in PRC_COLLECT_RANKCATEGORY
Optimization Priority: Immediate

Explanation: This query is taking over a minute to execute, which is like
a complete traffic stoppage. The stored procedure is likely processing
too much data or using inefficient algorithms.

7. 実装戦略

最適化を交通システムの改善のように考えてください - 問題を特定し、解決策を計画し、変更を慎重に実装する必要があります。

7.1. 優先順位マトリクス

このマトリクスは、都市の交通問題のトリアージのように、最初に何に注意を払う必要があるかを決定するのに役立ちます：

メトリクス	高影響	中影響	低影響
期間	交通渋滞（10秒超）	低速走行（1〜10秒）	スムーズな流れ（1秒未満）
頻度	ラッシュアワー（1000/秒超）	安定した交通（100〜1000/秒）	軽い交通（100/秒未満）
フェッチ	倉庫の移転（1000万超）	大型出荷（100万〜1000万）	小口配送（100万未満）
読み取り	市全体の検索（10万超）	近隣の検索（1万〜10万）	通りの検索（1万未満）

7.2. 段階的な最適化プロセス

重大なクエリを特定する

最大の交通渋滞（遅いクエリ）を探す
最も混雑する交差点（高頻度クエリ）を見つける
非効率なルート（高リソース使用）を特定する

実行プランを分析する

現在のルート（インデックス使用）を調査する
交通パターン（結合方法）を調べる
ボトルネック（ソート操作）を確認する

最適化を実装する

新しい道路を建設する（インデックス）
ルートを再設計する（クエリの再構築）
近道を追加する（キャッシュ）

改善を検証する

新しい交通の流れを測定する（新しいトレースレポート）
改善前後のメトリクスを比較する
効果のあった内容を文書化する

ご質問があればIBSurgeonにお問い合わせください

ご質問があれば、お気軽にお問い合わせください：[email protected]。