一般化する
ネットワークを介して転送するデータがない場合にデータを読み込み、ローカルディスク/ファイルシステムからデータを同時に読み取ってネットワーク共有に書き込むようにLinuxを設定する方法アイドル状態ですか？
同時に読み書きすることは、あるタスクを実行してから別のタスクを交互に実行するよりもはるかに高速です。
詳細
LinuxシステムのローカルディスクからNASデバイスに大量のデータを移動しています。
私は基本的にCIFSマウントにrsyncコピーしました。/srv/data/mnt/nas
最初は読み取りと書き込みが同時に可能な100MB/秒の読み取り速度と100MB/秒(ギガビットネットワークの限界)でNASに書き込む性能が良かったです。
しかし、数時間が過ぎた今、ローカルディスクから読んでいることがわかりました。その後、NASに書き込むときに読み取りを停止し、NASに書き込むデータがもうない場合は、ディスクからの読み取りを再開します。再び。ディスクの読み取り中はネットワークがアイドル状態であり、ネットワークを使用している間はディスクはアイドル状態です。
言うまでもなく、200MBを読んで200MBを書くのは、200MBを同時に読んで書くよりもはるかに時間がかかります。
読み取りと書き込みを交互にしながら一度に1つの操作を実行するのではなく、同時に読み書きする初期動作に固執するようにカーネルを設定するにはどうすればよいですか？
いくつかの観察：ローカルディスクが100 + MB /秒の速度で読み取られると、すべてが並列にうまくいくように見えますが、ディスク速度が遅くなると（何らかの理由で現在は20 MB /秒に過ぎないように見えます）、移行が発生するようです。読み書きするときに発生します。
書き込みが読み取りと並列に行われるように数秒ごとに手動で実行することもできますがsync（明らかに速度は遅くなりますが）、5秒ごとに実行されるようにsyncループを置くことは正しい解決策のようには見えません。while... 。
カーネルは約1GBのデータをキャッシュし、できるだけ早くネットワークを介して書き込むようです。大丈夫です。データの転送中に遅いディスクから読み取りを停止する理由を理解できません。ネットワーク。
ベストアンサー1
より詳細に調査した結果、この問題はカーネルとの関連性ではなく、rsyncCIFSの相互作用の方法に関連しているようです。
私が知っている限り、ターゲットrsyncファイルが閉じられると、CIFS（およびおそらくすべてのネットワークファイルシステム）は、closeシステムコールが返される前にファイルが完全にフラッシュされ、リモートディスクに書き込まれることを保証します。これは、シャットダウン操作が正常に完了したときにファイルが完全に保存され、データが失われる可能性がある追加のエラーが発生する危険性がないことをすべてのアプリケーションに提供することです。
これを行わないと、アプリケーションはファイルを閉じて保存操作が成功したと考えて終了し、（おそらくネットワークの問題によって）データが書き込まれなくなりますが、その時点でアプリケーションが遅すぎます。ユーザーにファイルを別の場所に保存するかどうかを尋ねるなどの処理を遅らせます。
この要件は、ファイルをコピーするたびに、次のファイルを読み取るrsync前にネットワーク経由でディスクバッファ全体を消去する必要があることを意味します。rsync
回避策は、この機能を無効にするオプションを使用してCIFS共有をマウントし、cache=noneすべてのI / Oがサーバーに直接移動できるようにすることです。これにより問題が解消され、読み取りと書き込みが並行して実行される可能性がありますが、このソリューションの欠点はパフォーマンスがわずかに低いことです。私の場合、ネットワーク転送速度は110 MB /秒から80 MB /秒に低下しました。
これは、大容量ファイルをコピーするときに読み取り/書き込み動作を交互に実行するとパフォーマンスが向上する可能性があることを意味します。多くの小さなファイルでは、キャッシュを無効にすると、ファイルを閉じるたびにキャッシュフラッシュの回数が減り、パフォーマンスが向上する可能性があります。
rsync最後のファイルがフラッシュされている間に次のファイルの読み取りを開始できるように、別のスレッドでファイルハンドルを閉じるオプションが必要なようです。
編集する：cache=none小さなファイルをたくさん転送する場合（10MB/秒から80MB/秒に増加）、確かに役に立ちますが、大容量ファイル（1GB以上）を転送するとき、cache=none転送速度が110MB/秒から同じ80MB/秒に低下することを確認しました。 。これは、多くの小さなファイルの遅い転送がソースディスクのルックアップに関連し、すべての小さなファイルの大容量キャッシュフラッシュに関連していることを示しています。