web-dev-qa-db-ja.com

mongodbスキーマロックの取得に費やす時間を削減するにはどうすればよいですか？

マスターと2つのスレーブで構成される3つのノードのレプリカセットを備えた、WiredTigerでサポートされたmongodb 4.0.10クラスターが本稼働しています。スレーブの1つには、同じ場所に別のサービスがあり、広範囲にスレーブを照会します。同じ場所に配置されたサービスのいくつかの速度低下に対処する際に、驚くほど低速のクエリがたくさん表示されます。これには3.3秒かかりました：

  find: "myColl",
  filter: { myField: "myValue" },
  projection: { name: 1 },
  $db: "myDb",
  $clusterTime: { clusterTime: Timestamp(1568198047, 3), signature: { hash: BinData(0, 0000000000000000000000000000000000000000), keyId: 0 } },
  lsid: { id: UUID("2ed823aa-e6af-4898-a4c1-c039d28a32ab") },
  $readPreference: { mode: "secondary" } }
  planSummary: IXSCAN { myField: 1 } keysExamined:0 docsExamined:0 cursorExhausted:1 numYields:0 nreturned:0 reslen:232
  locks:{ Global: { acquireCount: { r: 1 } },
          Database: { acquireCount: { r: 1 } },
          Collection: { acquireCount: { r: 1 } } }
  storage:{ data: { bytesRead: 355, timeReadingMicros: 4 }, timeWaitingMicros: { schemaLock: 3284692 }

ここで目立つのは最後の行で、スキーマロックと呼ばれるものを取得するために待機する時間の99.9％を費やしていることを示しています。

この特定のデータベースとコレクションをチェックしたところ、クエリ時にコレクションに50のアイテムがあり、データベース自体が小さかった（合計で1kドキュメント未満）ことがわかりました。さらに、myFieldにもインデックスがあります。

関連するかもしれないmongodbの私たちの特定の使用法に関する他のいくつかのデータは次のとおりです：

  • 顧客ごとにデータベースを持つことによるマルチテナンシー
  • ほとんどのドキュメントは小さい
  • ほとんどのドキュメントは、ライフサイクル全体を通じて同じサイズになります（サイズが大きくなるにつれて、パディングやドキュメントの移動に関連するパフォーマンスの問題があった他のドキュメントをここで読みました）。
  • 顧客データは、ドキュメントのサイズではなく、ドキュメントの数によって増加します

私はしばらくの間、これらの遅いクエリを監視してきましたが、パターンを確認できません。これは、mongodbが頻繁にメンテナンスタスクを実行しているときに、その時点で実行されているクエリを強制的に待機させているようなものです。

読み取りクエリがスキーマロックの取得を待機しているのはなぜですか？この長い待ち時間をなくすにはどうすればよいですか？

mongodblockingmongodb-4.0
4
expez

これは、WiredTigerストレージエンジンの一般的なアーキテクチャ上の問題です。現在ここで議論されています： https://jira.mongodb.org/browse/WT-5479

要するに、開いているファイルの数が多すぎます。可能であれば、不要なインデックスを削除することを検討してください。小さなコレクションのインデックス。 MongoDB 4.2で導入された新しいワイルドカードインデックスを探索することもできます。

1
Ralf Strobel