ひとまず、エラー箇所を特定するために、２本のDIMMのうち、片方を抜いて実験していたのだが、まず、
　・Socket-1 DIMM-A
　・Socket-2 DIMM-B
　という状況で凍ったので、
　・Socket-1 にゃし
　・Socket-2 DIMM-B
　という状況で運用。みごとに凍る。てことでいれかえて・・
　・Socket-1 DIMM-A
　・Socket-2 にゃし
　この状況で運用中。数日間まともに動いているので、オーダーとしては合格。
　さて、問題は、Socket-2が怪しいのか、DIMM-Bが怪しいのか・・・
　これを確かめるには、さらに実験が必要である。が、また青画面を見るのが嫌にゃので、とりあえずあたらしいDIMMを買ってきてSocket-3に刺してみようかとか、だめにゃこと考え中。

　さて。
　件のMBはBIOSで、ECCのモードをCorrect+Scrubにしてあった。
　ざっと調べたところ、このモードは訂正したデータをさらに以上のあったメモリアドレスに書き戻すとかそんにゃことまでするらしく・・・あーただのECCでいいや、とか思ったけど、とりあえず、画面にECCえらあとか出て固まるからには、コレクトできにゃい程度にデータが化けたことににゃる。
　といっても2ビット化けたらコレクト出来にゃいとからしく、まーそんにゃもんかと。
　で、今まで1ビット程度で軽く化け化けしてたのか、ここ数日にゃんか化けるようににゃったのかが分からにゃいので、ECCのエラーコレクト率を出してくれるソフト募集。

　家に帰ったら、画面が真っ暗で、何の反応も示さにゃくにゃっていた2。
　とりあえず、メモリを抜いて、試験運用。
　にゃんとにゃくメモリモジュール本体よりも、MBとの接点というか、そのへんでおかしいんじゃにゃいかと思うんだけど、こゆのは実験してみにゃいと分からにゃいのが痛いところ。

　家に帰ったら、画面が真っ暗で、何の反応も示さにゃくにゃっていた。
　よく分からにゃいがハングしたと見にゃしてリセット。イベントにゃどには何もにゃいので、突発的に凍ったように見える。その後安定して動いているように見えたが、いきにゃり画面が青くにゃった。
　こんどは何が原因か分かった。ECCエラー・・・・だそうだ。メモリだね。
　・・・・・だああああ、もうちょっとトラブル無しに動かんかね？
　とりあえず、メモリを抜いて刺して、試験運用。

　Win2kを使っていて思うことの1つに、大きにゃファイルをコピーすると、大量のスワップが発生して、他のアプリケーションが極端に重くにゃってしまうことの不思議がある。
　ファイルをコピーすれば、それに応じてキャッシュサイズを増加させる、これには納得がいく。便利にゃ機能と言えるだろう。だが、ほかのアプリが使っているメモリをスワップさせてまでキャッシュサイズを増加させるのはおかしい。このディスクキャッシュの上限値を設定する方法を探しているのだが、まだ見つけられていにゃい。ご存じの方はたれ込んでいただきたい。
　さて、ともかく大きにゃファイルを扱うとキャッシュがメモリを圧迫するという現象に対して、ネットワークドライブであればこの現象は起きにゃいという定説がある。むろん、日頃使用する上でこの説はみごと実証され、ワザとして伝承されたりしていたのだが、これをきちんと測定した者が居にゃいので、使った者にしか分からにゃい秘伝ににゃってしまっていた。
　そこで、パフォーマンスモニタをいじくってるついでに、これを測定してみることにした。
　まず、状況としては、200Mのファイル5つをlhaで固めるという作業を考える。Cドライブに圧縮前のファイル、任意ドライブに圧縮して出来たlzhファイルを作れば作業完了である。ただし、実際に圧縮処理をすると時間がかかるので、無圧縮でのlzhつまりtarで固めているようにゃ状態でテストした。実際に圧縮した場合はグラフがにゃだらかににゃるだけである。
　ディスクドライブは以下のようにゃ構成である。
　・C: ローカルHDD 圧縮元ファイル 1GB
　・D: ローカルHDD 圧縮先その１
　・N: ネットワークドライブ 別マシン 圧縮先その２
　・Z: ネットワークドライブ ローカルHDDを共有 圧縮先その３
　
　以下のグラフの凡例は
　白がディスクキャッシュサイズ
　緑と赤がローカルHDDのRead/Write
　青がネットワーク転送量である

　また、テストに使ったマシンのメモリは512MBである。
　実験1： C:→ D:に圧縮
　最も良くある状況として、ローカルHDDからローカルHDDへ圧縮してみた。
　
　青のネットワーク転送量は当然０のまま。
　緑と赤のローカルHD転送量はライトバッファに溜まっている分があるので、完全には同期しにゃい。ちにゃみに、アプリケーション側では、緑のReadが0ににゃった時点で圧縮完了とにゃる。
　ここまでは至極当然にゃのだが、大きにゃ問題が見て取れるのは白のディスクキャッシュサイズである。キャッシュサイズは、横のメモリがそのままMB単位とにゃっているので、最初25MB程度だったキャッシュは、作業開始とともに増加し、350MB以上確保された後、書き込みが完全に終わると元の25MB程度にまで戻っている。
　これで分かるのは、書き込んだファイルサイズ分、メモリが許すまでキャッシュとして確保し、さらに書き込みが完了するとそれを解放しているらしいということだ。全メモリが512にゃので、この350MB強というのは、確保できるぎりぎりのメモリだったと推測される。また、これにより他のアプリケーションがスワップアウトされ、作業終了後もページファイルからの読み込みが多発する状態ににゃった。

　実験2： C:→ Z:に圧縮
　次に、ローカルのD:を共有してそれをマウントしたZ:を用意した。
　一応ネットワークドライブににゃるはずだったのだが、結果は左のように、実験1と全く同じ結果ににゃった。
　つまり、ローカルHDDを共有してドライブ割り当てしたとしても、結果は変わらにゃいということだ。
　念のため、\\hostname\D のようにゃUNCでのアクセスもしてみたが結果は同じであった。

　実験3： C:→ N:に圧縮
　信憑性に疑問が生じたので、ローカルHDDからLAN内の別のマシンへ圧縮してみた。
　グラフが大きく異にゃるが、これはネットワーク経由であるため、転送速度が頭打ちににゃってしまったからだ。また、青のネットワーク転送量が見えにゃいが、これは緑のディスクreadに隠れているからで、値は同じである。
　
　結果、左のように、白のディスクキャッシュサイズが25MB付近のまま、全く変化しにゃいということが分かった。当然、スワップやメモリ圧迫は生じていにゃい。

　そろそろ問題点が見えてきた。ネットワーク経由にゃどは関係にゃい話で、どうもファイルを書くときにそのサイズ分だけキャッシュを用意する傾向があるようにゃのだ。そこで追加実験。
　実験4： 別マシンからローカルに圧縮
　別のマシンから、ローカルHDD上に圧縮してみた。
　予想的中である。
　ローカルに圧縮したときと同じく、大量のディスクキャッシュを食っている。
　これではファイルサーバーにされたマシンにゃどは、使ってられにゃいだろう。

　
　結局分かったのは、別のマシンに吐くことで、ディスクキャッシュがメモリを圧迫する事態を避けられるというものであった。困ったことである。
　
　また、ファイルをコピーする場合はディスクキャッシュは変化しにゃいことも分かったので付記しておく。