８月１日（月）から始めた Windows 7 の Windows update 、まだ終わってません。
ついに４日目に突入です。初日、ＯＳが壊れたか、と思った事態は、単に遅いだけだったかもしれません。余計なことをやってしまい、それでなくとも時間がかかるのに、さらに時間をかけてしまっただけだったかも。
ここ３日間、半日「更新プログラムを確認しています…」の画面を表示したまま、変化がないので、いっしょにインストールするオフィスやアプリケーションをインストールしてはＯＳをリブートして最初からやりなおし。また、ダウンロードしたパッチを当てるため、コマンドラインから更新処理を停止してＯＳをリブートしては、また、最初からやりなおし、といった作業を繰り返してきました。
半日も変化がないのは不安なんで、タスクマネージャーのパフォーマンスやリソースモニターを表示していて、遅い理由がなんとなく解ってきました。
Wndows Update の実行中は、まず、ＣＰＵのコアをまるまる１個占有してます。２コア４スレッドタイプのＣＰＵなので、他にも作業はできますが、かなり重い感じです。そして、メモリーを２．３Ｇバイト程度使ってます。幸い、今回設定したＰＣは、４Ｇバイトのメモリーを積んでいたので、スワップを使うことはありませんでした。スワップにいったらHDD搭載なので、はんぱでない重さになります。
そして、一番の特徴ですが、Windows update 動作中は、常に毎秒500バイト程度をネットワーク経由で送信しているようです。ネットワークで毎秒500バイト、という数値は、昔のダイヤルアップ回線並みですね。アナログ回線の時代ならあったかもしれませんが、ＬＡＮの世界では絶対に見ない数値だと思います。
もし、こんな調子でサーバーに送って確認しているのなら、わすか20Mバイトのデータの確認に10時間もかかる計算になります。ＯＳの更新確認に必要なデータが何バイトかは解りませんが、プロセスとして実行されている svchost.exe のメモリー占有サイズはそれほど大きいもではありません。しかし、たった20Mバイトに10時間かかる環境で、データを送っている訳ですから、もうとにかく時間がかかる訳です。
それも、マイクロソフトのサーバー相手に、ずっとこんな調子のスピードという訳ではなく、パッチのダウンロードが始まると数kバイトの転送がいきなり始まります。きっとサーバーがまったく別の仕様なんでしょう。Ｗｅｂからファイルでパッチをダウンロードしても、全く遅いと感じることはありません。
ちょうど、Windows 10 の Aniversary update が始まったばかりで、ＯＳ更新用のサーバー
は混んでいたのかもしれず、Windows 10 以外の更新の帯域を大幅に制限していたのかもしれませんが、でもね…
だだし、世の中にはパソコンを使う全員が高速の回線を利用している訳ではなく、遅い回線を使っている人も多くいるのも確かです。例えば、スマホのデザリング機能を使ってパソコンをインターネットに接続しているような場合。こういうケースは、ゆっくり転送した方がいいのかもしれません。でも、転送方法などはどうするかをユーザーに決めさせる、というのが親切なやり方で、一方的に企業側の都合を押し付けるのは、ちょっとね。
などと書いている間に、Windows Update が終わったようです。
いや、やっとこのパソコンから開放されるかと思うとちょっとうれしいのですが、その先ずっとこんな感じだとすれば、やってられないな、という複雑な思いをしています。
