最近になって奇妙な問題が発生し始めたようです。
大きなファイル (約 6 GB) をラップトップから古いファイル サーバーの 1 つにコピーすると、数秒後にサーバーのメモリが不足します。
これは最近になって始まったもので、おそらくパッチ火曜日以降だと思いますが、確証はありません。
このサーバーは Windows 2000 sp4 マシンで、1GB の RAM (注: このサーバーには 1GB 以上あったはずですが、電源を切ることができる日の終わりまで物理的に確認できません)、3GHz Xeon プロセッサ、RAID 10 の 4 x 250Gb 7.5k RPM SATA ドライブ、および Intel 管理スイッチの 1GB ポートに接続された 1 ギガビット NIC を搭載した Dell 2950 です。
(どうやら画像を投稿できないのでリンクで済ませるしかないようです)
コピーを停止するとすぐにメモリが解放されます。
ウイルス対策ソフトを削除しましたが、影響はありませんでした。「Microsoft ネットワーク用ファイルとプリンタの共有」オプションをバランスに変更しました。
当社には、Windows 2000 SP4、2GB RAM、2.8Ghz Intel Quad Core、6 x 300Gb 15k SAS (RAID 10) を搭載した別のサーバーがあります。
同じ 6GB のファイルをここにコピーしても、使用可能なメモリの量は変わりません。
サーバーの実行中に確認できるものは他に何かありますか? サーバーは使用中であり、小さなファイルのコピーによる影響はほとんどないため、まだ再起動できません。
以下は、サーバーのメモリが不足したときに開いていたいくつかの perfmon カウンターのスクリーン ショットです。
ありがとう
、ガレス
答え1
私も同じ問題に直面しています。
Windows Server 2008 を実行している 64 ビット サーバーに P2V 変換を実行しようとしています。VMDK ファイル (44 GB) の通常のファイル転送方法を使用すると、ファイル システム キャッシュにより、宛先サーバーの Windows の 14 GB RAM が数分後に不足します。
32 ビット サーバーで P2V 変換またはファイル コピーを実行すると、この問題は発生せず、メモリ使用量は適切なままになります。
次に、VMDK ファイルを宛先 VMWare サーバーにコピーしようとすると、同じ問題が発生します。
このページには私が見ているものが正確に説明されています:
http://blogs.technet.com/askperf/archive/2007/05/08/slow-large-file-copy-issues.aspx
私の作業に基づくと、この AM ESEUtil が最適な方法のようです。予想していたほど高速ではありませんでしたが、Windows に異常が発生することもありませんでした。
Windows FTP クライアントは、ファイルをターゲットの宛先に移動する前に、C:\ 上の Temp ファイルを使用します。注意してください! :-)
これはとてもイライラする。
答え2
ちょっと面倒なのは分かっていますが、サードパーティのファイル コピー ユーティリティを試しましたか? Windows は、ファイルのコピーが時々鈍かったり、遅くなったりする傾向があります。Lifehacker では、こうしたユーティリティのトップ 5 リストを作成しました。そのうちの 1 つを試してみて、同じ問題がまだ発生するかどうかを確認してください。
http://lifehacker.com/5280976/five-best-alternative-file-copiers
また、towo さんが言ったように、仮想メモリの設定を確認してください。ベストプラクティスは、ページファイルをメモリの 1.5 倍にすることです (つまり、1 GB のメモリ = 1024 MB、1024*1.5 = 1536 MB のページファイル)
答え3
W2K のネットワーク ファイル コピー プロセスには既知の問題があります。リモート システムが、ネットワーク経由でファイル データが到着する速度よりも速く書き込みキャッシュを空にできない場合、ファイルが十分に大きいと、サーバー上のすべての物理メモリが着実に消費されます。Mark Russinovich は、この問題が発生する可能性がある理由について詳細に説明しています。記事上でWindows Vista のファイル コピー メカニズムの変更によるものです。投稿されたパフォーマンス グラフはこの問題のように見えますが、非常に遅いディスクと高速ネットワークを備えたターゲット システムで、まさにこのような動作を過去に見たことがあります。
ただし、ターゲット OS が少し古いとしても、ハードウェアはそれほど弱いわけではなく、4x7.2K SATA ドライブを使用した RAID 10 セットアップでは、書き込み速度が 60 ～ 120Meg/秒程度になるはずです。これは、Vista がコピーに対して報告している 39Meg/秒よりも大幅に高速です。ここで奇妙なのは、堅牢で適切に構成された GigE リンクであれば、このような大きなファイルの継続的なコピーで、ネットワーク転送速度が 70Meg/秒 (またはもう少し高い) に達する可能性があることです。とはいえ、クライアントまたはサーバーのいずれかに出入りする他のトラフィックがある場合、または (より可能性が高いですが) その速度が主にローカル ラップトップのハード ドライブの速度によって制限される場合、38Meg/秒は異常ではありません。
いずれにせよ、RAID 10 が実際に正常であるかどうかを確認します。ここでの症状から、RAID 10 が本来の速度で書き込みできなかったのではないかと疑われます。
答え4
おそらく、システム ハード ドライブの仮想メモリを増強する必要があります。ハード ドライブの空き容量が少ないことが、この問題の原因となっている可能性があります。
また、論理的な観点から見ると、ファイル システムからファイル システムへコピーするときに、サーバーは実際にファイルをメモリに保存する必要はなく、ファイルが通過するメモリにバッファを割り当てるだけです。ただし、ファイルのコピー方法によっては、一部のアプリケーションは最初にファイルを完全にメモリに保存してから、ディスクに書き込みます。
FTP などのプロトコルを使用してみてください。それでも問題が解決しない場合は、ネットワークの問題を調べてみる必要があるかもしれません。
ここでの興味深い疑問は、サーバーが実際にファイルをどのように保存するかということです。ご覧のとおり、I/O 負荷は大幅に低下しており、これは、実際にはファイルをどこかに書き込んでいるのではなく、メモリにバッファリングしているだけであることを意味します。