Content last updated 2026-03-26

DB のパフォーマンス問題の調査

このガイドでは、エンジニアリングチームと連携して DB のパフォーマンス問題を調査する手順を説明します。

使用するタイミング

このワークフローは、お客様から データベース起因 に見えるパフォーマンスの症状が報告された場合に使用します。例えば:

ページの読み込み、API 呼び出し、または db_duration_s / db_count の高い Sidekiq ジョブが遅い
ロック競合、ブロックされたクエリ、または高いデータベース CPU / I/O
バックグラウンドマイグレーションやメンテナンスタスクが遅い
トレースでデータベースのボトルネックが見られる繰り返しのタイムアウト

ワークフロー

1. 初期トリアージとスコープ設定

何が遅いか と 誰にとって遅いか を明確にします:
- 特定のエンドポイント、アクション、ワークフロー（例: MR の読み込み、パイプラインビュー、API 呼び出し）
- スコープと影響範囲（例: ユーザー / プロジェクト / インスタンス全体）
チケットに 環境の詳細 を記録します:
- GitLab のバージョン、デプロイの種類（Omnibus / Helm / Dedicated）、リファレンスアーキテクチャのサイズ
- データベースエンジン／バージョン、ホスティング（VM、マネージド DB、ベアメタル）、HA／レプリカ構成
DB 関連 である可能性が高いことを確認します:
- DB の時間が長い、db_count が高い、ロック待ち、明らかな遅いクエリを示すメトリクスやログ
DB の所要時間が長い Sidekiq イベントを特定するための JQ クエリの例:

cat current | jq -Rr 'fromjson? | select(.db_primary_duration_s != null and .db_primary_duration_s > 30) | [(.duration_s * 1000 | round / 1000), (.redis_duration_s * 1000 | round / 1000), (.db_primary_duration_s * 1000 | round / 1000), (.cpu_s * 1000 | round / 1000), ."meta.feature_category", .queue, .class, .correlation_id] | @tsv'

2. 具体的な証拠の収集

問題を一意に特徴付けるのに十分な情報を集めます:

最小限の再現可能な記述（可能な場合）
代表的な例:
- 遅い操作のリクエスト ID、ジョブ ID、トレース
- サンプルの遅いクエリやクエリのフィンガープリント
タイムラインと変更:
- 問題が始まった時期、最近のアップグレード、設定変更、トラフィックスパイク
主要なメトリクス／スクリーンショット:
- DB の CPU、I/O、接続数、ロック、遅いクエリのチャート
  - 最大データベース接続数の計算には GitLab PostgreSQL Connection Calculator を使用できます。

これらは後で Issue やエピックで使用できるよう、チケットからリンクして残しておきます。

3. 既存の調査との相互参照

GitLab.com / Dedicated のログを類似パターンで検索する（アクセス権がある場合、または Infra 経由で）:
- 同じワーカー名やエンドポイント
- 同じクエリシグネチャやエラーテキスト
- 類似する症状パターン: タイムアウト、N+1 のような挙動、メモリスパイクなど
- Elastic 検索の例: https://log.gprd.gitlab.net/app/r/s/0Bvmn
GitLab Issue を検索 (gitlab-org/gitlab および関連グループ):
- 検索条件:
  - ワーカー名やサービス名（例: 特定のバックグラウンドジョブ）
  - エンドポイント名や機能名
  - クエリパターンやエラー文字列
- 関連するラベルでフィルタリングします。例:
  - performance, infradev, SLO::Missed, GitLab Dedicated, bug::availability
- 関連する明らかなパフォーマンスエピック（影響を受けるエリア向け）を確認します。
インフラ／Dedicated のトラッカーを確認:
- 類似する以下を持つ GitLab.com / Dedicated インシデントを探します:
  - 症状（タイムアウト、高い DB 負荷、ロック競合）
  - エラーメッセージやクエリパターン
  - ワーカー／機能
必要に応じてオーナーである開発グループに相談:
- 単独で調査することを避けるため RFC プロセスを利用します。
- 一致しそうだが確信が持てない場合、関連グループを既存の Issue で @ メンションし、お客様の証拠を簡潔に要約します。

4. 判断: 既存 Issue か新規 Issue か

4.1 良い一致を見つけた場合

お客様の症状と一致する既存の GitLab Issue がある場合:

チケットを Issue にリンク します:
- GitLab Issue に以下を含む短いコメントを追加します:
  - デプロイの種類、GitLab のバージョン
  - インスタンスのサイズ／注目すべき設定
  - 大まかな影響（例: “Ultimate, ~10k active users, many MRs per day”）
お客様関連のラベルが付与されていることを確認:
- 適切な場所に customer および関連するデプロイ種別／パフォーマンスラベル
試したこと、または既知の 任意の緩和策（.com / Dedicated またはドキュメントから）と、その効果について記録します。

4.2 一致が見つからない場合

.com または Dedicated に類似パターンが 存在する 場合:
- gitlab-org/gitlab（または適切なプロジェクト）に 新規 Issue を作成 し、以下を含めます:
  - 問題の要約
  - 双方からの証拠:
    - お客様の環境
    - GitLab.com / Dedicated のログ
- 以下のようなラベルを追加します:
  - customer, performance, infradev, デプロイ種別ラベル
- オーナーグループにタグを付け、関連するエピックがあればリンクします。
- お客様のチケットをこの新規 Issue にリンクします。
.com / Dedicated に類似パターンが 見られない 場合:
- セルフマネージド固有の可能性 として扱います:
  - 設定、スケーリング、または環境固有の挙動
- 問題が 重要かつ再現可能 な場合、依然として以下を含む GitLab Issue を作成 します:
  - 明確な再現手順
  - お客様への影響
  - 仮説（例: スキーマ、インデックス、設定、ワークロード特性）

5. データベースの調査を主導する

クロスリファレンス作業と並行して、技術的な調査を主導し続けます:

既存の Database Help / DB Support Pod ワークフローを以下に使用します:
- クエリ分析と遅いクエリの特定
- インデックス／スキーマのレビューおよびバックグラウンドマイグレーションの確認
- ロック／ブロック分析と接続飽和
以下の場合は Database Engineering / DBO を巻き込みます:
- 問題が体系的、または変更がリスキーに見える場合
- スキーマ、パーティショニング、バックグラウンドマイグレーションについてより深いガイダンスが必要な場合

調査結果はチケットに、関連する場合はリンクされた GitLab Issue にも記録します。

6. フィードバックループを閉じる

デプロイ間で作業を再利用可能にするために:

新しい情報が現れたら（お客様や Infra から）:
- リンクされた GitLab Issue にコメントとして追加します。
修正または緩和策 がマージされたら:
- 以下を記録します:
  - 修正を含むバージョン
  - バックポートやフィーチャーフラグの要否
- お客様が修正を適用し検証できるようサポートします。
検証後:
- GitLab Issue に以下をコメントします:
  - お客様の確認と前後のメトリクス
  - 同じ修正を他のデプロイ種別にも事前に検討すべきかどうか。