これまでこのようなことは見たことも聞いたこともありませんし、オンラインでも似たようなものを見つけることができません。
ネットワークをギガビットにアップグレードし、最近は大容量のファイルを転送しています (今回の問題は、合計 200 GB を超える DVD イメージの束です)。数 GB 以上のファイル セットをコピーしようとすると、Mint がデータ チャンク (通常は約 1.2 GB 以下、場合によっては数百 MB) を RAM にロードしてから転送を開始するという奇妙な動作に気付きました。その転送が完了すると、Mint は文字通り転送を停止し、古いデータ チャンクを吐き出し、次のデータ チャンクが RAM にロードされるまで転送を続行するのを待ちます。その後、ネットワーク経由で転送を再開します。そして、それが繰り返されます。そして、繰り返します。そして、データがすべて完了するまで繰り返されます。
これは、このような奇妙な瞬間の 1 つにおけるシステム モニターのスクリーンショットです。
RAM がデータをダンプした瞬間に転送が停止し、転送が再開した瞬間に RAM が平準化していることがわかります。また、システム モニターが示すように 3.2 GB ではなく、実際には 6 GB の RAM が搭載されていることも面白いところです。Mint が突然これを報告しなくなったのは、今回で 2 回目です。しかし、これは別の日に質問しましょう。
これは世界最悪の事態ではありませんが、私がこれまで使用した他のすべての OS が、ネットワークを介してデータを転送しているときに同時に RAM にデータをロードしたり RAM からデータをロードしたりするのは少し面倒です。それについて考えるために一時停止する必要はありません。これを解決できれば、大量のデータを移動するときに時間を節約できます。
何か提案、治療法、診断、理論はありますか?
答え1
Marco のコメントに触発されて、思いつかなかったことをいくつか試してみたところ、答えが見つかりました。つまり、代替案を見つけたということです。これについて詳しい方がいらっしゃいましたら、ぜひ回答を追加してください。
ファイルの転送方法を事前に指定しておくべきでした。これは、当然ながら、Synology NAS への WebDAV 接続を介してネットワーク経由で実行されました。
Marco のコメントを受けて、いくつかの異なる方法を使用して約 11.7 GB を NAS にコピーすることをテストしました。
Samba: 平均速度が大幅に速くなっただけでなく、データの読み込みを待つ問題も発生しませんでした。
FTP: 平均速度は速くなり、データが RAM にロードされるのを待つために転送が停止することはありませんでしたが、CPU が少しおかしくなることがありました... つまり、コアの 1 つが最大限に使用され、転送をキャンセルした後も CPU を消費し続けるため、FTP プロセスを強制終了する必要がありました。
WebDAV: 以前と同じです。RAM が大量のデータを取得し、データを転送し、その後 RAM がそれをダンプしてさらにデータを取得し、転送する、などです。
そこで、この場合は Samba のほうがよい方法だということが分かりました。少し Google で検索してみたところ、WebDAV は特に LAN では扱いにくいプロトコルだと感じる人もいることがわかりました。
それでも、これが WebDAV の仕様なのか、他の人にも同じ問題があるのか、それとも Mint に問題があるのか、それとも私の Mint の特定の設定だけの問題なのかはわかりません。そのため、これをベスト アンサーとして選択する前に、他の人がもっと良い解決策を持っているか、私が追加できない追加事項があるかどうか確認するために、数日間待ってみようと思います。