ステップ1：リソースの利用状況を確認する

1. IBM Cloud コンソールにログインし、 MongoDB 配置に移動します。

2. モニタリングのセクションを見直す：

   • CPU 使用率
   • メモリー使用率
   • ディスクのIOPSとレイテンシー
   • アクティブ接続数

ステップ2：遅いクエリを特定する

遅いクエリは、パフォーマンス低下の最も一般的な原因の1つです。

1. プロファイリングを有効にする：

   db.setProfilingLevel(1, { slowms: 100 })
   

2. 最近の低調なオペレーションを見直す：

   db.system.profile.find().sort({ ts: -1 }).limit(20)
   

3. クエリの実行を分析する：

   db.collection.find({ ... }).explain("executionStats")
   

ステップ3：接続の使用状況を確認する

接続数が多かったり、管理が不十分だったりすると、パフォーマンスに影響を与える可能性がある。

db.serverStatus().connections

ステップ4：レプリケーションの健全性をチェックする

レプリケーションの遅延は、読み取りパフォーマンスとデータの鮮度に影響を与える可能性がある。

rs.printSecondaryReplicationInfo()

ステップ5：シャーデッド・クラスタの検討（該当する場合）

シャーディングが必要になるのは、次のような場合だ：

• 作業セットがRAMより大きい
• シングルノードのIOPSはスケーリング後も最大値
• 水平書き込みスケーリングが必要
• コレクションは1-2 TBを超える

詳しくは、 パフォーマンス・チューニングと シャーディングを 参照のこと。

デプロイメントがシャーディングを使用している場合は、実行してください：

sh.status()

ステップ6：大容量データ削除後

かなりの割合のデータを削除しても、オペレーティングシステムレベルのディスク使用量はすぐには減らない。

ステップ7：ロックの競合をチェックする

ロックの競合は、同時処理と全体のスループットに深刻な影響を与える可能性がある。

• グローバルロックの統計情報を確認する：

  db.serverStatus().locks
  

• ロックのために現在のオペレーションをチェックする：

  db.currentOp({
    $or: [
      { waitingForLock: true },
      { "locks.Global": "w" }
    ]
  })
  

• ロックの待ち時間を分析する：

  db.serverStatus().globalLock
  

ステップ8：作業負荷パターンの分析

ワークロードのパターンを理解することは、最適化の機会を特定するのに役立ちます。

• 動作カウンターをチェックする：

  db.serverStatus().opcounters
  

• 時系列でオペレーションを分析する：

  db.serverStatus().opcountersRepl
  

• ホットなコレクションを特定する：

  db.adminCommand({ top: 1 })
  

• 読み取り比率と書き込み比率を比較する：

  var stats = db.serverStatus().opcounters;
  print("Read ratio: " + (stats.query + stats.getmore) / (stats.query + stats.getmore + stats.insert + stats.update + stats.delete));
  

ステップ9: メモリの圧迫とキャッシュ効率の調査

MongoDB's WiredTiger ストレージエンジンはキャッシュ効率に大きく依存している。

• WiredTiger キャッシュ統計情報を確認する：

  db.serverStatus().wiredTiger.cache
  

• 主要指標を見直す：

  var cache = db.serverStatus().wiredTiger.cache;
  print("Cache size: " + cache["bytes currently in the cache"]);
  print("Max cache size: " + cache["maximum bytes configured"]);
  print("Pages read into cache: " + cache["pages read into cache"]);
  print("Pages written from cache: " + cache["pages written from cache"]);
  print("Cache hit ratio: " + (1 - cache["pages read into cache"] / (cache["pages read into cache"] + cache["pages requested from the cache"])));
  

• 立ち退き圧力をチェックする：

  db.serverStatus().wiredTiger.cache["pages evicted by application threads"]
  

db.serverStatus().wiredTiger.cache["tracked dirty bytes in the cache"]

ステップ10：書き込みに関する設定と読み出しに関する設定を見直す

書き込みの懸念と読み込みの優先設定は、パフォーマンスと一貫性に大きく影響する。

• 現在の書き込みの懸念を確認する：

  db.getWriteConcern()
  

• レプリカセットの設定を確認する：

  rs.conf()
  

• 懸念事項を書き込む：

  懸念事項の書き込みオプション

  懸念事項を書く	耐久性	パフォーマンス	ユース・ケース
  w: 1	低	高	重要でないデータ、高いスループット
  w: "majority"	高	中	デフォルト、バランスの取れたアプローチ
  w: <number>	ミディアム-ハイ	ミディアム-ロー	特定のレプリカ数
  j: true	最高	最低	ジャーナル同期が必要な重要データ

• プリファレンスのオプションを読む：

  プリファレンス・オプションを読む

  プリファレンスを読む	整合性	パフォーマンス	ユース・ケース
  primary	最高	中	デフォルト、強い一貫性
  primaryPreferred	高	ミディアム-ハイ	セカンダリーへのフォールバック
  secondary	結果	高	分析、レポート
  secondaryPreferred	結果	高	スケーリングを読む
  nearest	結果	最高	最低のレイテンシー

• お申し込みの際、read preferenceにチェックを入れてください：

  // Example in Node.js driver
  db.collection('users').find({}).readPreference('secondary')
  

ステップ11：バックアップとメンテナンスの影響を監視する

バックアップ作業やメンテナンス作業は、一時的にパフォーマンスに影響を与える可能性があります。

db.currentOp({
  $or: [
    { op: "command", "command.backup": { $exists: true } },
    { desc: /^conn/ }
  ]
})