Vista-ultimate-64bit(8コア、mem=64GB、disk300GB×4)上でNIS2013-20.4.0.40を使っています。 動画処理中はCPU利用率80～100%の状態が2～24時間の間、続くのですが、処理が終わってからNortonタスクの履歴を調べると、下図のようになっていました。
図中から、80%超の高負荷連続状態をNISは「アイドル」と判定してしまっていることがわかります。 この状態では「アイドル」によるタスクスケージューリングは「めちゃくちゃ」にスケジューリングされてしまいます。 これまで問題が多かった「アイドル判定」ですが「20.4.0.40」でも未だ改善されていないようです。 尚、このマシンではCPU高負荷で使うことが多いマシンなのでパホーマンス警告の「CPU」はOFFにしています。 ONにしたときの実験は行っていませんのでONのときにどうかは不明です。
Vista64+NIS2013(20.4.0.40)のマシンを2台(各4本のDisk)用意し、マシンAの1本のDiskをマシンBと共有して、Giga-LAN経由でマシンAの約200GBのファイルをマシンBにコピー(マシンBのExplorerからワンクリック)しました。 コピーは50-100MB/secで進行しましたが、1時間以上かかりました。 マシンAはあらかじめScreenSaverを長時間無効にした上でProcessHuckerを起動しておいてファイルアクセスをコピー中にモニターしたのですが、コピー中にバックグラウンドスキャンが走り出し、コピー速度が低下しました。 事後、マシンA、マシンBのNortonタスク履歴を確認したところ、両者共にコピー中の期間を「アイドル」と表示していました。 20.4.0.40の「アイドル」判定はめちゃくちゃですね。 32bitOS上では適切に動作するのかもしれませんが、64bitのVista64上では適切に判断されていません。
スクリーンセイバーのアイドル判定はマウス操作やキーボード操作の有無で「アイドル」を判定しているが、これはスクリーンセイバーが起動されている状態がマウス操作やキーボード操作の障害になるので、起動による障害を回避するための判定が正しく行われてるといえます。 しかしながら、マウス/キーボードによる「アイドル」判定は操作者が「ビジー」かどうかを判定しているのであって、マシンがビジーかどうかを判定しているのではありません。 マシンが本当にビジーな状態では、高負荷、高ディスク使用率の状態が長時間連続するため、操作者は離席してしまい、キーボード/マウスは一切触れられないことが多いのです。 NISのアイドルタスクはディスクに対してのアクセスが連続して頻繁に行われるので、アイドルタスクの走行によって発生する障害はアイドルタスクによるディスクアクセスの占有です。 従って、アイドルタスクを実行していいかどうかの判定は、NIS以外のプロセスによるディスクアクセス頻度が高ければ「ビジー」で低ければ「アイドル」であるという判定が行われるべきなのです。 また、アイドルタスク走行でのCPU使用率の増加は高性能マシンでは無視出来ますが、レガシーな低性能マシンでは他のアプリの走行性能を低下させてしまうので、CPU利用率もアイドルタスク起動の可否判断に必要な判断材料です。 現状のVista64上の20.4.0.40ではディスク／CPUの両利用率によるという正しい(適切な）「アイドル判定」が行われていません。 操作者の「ビジー」を検出するマウス／キーボードによるアイドル判定はそれなりの意味があるのかもしれませんが、アイドルタスク走行の可否を判断するには使い物になりませんので、ＮＩＳの定義する「アイドル状態」をDisk/CPUの低使用率な状態であると定義を改め、「アイドル状態検出」をあるべき姿に改めていってもらいたいと思います。
キーボード入力とマウス操作が一定時間の間なければ、CPU使用率が100%近い状態でも、激しいディスクI/Oが行われていても、お構いなしに「アイドル」とNISが判定してしまう、このばかげた仕様は新バージョン「NIS2014」になっても修正されていないのだろうか？