宮脇です。
天野さん、早速のレス、ありがとうございます。
> これはカーネル絡みの深い問題のようで、
> 要するに、ハードウエアのために最適化されていない事のようです。
> おそらく、CPUも、いっぱいいっぱいで回ってますよね?
> 違うリリースを使うのが一番手っ取り早いと思います
> (つまり、リコンフィグでは解消できない)。
> 苦肉の策としては、ファイルシステムの最適化でしょうか。
> それと、ddのパラメータを変えるとか...。
私もハードウエアの問題を考えていたため、ディスクパラメータなどを貼り付けまし
たが、半信半疑です。というのも、
(1) ddコマンドだけで非圧縮でコピーすると、まったく問題なく、コピーしてくれま
す。
(2) 確かに、CPUも、いっぱいいっぱいで回っていて、応答も遅れ気味になっていま
す。でも、ＨＤＤはあくびしていると思います。最後の320ブロック（２０ＭＢ弱）
のコピーには３４１秒もかかっていて、ＨＤＤアクセスランプも、たまに、思い出し
たようにつくだけです。
> #しかもこれ、マシンの種類が違うと
> #全然問題無かったりして再現性も低いんですよね。
そのようですね。実は、昨日報告したマシンは仕事で使っている実験機です。
今は自宅なので、ノートマシンで似たようなこと（次の実験結果参照）をやってみた
のですが、問題は起きませんでした。
−−−−−
私は、ディスクアクセスの問題ではなくて、gzipの処理方式の問題かもしれないと思
い実験してみました。以下は、その実験結果です。
というのも、第１行を出力したときを０秒として相対時間を計算すると以下のように
なるからです。
KNOPPIX Live Linux2
0:00:00 0:00:00
0:00:43 0:00:16
0:01:07 0:00:28
0:02:04 0:00:44
0:03:37 0:01:00
0:05:35 0:01:15
0:07:58 0:01:32
0:10:47 0:01:47
0:14:00 0:02:03
0:17:36 0:02:18
0:21:23 0:02:35
0:25:47 0:02:51
0:30:35 0:03:07
0:35:48 0:03:22
0:41:29 0:03:38
これをExcelに入力して折線グラフを描かせると、KNOPPIXは放物線、Live Linux2は
直線を描きます。
何かの二乗に比例するアルゴリズムはたくさんあるので、ひょっとしてと思って、
man pageを読むと、--best（圧縮率優先）と--fast（性能優先）というパラメータが
あったので、これではないかと思ったのです。
で、ノートマシンで似たようなことをやってみたところ、以下のようになりました。
これでグラフを書かせると、どれも直線になります。（つまり、問題現象は発生
しませんでした。）
default --best --fast
0:00:00 0:00:00 0:00:00 Progress: 320 / 32000 ;
0:00:02 0:00:13 0:00:02 Progress: 640 / 32000 ;
0:00:05 0:00:21 0:00:03 Progress: 960 / 32000 ;
0:00:07 0:00:30 0:00:04 Progress: 1280 / 32000 ;
0:00:09 0:00:42 0:00:06 Progress: 1600 / 32000 ;
0:00:11 0:00:53 0:00:09 Progress: 1920 / 32000 ;
0:00:16 0:01:03 0:00:12 Progress: 2240 / 32000 ;
0:00:20 0:01:10 0:00:16 Progress: 2560 / 32000 ;
0:00:25 0:01:14 0:00:20 Progress: 2880 / 32000 ;
0:00:29 0:01:19 0:00:25 Progress: 3200 / 32000 ;
0:00:34 0:01:27 0:00:29 Progress: 3520 / 32000 ;
0:00:38 0:01:38 0:00:31 Progress: 3840 / 32000 ;
0:00:43 0:01:45 0:00:35 Progress: 4160 / 32000 ;
0:00:47 0:01:54 0:00:38 Progress: 4480 / 32000 ;
0:00:52 0:02:03 0:00:42 Progress: 4800 / 32000 ;
（中略）
0:07:17 0:12:48 0:05:59 Progress: 31040 / 32000
0:07:22 0:12:55 0:06:03 Progress: 31360 / 32000 ;
0:07:26 0:13:01 0:06:07 Progress: 31680 / 32000 ;
使ったコマンドは以下のとおりです。（ディスクが１台しかないので、出力先は
/dev/nullに変えました。必要なら$1に--bestや--fastを指定します。）
(mydd if=/dev/hda1 bs=63k count=32000 progress=320 |gzip $1>/dev/null) 2>&1
| (while read xxxx; do echo $(date +%T) $xxxx; done)
このノートマシンはFMV NB10Aで、CPUはceleron 1060MHz、メモリは256MBです。
−−−−−
一つ、気になることがあります。
うまくいくマシンはどちらも、メモリに余裕があります。
Live Linux2はKDEのかわりにfvwm2を使っており、ramdiskもルートＦＳの５ＭＢだけ
です。その分、メモリには余裕ができるので、メモリ128MBでスワップなしでも安定
動作します。
また、ノートマシンもメモリ256MB、スワップなしで安定動作しています。
しかし、昨日のマシンをKNOPPIXで使うときは、メモリ128MBでスワップなしだと
不安定になるので、スワップを追加しています。
このメモリが関係しているのでしょうか。例えば、メモリが少ないと、処理方式が
変わり、遅くなるとか。
# 自宅にメモリ128MB程度のマシンが無いため、確認できないのです。
何か分かりましたら、お教えいただけると幸いです。
よろしくお願いいたします。
| 