WiredTigerを使用してMongoDB 3.4のファイル（事前）割り当てステップ（最大増加値）に影響を与える方法
私たちは環境にいくつかの本当に小さなDB（5GB）をDBごとのディレクトリとしてデプロイしました。dirsの下にはXFSを備えたLVMがあり、DBスペースをいっぱいにする必要があるときに「ブレーキ」のロジックを実装しました（すべてがいくつかの厳密なディスククォータによるものです） -まったく面白くないと思います...）。私たちのソリューションは、CentOS 7.5上のMongoDB v3.4.19で実行されます。すべて問題ないようです。
一部のDBは、単一のコレクションで60％以上のディスク領域を使用しており、このシナリオでは、2.3GBのダンプ（すべて5GBのデータベースdir/= diskに復元中）に遭遇しました。 ）2の累乗の戦略（または非常によく似たもの）。
この状況はトリガーに当たり、最終的にはDBのロックにつながるはずです（スペースが残っていないため、クラスター全体が落ちるよりもなお良いでしょう）。基本的には、10GB DBと同じ状況です。 （そして、ある意味で、文字通りあらゆる能力で同様の状況が発生する可能性があると言える...）
私の質問のポイントは次のとおりです。復元（のみ）するために、またはすべてのために、Mongo/WTの（事前）割り当ての増加のステップ（最大サイズが〜2GB未満）に影響を与えることができますか？
（この場合、パフォーマンスへの影響は最優先されません。）
ストレージエンジンのdb.adminCommandおよびconfigStringsを通じていくつかの有望な可能性を見つけましたが、影響を与えたりリストしたりできませんでしたいくつかの可能なパラメータも、物事を良いものにするために何かを変更する...特にfile_extendパラメータWT through
db.adminCommand( { setParameter: '1', wiredTigerEngineRuntimeConfig: { <parameter> } } )
有望に見えましたが、クラスターに渡す方法が見つかりませんでした...一部の試行はエラー22-無効な引数で終了しましたが、詳細については見つけることができませんでした...
もう1つは、MMAPエンジンのみに適しているようです-newCollectionsUsePowerOf2Sizes = false。
これにより、ダンプ（最終的にはバックアップ）をクラスターに復元するのがさらに面倒になります...
その問題が明確に説明されていて、ヒントやヒントをいただければ幸いです...追加の情報が必要な場合はお知らせください。
更新：
スクリーンショットを撮りましたが、私が上で話している内容がはっきりと表示されていると思います... $ ls出力（左上）、$ df出力（右上）、$ mongorestoreの進行状況（左下）。 （聞く（読む）の千回よりも一度見る方が良い...）
初め 
最初の割り当て（1.4GBに-650MB使用） 
2番目の割り当て（2.4GBへ-1.1GB使用） 
3番目の割り当て（4.4GBへ-2.1GB使用） 
復元終了時（まだ割り当てられている4.4GB-使用済み2.3GB） 
通常に戻る（余分なスペースの割り当て解除） 
ありがとうございました。
ズデネク
WiredTigerはデータファイルを事前に割り当てません。ジャーナルファイルのみが事前に割り当てられます（事前割り当てごとに100MB）。 ジャーナルプロセス を参照してください。
表示されているディスクの枯渇は、おそらくこれらのジャーナルファイルが原因です。ジャーナルファイルは迅速な書き込み用に最適化されており、その内容は WiredTigerチェックポイント でより永続的な方法で永続化され、約60秒ごとに発生します。通常、データファイルに永続化すると、ジャーナルファイルを削除できるようになるため、使用されるディスクが少なくなるはずです。ジャーナルファイルは、チェックポイントの後でのみWiredTigerによって削除され、それ以外の場合は削除されないことに注意してください。
この復元/データロードプロセス中に一時的に余分なスペースを確保することをお勧めします。データベースが定常状態になると、より正確なサイズが表示されます。
2の累乗の事前割り当ては、非推奨のMMAPv1ストレージエンジンに固有です。これはWiredTigerには関係ありません。
Mongo/WTの（事前）割り当ての増加のステップ（最大サイズが〜2GB未満）に影響を与えることができますか？
Googleグループフォーラム こちら に従って、各データファイルは2GBを超えることはありません。署名された32bitintを使用して各ファイル内のインデックスを作成するため、2^31バイトを超えるバイトは使用できません。 16000ごとにdb [1]ファイルのソフト制限があり、プロセスごとに1つのDBで32TBに制限されます。これは主に健全性チェックとして使用されるだけなので、その数を簡単に変更し、再コンパイルしてその制限を引き上げることができます。とはいえ、現在の48bitのx86_64 cpus仮想アドレス空間制限にすぐに遭遇します。ユーザー空間で使用できるのは47ビットのみで、128 TB未満のハード制限になります。また、耐久性を使用する予定がある場合は、すべてのファイルをダブルマップするので、64TBに制限されます。
ファイルシステム内の単一のファイルを意味します。 MongoDBのデータベースは複数のファイルにまたがっているため、データセットのサイズに制限はありません。はい、これは64-bit OSsにも適用されます。すべてのプラットフォームで同じデータファイル形式を使用しているため、ファイルを自由に移動できます。
32-bitオフセットは、主にスペースの最適化です。これにより、32ビットのファイル番号とそのファイルへの64-bit DiskLocオフセットで32-bit stuctを使用して、単一のデータベース内の任意の場所を指すことができます。これは、mongoがpointersをディスクに保存するときに内部的に使用するものです。