0
oplogreplayにnumInsertionWorkersPerCollection> 1のmongorestoreを使用すると、パフォーマンスが改善されません.64 GB RAMの私の完全なoplogサイズは約1 GBです（同じコレクションで約100万回のリクエスト）。だから私はここではハードウェアが限界だとは思わない。親切にも、その背後にある理由を教えてください。- numInsertionWorkersPerCollectionを使用したoplogreplayでのmongorestoreの使用oplog再生にmongorestoreを同時に使用する
基本的には、mongorestoreとsync（セカンダリでoplogを更新するために使用される）とを比較していました。同期の場合、私たちはoplogを同時に適用できるデフォルトの16人の作業者を持っています。私はmongorestoreと同じことをやりたいと思っていました。
情報ありがとう！ @JJussi :)。しかし、どのようにして、同期の間に、モンゴストアの再生と比較して、速い再生が非常に速く起こることを説明しますか？ –
私の主張を支持するために、私は次の実験を行った。レプリカセットからセカンダリを切り離し、次にプライマリで約1Mの操作を実行しました。今、レプリカセットなしで（つまり、--replSet setNameなしで）セカンダリを実行し、mongorestore oplog再生を使用してそれにoplogを適用します。それは約4分かかりました。同じ実験を繰り返しましたが、セカンダリをプライマリ（つまり、--replSet setName）でもう一度接続すると、約1分かかりました。このような大きな違いの背景には何がありますか？ –
異なるコード。別のプログラマー。私はopLogの再生に関するmongodコードをチェックしていませんが、そこには今日パラレルになることができます。 wiredTigerエンジンの時間の前に、mongodも非常に単一のスレッドでした。 – JJussi