NISv20のクイックスキャンについて調べてみました

こんにちは! ライちゃんです。

 

NISv20のアイドルタイムスキャン(クイックスキャン)等について調べてみましたので発表します。

NISv20のクイックスキャン関係の仕様はNIS2012と全く同じでした。NIS2012で問題となった強制的に実行するタイプのクイックスキャンも、残念ながらNISv20でも修正されていませんでした。

 

 

アイドルタイムスキャン(クイックスキャン)

 

アイドル状態で行うクイックスキャンをアイドルタイムスキャン(クイックスキャン)と呼びますが、ちょっと長いので以降は「アイドルクイックスキャン」と表記します。

基本的な動作についてチェックしましたが、以前のバージョンから変更はありませんでした。

 

 

周期

アイドルクイックスキャンの周期は3日毎です。

一度スキャンを実行すると以降3日間はアイドルクイックスキャンをしなくなり、4日目以降にスキャンするようになります。

例えば7月8日 19::00にクイックスキャンを実行した場合、次回のスキャンは7月11日の19:00以降、PCがアイドル状態になった際に実行します。

 

ウィルス定義の更新との連動

ウィルス定義が更新されるとアイドルクイックスキャンが予約されます。ライブアップデートによりウィルス定義が更新されるとアイドルクイックスキャンが実行待ちの状態となり、次回アイドル状態になった際にアイドルクイックスキャンを実行します。

 

アイドルクイックスキャンの振る舞い

開始/終了時にはメッセージは表示しません。

NIS2012の初期のバージョンではメッセージの通知があり、後期のバージョンでは通知がなくなりましたが、NISv20ではメッセージの通知はありません。

 

スキャン中にマウス/キーボードの操作を行うとスキャンを中断します。

NIS2011(たぶんNIS2012の初期のバージョンも)ではスキャンが始まるとマウスやキーボードを操作しても中断しませんでしたが、NISv20はスキャンを中断します。中断した場合は次回アイドル状態になったときに再実行します。

 

まとめ

  • クイックスキャンの周期:3日ごと
  • ウィルス定義の更新後:アイドルクイックスキャンが予約される
  • スキャン時のメッセージ:なし
  • スキャン中に割り込みがあったとき:スキャンを中断する

 

 

強制的に実行するタイプのクイックスキャン

 

NIS2012が出た最初の頃、強制的に実行されるクイックスキャンが話題になったことがあります。マウスやキーボード操作をしている最中にアイドルクイックスキャンのようなスキャンが始まったというものでしたが、NISv20でも条件によっては発生します。

以降はこのクイックスキャンのことを「強制クイックスキャン」と表現することにしますが、2種類のタイミングで実行されることと、発生する条件について解説します。

 

ウィルス定義の更新後24時間後に実行する強制クイックスキャン

ウィルス定義の更新後、24時間以内にクイックスキャンが実行されない場合に強制クイックスキャンが実行されます。

ウィルス定義の更新とあわせてアイドルクイックスキャンが予約されますが、24時間以内にスキャンが行われないと強制クイックスキャンが実行されます。実行のタイミングはウィルス定義の更新時点から24時間後です。

 

長期間クイックスキャン行われない場合に実行する強制クイックスキャン

クイックスキャンが長期間行われない場合、最後にクイックスキャンが実行された5日後に強制クイックスキャンが実行されます。

4日に一度はスキャンしなさいということだと思いますが、前回クイックスキャンが実行されたタイミングから5日目に入った時点でスキャンが実行されます。

 

強制クイックスキャンが発生する条件

NIS2011からNIS2012、NISv20とソフトを上書きして更新した場合に発生します。NISv20を新規にインストールした場合は発生しません。

強制クイックスキャンはNIS2011の時の仕様だと思いますが、バージョンアップしてもそれが残っているような感じです。

 

強制クイックスキャンのふるまい

アイドル状態でなくても強制的に実行されます。

スキャン中はマウス/キーボードでは中断できません。

スキャン開始や終了のメッセージはありません(NIS2012の初期のバージョンではありました)。

 

 

<検証環境>

  • Windows 7 Home Premium 32bit SP1(仮想環境)
  • NISv20(ver.20.4.0.40体験版)

dual-QC-Xeon機(8コア、mem=64GB、disk=300GB×4)上でwinVista64+NIS2013(20.4.0.40)を使っています。 パフォーマンス性能管理のためにNISのバックグラウンドタスクの動きを調べていますが、「クイックスキャン」も調査対象のひとつです。 以下、システムを立ち上げて、アプリを動作させずNISの動きのみをモニターした時の情報です。

NIS2013ではシステム起動後、抑止時間(デフォルト20分)が経過するとバックグラウンド活動を開始しますが、 svchostが最近出来たファイルをはじめ、*.exeや*.dllを優先度=「very low」で逐次読み出して、NISの内部管理データベースが存在するc:\ProgramData\Norton\...¥ 傘下のファイルへの書き込みを行い、同時にNISのエンジンであるccsvchstがこれらデータベースファイルの読み書きを行って管理用データベースを逐次更新していきます。 私には昔の感覚が残っているので、「スキャン」とはファイルを逐次読み出して検査する処理だと思っているのですが、後述するようにNIS2013の「クイックスキャン」とは、この感覚に従えば「スキャン」とはいえないシロモノになって来ています。 スクリーンセイバーのタイムアウト時間を600分=10時間に設定して、ProcessHuckerで各種ファイルへのアクセス状況をリアルタイム監視できるようにし、NIS2013マネージャーのパフォーマンス画面を開いてNISのアイドル認識をモニターして、「クイックスキャン」の実行が履歴に記録される現場を観察してみたのですが、「クイックスキャン」が実行されている3分程度の時間帯ではccsvchstがc:\ProgramData\Norton 傘下のファイル群を盛んに読み書きを行い(優先度=Normal)ますが、OSやNorton以外のアプリ関連の*.exeや*.dllの読み込み(スキャン)は殆ど行われていませんでした。 この理由は 「ノートン インサイト:セキュリティを犠牲にすることなくパフォーマンスを改善するソリューション 」: http://communityjp.norton.com/t5/blogs/blogarticlepage/blog-id/npbj/article-id/21 を読んで見てみて理解が出来ました。 即ち、私の理解する「スキャン」は「クイックスキャン」が実行される前に実行済みだったのです。 NIS2013の「クイックスキャン」は感染しやすい領域のファイル群を実際に「スキャン」しているのではなく、事前のスキャンによって収集された各ファイルの特徴情報をパターン情報と照合して結果を出す仕組みになっており。この仕組みによって検査時間の短縮を達成しているようです。 ProcessHuckerを使って個々のファイルのI/Oをモニターするようになったのは最近の話であり、以前はシステム動作中のパフォーマンス低下の犯人が「クイックスキャン」だとばかり思っており、前出のsvchostによる各種ファイルの「バックグラウンドスキャン」も「クイックスキャン」の動作の一環だと考えていました。 しかしながら、ccsvchstの「クイックスキャン」がマウス/キーボード割り込みで一時停止するのに反し、svchostによる「バックグラウンドスキャン」はマウス/キーボード割り込みでも停止しませんし、CPU/DISKが高使用率のビジー状態(NIS2013はこれをアイドルと判定しています)になっても停止/中断をしませんので、この「バックグラウンドスキャン」は「クイックスキャン」とは独立の存在のようです。 こうなるとパフォーマンス管理の上では高々2-3分間の間だけ性能低下する「クイックスキャン」はどうでもいい存在であり、時によれば多数のファイルをスキャンすることで長時間にわたって性能低下させてしまうsvchostによる「バックグラウンドスキャン」のほうが問題であることがわかりました。

「バックグラウンドスキャン」をおこなっているsvchostはc:\ProgramData\Norton\...\○○.TMPに50-100kB/secで何かを書き込んでいる時間帯が支配的で、或るタイミングになるとccsvchstがデータベースの整理更新や検査を行っている時間帯があり、これら2つの動作が繰り返されるようですが、この途中にsvchostが以前の遣り残しのファイルや新規ファイルのスキャンを行います。 困るのは、しばしば突然にsvchostによって*.exeや*.dllを中心に殆ど全てのファイルがスキャンされる時間帯が出現することで、この時、望まざるパフォーマンス低下が起こります。 問題のsvchostは C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted であるとされていますが機能の説明はProcessHuckerからは報告されていません。 多分、NISのccsvchstが[Diagonostic system host]WdiSystemHostサービスとしてのsvchostを利用していて、「ノートンインサイト」のSHA256 暗号化ハッシュ計算などもここでなされているものだと思います。 パフォーマンス管理のために。このsvchostの「バックグラウンドスキャン」動作のスケジューリングがどうなっているかの解明して、動作の予見が出来るようになりたいと思います。

kawamoto76 様

 

こんにちは! ライちゃんです。

 

kawamoto76様がお悩みのバックグラウンド活動はクイックスキャンとは別のものということで間違いないと思います。

症状を拝見して思いついたのが「ノートンコミュニティウォッチ」です(確実とはいえません)。

ノートンコミュニティウォッチはPCの情報を収集をする機能らしいのでこれがあやしそうに思います。ノートンコミュニティウォッチはPC起動後の抑制時間(タスク延期)が過ぎると働きますし、アイドル状態に関係なく実行されます。

私のPCでは数秒から数十秒程度で終わる処理ですが、使用状況によっては長時間かかることもあるのかもしれません。実行に要した時間はノートンタスクで確認できますので、これが疑わしければ設定をOFFにするなどして原因を特定してみてはどうでしょうか。

ライちゃんさま、コメントありがとうございます。

「ノートンコミュニティウォッチ」はノートンタスクの実行履歴に記録されていますが、当方のマシンでは毎回10-15秒程度の実行時間であり、記録される時間帯も「バックグラウンドスキャン」とは無関係です。 多くのNISユーザーからUPされるアプリケーションモジュールファイルの信頼属性情報を集めたSymantecのサーバーとの間の情報交信機能が「ノートンコミュニティウォッチ」だと思います。

ノートンインサイト機構によってスキャン省略を行ってスキャンの時間短縮を行うには、大半のファイルを一度はスキャンしておかなくてはなりません。 優先度=「very-low」で順次スキャンを進めていっているのがsvchostの「バックグラウンドスキャン」であり、これにより各くファイルの信頼属性データベースが構築されるのだと思います。 NIS2010あたりではノートンタスクの完全スキャンでこれを行っていたようで、そのため注意書きには「最初の完全スキャン(バックグラウンド)は必ず実行して完了させてください」とかかれていました。 手動(フォアグラウンド)での完全スキャンを実施しても、単純に検査して結果報告し処置の指示を仰ぐだけであり、信頼属性データベースは構築されないので、信頼属性データベースを構築するには初回のバックグラウンド完全スキャンが必要だったものと考えられます。 NIS2013では信頼属性データベース構築のためのスキャンが「ノートンタスク」ではなくて、ccsvchstの基幹プロセスとして行われるようになったのだと思います。 NIS導入後、システムが使い込まれるとスキャン対象がなくなっていくので、新規ファイル以外にはスキャンの必要が無く、この「バックグラウンドスキャン」がパフォーマンスを損ねることは無いと期待されます。 NIS2013をインストールした直後に手動で「クイックスキャン」を行うと、逐次スキャンされるファイルの名称が表示され、10分以上の時間がかかりますが、数日使い込んだ後で手動「クイックスキャン」を行うと1-2分で「クイックスキャン」が終了し、「クイックスキャン」実行中には実際の「スキャン」は殆ど行われていないことがわかりますが、殆どのファイルは「実際スキャン」済みになっているはずです。 しかし、何らかの理由で「再スキャン」、即ちスキャン済みファイルの信頼属性データベースの再構築が開始されると、大きな負荷になります。

ノートンインサイトの説明:http://communityjp.norton.com/t5/blogs/blogarticlepage/blog-id/npbj/article-id/21 はNIS2009の発表当時のものですが、「思想」はNIS2013の現在でも引き継がれていると思います。 気になるのは、想定問答集の中での記述に以下のように書かれています。

Q:製品が実行されていない間(セーフモードで起動したり CD から起動した場合など)に信頼済みファイルが変更されていないとどうして分かるのですか?

A:起動時に NTFS ファイルシステムを分析し、掌握していない変更が認められた場合にはそのボリュームのすべてのファイルの信頼属性が破棄されます。

 

Q:それでも実際に誤って信頼した場合はどうなりますか?どのような情報をもとに、ファイルを再びスキャン対象に戻すのですか?

A:LiveUpdate の際に、破棄された SHA256 ハッシュのリストをクライアントが受信する「破棄メカニズム」が実装されています。この SHA256 ハッシュのリストに含まれているファイルを現在クライアントが信頼している場合、そのファイルの信頼属性はすべて破棄され、ファイルは再びスキャンの対象に戻されます。

 

即ち、起動時のファイルシステムのチェックで掌握していない変更が認められた場合にはそのボリュームのすべてのファイルの信頼属性が破棄されるので、当該のドライブに存在するファイルが全て「スキャン」され直されます。 また、NISの管理データーベースの異常が検出されたり、LiveUpdateによって多数のファイルの信頼属性が一挙に破棄されるような事態が発生すると、これらファイルの「スキャン」がやり直しになります。 立ち上げ時のチェックによって再スキャンが発生しているかどうかは、NIS活動開始後のファイルアクセス状況を確認すれば容易にわかるので、再スキャンが発生している場合は、終わるまでまってから業務を開始すれば、快適なパフォーマンスで使い続けることが出来るはずです。 LiveUpdateによる多数ファイルの信頼属性の破棄は突然に訪れますので、安定使用するためには自動LiveUpdateは殺しておいたほうが無難です。

kawamoto76 様

 

こんにちは! ライちゃんです。

 

ノートンコミュニティウォッチは関係しないとのこと了解しました。

考えられる原因ですがkawamoto76様の考えておられている通りかもしれません。私もそのあたりを疑っていました。

 

その現象は私も2度ほど見たことがあり、他のユーザからもこのフォーラムに何度か投稿がありました。私が見たのはPCをOSからインストールした後だったと思いますが、ディスクが長時間動いているのを不審に思いWindowsのソースモニタで確認したところノートンが(*1)ファイルを次々と読み込むような動作をしていました。ソフトはNIS2012でしたが、ノートンタスク上はなにも表示していませんでした。PCを再起動しても処理を再開し、電源を切って日が変わっても再開するような感じでした。処理がひととおり終了した以降は発生していませんが気になる動きでした。

 

kawamoto76様はその現象が起きたときにノートンタスクは確認されましたか。最近(NIS2012の後期)になって追加されたタスクがいくつかありますがそれらが動いているということはありませんか。「インサイト保守」と「製品保守」という項目があやしそうな気がします。

 

*1 その時はノートンが動いていると判断しましたが、なぜそう判断したのかは覚えていません。

NISの活動モニターではProcessHucker画面とNISマネージャーのパフォーマンス画面を表示してモニターしていますが、svchostによるスキャン(今後は「プレ-スキャン」よ呼ぶことにします)は「インサイト保守」、「製品保守」ではありません。 「インサイト保守」、では主にc:\ProgramData\Norton傘下のファイルが読み書きされており、ファイルの信頼属性データベースのメンテナンスが行われていると思われます。 「製品保守」ではc:\ProgramData\Norton傘下のファイル、C:\Program Files (x86)\Norton Internet Security傘下のファイルに対する読み書きが行われていて、主にNISの関連ファイルの改ざんの有無をチェックしていると思われます。

NISの主たる目的はウィルスの検出/除去、ネットワークからのファイアウォールですので、ノートンタスクの実行履歴の記述はパフォーマンス監視のためではなく、セキュリティー管理の節目を記録しています。 即ち、svchostの「プレ-スキャン」ではウィルスを検出/除去するわけではなく、ファイルの信頼属性データベースに各ファイルの特性パラメーターが登録されるだけであり、ウイルスかどうかを判定して除去(自動/手動)するか、信頼登録するかという「検査スキャン」が行われるのは、これら特性値とウイルスパターンを突合する「クイックスキャン」あるいは「完全スキャン」が行われなければなりません。 即ち、「クイックスキャン」/「完全スキャン」の完了時点が耐ウイルス性からみたマシンの信頼性の変更ポイントになりますので、ユーザーがこれを知ることが出来るように表示を行っているものと思われます。 しかしながら、パフォーマンス管理の視点から考えると、「クイックスキャン」/「完全スキャン」以外のノートンタスクの負荷は軽微であり、「インサイト」機構の導入によってNIS2013では「クイックスキャン」は負荷として認識する必要がないほど軽くなっています。(但し、「プレ-スキャン」が処理不十分な状況で実行された場合には、未処理ファイルのウィルスチェックをするので負荷は大きい) ノートンタスクの「完全スキャン」については未観察ですが、これも「インサイト」機構によって、軽微な負荷になっているものと想像します。 従って、NISの活動によるパフォーマンス低下を予見する際に注目すべきなのはこれら「ノートンタスク」の挙動ではなく、svchostによる「プレ-スキャン」の仕上がり具合、および「プレ-スキャン」のやり直しの予約状況がどうなっているかという点です。 NIS2013の64bitOS版(C:\Program Files (x86)\Norton Internet Security\Engine64)は20.3.1.22の時代はマシンを立ち上げるたびに全数「プレ-スキャン」が行われていました。 20.3.1.22では信頼属性データベースが毎回、最初から構築され直されていたと思われますが、20.4.0.40になってからは、立ち上げ後に全数「プレ-スキャン」されることはなく、新規ファイルを中心に「プレ-スキャン」されるように変わり、64bitOSのマシンのパフォーマンスは一挙に改善しました。 「プレ-スキャン」は優先度=「very-low」で実行されており、OSの優先度管理にユーザーアプリプロセスのパフォーマンス維持を任そうという思想だと思いますが、優先度管理はあくまでCPU占有時間に関するものであって、DMA転送中心のディスクI/Oを管理しているものではありませんので、優先度指定だけでは全数「プレ-スキャン」の嵐を抑えることには不十分であるように思います。 やはり、Norton以外のディスク使用率を常時モニターし、他のプロセスがディスクを使っている際には「プレ-スキャン」のスキャン速度を抑える仕掛けを採用して、DISKのアイドル時間帯に「プレ-スキャン」が加速するという仕掛けが導入されることがベストであり、この仕掛けの導入によってNISのバックグラウンドプロセスがマシンパフォーマンスを低下させることを回避してもらいたいと思います。

kawamoto76 様

 

こんにちは! ライちゃんです。

 

ヘルプを見ているとインサイト保守があやしいと思ったんですがちがうんですね。

 

私のPCではそんな動きはしているようには思えません。PC起動後はディスクアクセスはほとんどなくなります。

※普通の個人のPCなので新しいファイルなどはそんなにありません

 

私が経験した現象はその時だけのもので1回きりでした。NISの前のバージョン(20.3.1.22)も起動後に全ファイルを検査するようなことはしていませんでした。

 

問題となっているsvchostですが、ノートンが関係しているのは間違いないのでしょうか。svchostを動かしているのはノートン関係のプログラムですか。OSや他のアプリケーションによるものということはないのですか。

32bitOS上でのNISのエンジンは 32bitOS上の C:\Program Files\Norton Internet Security\Engine ですが、 64bitOS上でのNISのエンジンは C:\Program Files (x86)\Norton Internet Security\Engine と

C:\Program Files (x86)\Norton Internet Security\Engine64 の2本立てで、 名前からすると、主にEngine64が使われるはず。 宣伝カンバンやの目標仕様は同一ですが、走行しているアプリとしては、32bitOS上のNISと64bitOS上のNISは別物です。 特に、日々更新ごとに変動している詳細仕様やバグについては32bit/64bitで異なります。 OS種別でも差異が出ますが、32bit上NIS(32bit版と呼ぼう)と64bit上NIS(64bit版と呼ぼう)は「別物」と考えてください。

svchostの「プレ-スキャン」は通常では新規ファイルをスキャンするだけです。 NISは各ファイルの信頼属性のデータベースを使ってウィルススキャンの高速化を実現していますが、このデータベースを構築するには各ファイルの特性値を収集し、パターンファイルと突合して、各ファイルを分類するのですから、フロントエンド(手動)で「完全スキャン」を行うのと同等、あるいはそれ以上の累積時間が必要なはずです。 NIS導入後に粛々としてこの作業が進行していくはずですが、優先度が低く把握が難しい動きです。 他の場所にも書きましたが、手動スキャンでは信頼属性データベースは構築されません。 ユーザーが気がつくかどうかは別として、いづれにせよ、NISを導入して放置すれば信頼属性データベースが構築されます。 注意が必要なのはこの信頼属性データベースが破壊されて再構築が必要になることがあるということで、どのような場合に再構築が必要になるを知っておきたいのです。

動作中のVista64+NIS2013では多数のsvchostが動いていますが、各々個別のプロセス番号が付与されています。 マシンが違うと、また立ち上げる度に異なるプロセス番号になりますが、シャットダウンするまでは同じプロセス番号が保持されますので、プロセス番号によって識別できます。 問題にしているsvchostについては、C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted で起動されたものであるとされていますが、これを利用しているプロセスの説明はProcessHuckerからは報告されていません。 svchost自体はLocalServiceNetworkRestrictedを引数にしていることから、WdiSystemHostサービス[Diagonostic system host]だと推察されます。

システム立ち上げ後、新規ファイルを中心にsvchostが順次にファイルを読み出していきますが、並行してc:\ProgramData\Norton\...\○○.TMP に書き込みを行いますので、NISによって読み書きが指示されていると考えるのが合理的です。 ファイルの読み出しがなくなってもc:\ProgramData\Norton\...\○○.TMPに50-100kB/secで何かを書き込んでいる時間帯が続き、しばらくたつとccsvchstがc:\ProgramData\Norton\...\○○.TMPを読み書きして、c:\ProgramData\Norton\...\傘下のファイルを更新する嵐が発生しますが、一段落すると当該svchostによる読み書きは消失して、ccsvchstによるc:\ProgramData\Norton\...\傘下のファイルの読み書きと「system」による$logfile、$MFTへの読み書きのみが残ります。 時間が経過すると、再びsvchostがc:\ProgramData\Norton\...\○○.TMPに50-100kB/secで何かを書き込んでいる時間帯が始まり、ccsvchstにいたる動作が繰り返されます。 問題のsvchostはOS付帯のプロセスですが、これら一連の観察結果から考えると、それを使っているのがNISのccsvchstであることは、間違いないと思います。

尚、NISのバックグラウンド動作を詳細調査するには、ディスクのアクセスランプやタスクマネージャーでのI/O頻度のモニターでは不十分であり、これらだけでは判断を誤ります。 現状のNISの動作仕様を把握するためには、時々刻々アクセスされるファイル一つ一つの名称と各々のファイルにアクセスしているプロセスを知ることが必須です。

NIS2013-20.3.1.22での32bit版と64bit版の違いについては、以前に

「32bitOS上と64bitOS上で重さがぜんぜん違うNIS2013-20.3.1.22」http://communityjp.norton.com/t5/forums/forumtopicpage/board-id/NIS_NAV/thread-id/3514

で報告していますが、32bit版については導入したばかりにはsvchostの全数プレ-スキャンが観測されましたが、それ以後はsvchostによるプレス-キャンは新規ファイルについてのみでした。 32bit版についてのライちゃんの報告は妥当ですが、64bit版については当てはまらないと思います。

また、20.4.0.40では大幅に改善があり、以前からは状況が相当に変化しているはずです。 上記報告はあくまで20.3.1.22の時のものであることに注意してください。

kawamoto76 様

 

こんにちは! ライちゃんです。

 

その症状はノートンが原因ではないと思います。LocalServiceNetworkRestrictedは複数のサービスをグループ化したものに付けている名称のようで、その中には複数のサービスを含みます。

レジストリの HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost  でグループの内容を見られます。

 

冒頭でノートンが原因ではないと書きましたが、ノートンはサービスがファイルにアクセスするのでそれを監視する為に動いているのだと思います。

ノートン動くからサービスが動いているのではなく、サービスがファイルにアクセスするからノートンが監視しているのだと思います。

例えばWindows 7のデフラグはSvchostと使って起動しますので(Vistaは違います)、見た目には今回の現象と同じような状況が発生します。デフラグを実行するとSvchostがディスクにアクセスを始めI/O優先度はバックグラウンド(Process Hackerでのvery-low)です。プロセス上はSvchostが動いているように見えますが、その実体はデフラグサービスです。ノートンもそれに連動してディスクI/Oを行ないます。これはデフラグが動くからノートンが動いている訳ですが、kawamoto76様の症状も同じと思います。たぶんノートンを無効にしたりアンインストールしてもSvchostのディスクアクセスは止まらないと思います。

 

Svchost とサービスの件に戻りますが、LocalServiceNetworkRestrictedに間違いはありませんか。良く似た名前でLocalSystemNetworkRestrictedというのもあります。そちらではありませんか。

実はうちのVista(仮想環境)をテストの為に起動したのですが、今まさにkawamoto76様の現象と似たような状況が発生しています。PC起動時にSvchostがディスクにアクセスを続けていてファイルを順次読み込んでいます(ものすごく遅いです)。私のPCの場合はサービスのグループはLocalSystemNetworkRestrictedでしたので同じ現象ではないかと思ったのですがどうでしょうか。

※Vistaのリソースモニタは使いにくいのでProcess Hackerを入れてみました。

 

 

【提案】原因を追究するために次の提案をさせてください。

  1. 状況発生時Svchostの実体であるサービスを特定する。
    Process Hacker上ではSvchostの下に階層付きで表示するのが実際のサービスだと思います。Processのタブで並び替えしていない状態で確認できます。
    ※WdiSystemHostは違うように思います。うちのVistaではそのサービスは別のグループに所属していました。
  2. サービスのグループ名を再度確認する。LocalServiceNetworkRestricted または LocalSystemNetworkRestrictedのどちらなのか。

ライちゃん様コメントありがとうございます。 ライちゃん様の検証報告では32bit/64bitが明記されていませんが、 64bit環境で検証されたものと期待します。 NISの外部仕様は共通のものであっても、内部動作は32bit/64bitの違い、またOSの違いによって異なっており、パフォーマンスの違いが出ていると考えます。 尚、windowsのdefragは当方の要求にかないませんので、当方環境ではboot-time-defrag機能も含めwindowsのdefrag(=NISの「最適化」)は殺しています。

問題のsvchostのpropertyの報告にミスがありました(多分サービス一覧を参照しながらreportしたので、その時に間違えなのでしょう)。 ProcessHucker上では、ご指摘のとおり、「LocalSystemNetworkRestricted」でした。 「LocalSystemNetworkRestricted」を引数にしているサービスはたくさんあります。 思い当たるのが「WdiSystemHost」ですが、サービスマネージャーで調べてみてもこのサービスは走行していませんでした。 ProcessHuckerの表示で、問題のsvchostの直下にあるのは「dwm.exe」(デスクトップウィンドウマネージャー)ですが、dwm.exeが全ファイルをナメるというのは、必要性があるのかなと不審に思い、これは無視していました。 ライちゃん様の検証時には起動後、svchostが全ファイルをナメる様な動きが観察されたとありますが、多分、NIS導入まなしで、まだ使い込まれていないマシン上の話だと思います。 20.3.1.22の時には起動するたびにsvchostが全ファイルをナメるような動きをしていたのですが、20.4.0.40になってからは、使い込むと起動時にsvchostがナメるのは新規ファイルと前回のナメ残し(新規追加された数GBの動画データなどは、プレ-スキャン未了で持ち越されるものと推定)のみになり、負荷も無視できるようになっています。 30.3.1.22→40.4.0.40でのsvchostの挙動の大きな変化が見られたことから、このsvchostはNISのccsvchstが動かしているという確信を持つに至っています。 また、このsvchostが各ファイルをプレ-スキャンしてNISの必要とするSHA256 暗号化ハッシュの計算などを収集するのでなければ、プレ-スキャンはいつ、どのプロセスが行うのでしょうか? NISを再インストールしてからの動きをモニターしてみても、このsvchost以外には思い当たるものがありません。 尚、突然svchostが多数のファイルをナメ始める事態は40.4.0.40ではめったに起こらなくなってきています。 しかしながら、ノートンインサイトの説明では 「A:起動時に NTFS ファイルシステムを分析し、掌握していない変更が認められた場合にはそのボリュームのすべてのファイルの信頼属性が破棄されます。」 という事項がありますので、どのようなアプリがいくつかのファイルについて「Nortonの掌握できない変更」を行うのかを知っておくことは、パフォーマンス維持の上では極めて重要だと思います。 現在の私の理解ではNIS2013-20.3.1.22で見られた起動毎の直後のsvchostの総なめプレ-スキャンが、まさにファイル信頼属性データベースの再構築の下準備「プレ-スキャン」だと思います。

追記:
ProcessHuckerを動かす際には「管理者モード」で起動してください。 通常ユーザーモードから起動すると、ファイルごとのアクセス状況を表示するための「disk」タブが表示されないので、個々のファイルへのアクセス状況を見ることができません。 「管理者モード」で起動すると「disk」タブが表示され、これを開くとファイル毎のアクセス状況が調べられます。

kawamoto76 様

 

こんにちは! ライちゃんです。

 

私のVistaでファイルをアクセスしていた原因は、Superfetch(サービス名sysmain)というサービスでした。見た目はkawamoto76様で起きている現象と良く似ています。

 

ひとつ訂正します。先の投稿でProcessHuckerについて間違ったコメントをしました。Processタブで階層を下げて表示しているのは実際に動いているすべてのサービスを表示している訳ではありませんでした。LocalSystemNetworkRestrictedのようにグループ管理されているサービスの場合は、ひとつずつサービスを当たっていかないと原因は特定できませんでした。

 

もう少し調べてからまたレポートします。

 

※私のVistaは32bitのHome Premiumです。

※ProcessHuckerは管理者モードで使っています。追記ありがとうございました。

既にご承知のことのはずですが、ユーザー毎/グループ毎のACLを保持しないwindows95/98の思想を踏襲した「HomeEdition」と
ユーザー毎/グループ毎の個別ACL管理を行うNT3.5/4.0の思想を踏襲した「ProfessionalEditon」ではOSの内部動作が異なります。 XP以降、Home/Proは作りが似通ってきてはいるものと思いますが、細部では相違が出てくるところが多いのではないでしょうか? Proで動作が検証されている事項はHomeでも正常動作すると思いますが、その逆は成り立たないことがあるはずです。 従って、32bit/64bit共に動作検証は「Pro」で行ったほうがいいと思います。 特に、パフォーマンスの問題については、「Pro」で問題が無いので「Home」もOKだろうという推定が妥当で、逆の「Home」は問題が無いが「Pro」もOKだろうという推定は危険です。

kawamoto76 様

 

こんにちは! ライちゃんです。

 

エディションなどにより同じVistaでも違いがあるのは認識していますが、私は個人のユーザなのでそんなに色々な資源は所持していません。Vistaは32bit版のHome Premiumしかもっていませんのでそれでやってみるしかないですね。

 

私のVIstaの状況は次の通りです。

 

【現象】PC起動直後1分~数分後にSvchostがファイルを次々と読み込んで行く。対象のファイルはOSやアプリケーション、一般的なデータファイルなど様々。

ディスクI/Oの優先度はvery-lowです(ProcessHucker上での表現)。

ProcessHuckerで見るとSvchostの下にdwm.exeを表示しているプロセスがこの処理を行っています。サービスのグループ名はLocalSystemNetworkRestrictedです。

 

【原因】Superfetchがファイルをキャッシュしようとしているのが原因でした。

現象が起きている最中にSuperfetchを停止するとディスクのアクセスが止まりました。また、Superfetchのサービスを無効にしてPCを起動すると現象は発生しましせんでした。

Superfetchのサービスが無効の状態でPCを起動し、サービスを手動で開始すると開始した瞬間にディスクへのアクセスが始まります。

※サービス名:SysMain 表示名:Superfetch

 

SuperfetchはPC起動時以外にもメンテナンスのために様々な処理をしているようです。PCを使っていない時に活動したりするそうですので、これを疑ってみてはどうでしょうか。

 

ご提案

Superfetchが原因かどうかを確認する。Superfetchのサービスを無効にした状態でPCの動作を確認する。

実機でのテストが難しいようであればVistaの検証環境を作ってみても良いかもしれません。

私の考えではこれに間違いないんじゃないかなと思っています。kawamoto76様にもぜひご確認いただければと思います。

Vista64(SP2)+NIS2013-20.4.0.40でSuperFetchサービスを無効にすると、問題のsvchostが新規追加ファイルにアクセスする現象、および長期にわたりc:\ProgramData\Norton\...\○○.TMP に読み書きを行う現象は観測されなくなりました。 ググってみると、http://agorian.com/web/vista/000099.htmlのようにVistaのSuperFetchはVistaリリース(SP0)時はパフォーマンスを損ねるとして嫌われていたそうです。 *.exeファイルを片っ端からメモリーにキャッシュするサービスと説明されていますので4GBの壁がある32bitでは全てが入らないので影響が少ないが、当方マシンのようにmem64GB+pagefile128GB=192GBのメモリー空間を持つ大容量64bitマシンの場合、システムに存在する全exeを取り込んでもまだ余裕があるので全てをキャッシュにかかるので影響が大きいのかもしれません。 ただ、*.tsや*.m2tsなどの数10GBサイズの大容量動画データもsvchostでスキャンされますので、*.exeファイルをメモリーにキャッシュするというだけでないようです。 Vista(SP1),Vista(SP2)で改善が進んだとは言われますが、デフォルトONで導入されているWin7でもそれなりのパフォーマンス阻害があるのかもしれません。

とわいえ、このSuperFetch由来のsvchostとNISがまったく独立な関係ということではありません。長期にわたりc:\ProgramData\Norton\...\○○.TMP への読み書きがなされることから、NIS2013がSuperFetchをフックして情報を取り出しているように見受けられます。 NIS2013では20.3.1.22まででは、このsvchostによるファイルの総なめ嵐があったのがNIS2013-20.4.0.40では殆ど見られなくなっていますので、NISがSuperFetchの動作に影響を及ぼしていることは明らかです。 ライちゃんのVista32の観察報告を考慮すると、以前の私のxp32とVista64の比較の「32bitは軽く、64bitは重い」という結論は、「xpは軽く、Vistaは重い、7は不明」に書き換えなければならないのかもしれません。 SuperFetchをフックして各ファイルの特性値を収集するというやり方は、観察結果からは可能性が大なのですが、default=ONのSuperFetchを殺して使うユーザーではどうやるのだと考えると、声が小さくなってしまいます。 OSごと、SuperFetchのON/OFF事情によって収集方法を選択分岐している可能性もありますが、いづれにせよ、もっと観察してみなければわかりません。 NIS2013-20.3.1.22に戻して、SuperFetchをOFFにしてテストしてみましょうか。。。。

 

今回、議論に加わって言いたかったのは、クイックスキャンが対象ファイルを総なめするものではなく、

(1)何らかのバックグラウンドプロセスによる各ファイルの特性値の収集 (私が定義した「プレ-スキャン」)

(2)プレ-スキャンで収集した特性値DBとウイルスパターンDBとを突合してウイルス判定を行うノートンタスクの「クイックスキャン」 この際、信頼属性DBで信頼済みのものについては突合がskipされ、突合結果で信頼性DBは更新される

(3)必要と思われるファイルについて信頼属性DBと特性値DBの情報をSymantecのサーバーに送信する処理

(4)多数のユーザーによって報告されたSymantecサーバーの情報を取得して、信頼属性DBを更新するノートンコミュニティ

(5)Liveupdateによるウイルスパターンの更新、および信頼属性DBの更新(信頼無効化)

という一連の処理の中の一環であるということであり、読み込み対象は各ファイルの特性値DBであって読み込みサイズが小さく、処理も数分で終わってしまうので、いつクイックスキャンが実行されるのかということはパフォーマンス管理の上ではさほど気にする必要が無いように、NISが成長しているという点です。 そして、パフォーマンス管理の上では、実際にファイルをなめる「プレ-スキャン」の動作(これこそがパフォーマンスを阻害する)がいつ、どうやってなされるかを知り、注意書きにある信頼属性DBのresetに伴う大量の「プレ-スキャン」を誘発する原因が何かなのかを知っておくことだと思います。

kawamoto76 様

 

こんにちは! ライちゃんです。

 

VistaではSuperfetchのハードディスクにアクセスし続けるという振る舞いがユーザに嫌われているようで、機能をOFFにしているひともいるみたいですね。

そういえば私のPCはVistaでは空きメモリ0MB(メモリ4GB./32bitOSでの環境)近くというのが普通の状態でしたが、これはSuperfetchの働きによるものだそうです。未使用のメモリが出ないように積極的にキャッシュするようで、OS、exe、データファイルなどユーザが使いそうなあらゆるファイルをキャシュしようとします。

Windows 7ではSuperfetchの働きはユーザに嫌われないようにおとなしい仕様に変更されたそうですが、SSDのドライブを使用しているとSuperfetchはデフォルトでOFFになります。私もSSDを使っていますので、Superfetchの存在自体を忘れてしまっていました。

 

SuperfetchはユーザのPC使用状況を判断して必要になりそうなファイルをメモリにキャッシュするそうなので、ユーザから見ると不思議な動きします(曜日や時間帯まで判断するそうです)。起動時のキャッシュ動作は再現性が100%なので確認しやすいですが、起動後のSuperfetchの動きは検証するのは難しいかもしれません。

 

原因がSuperfetchだと特定できた後のことですが、Superfetchを完全に無効にするとパフォーマンスが落ちる部分があるでしょうから、設定を変更すると良いかもしれません。

次のリンクはマイクロソフトのコミュニティのトピックですが、回答しているのはマイクロソフトのモデレータの方なので信頼できる回答だと思います。

PCを使っていない時にディスクにアクセスするのは、プリフェッチという機能が動いているからのようです(すいません自分でははっきり理解できていないところはあります)。Superfetchのサービスは有効にしたままでプリフェッチを止めてやれば長時間のデータ転送時のディスクへの負荷が少なくなりそうな気がします。

 

マイクロソフトコミュニティ:SuperFetch がキャッシュするアプリケーションやファイルを設定することはできますか?

http://answers.microsoft.com/ja-jp/windows/forum/windows_vista-performance/superfetch/af4187bb-463c-45e4-8f85-b447881c97b6

 

***

 ご参考

kawamoto76様がプレ-スキャンと定義されたノートンの事前のファイル検査は、システムの完全スキャンで行っていると予想します。デフォルトではシステムの完全スキャンはONですし、NIS2011の時代には一定の期間実行できないとクイックスキャンのように強制的に実行する仕組みもありました。 他にはクイックスキャンやファイルを使う際の通常のスキャンでも記録しているんじゃないかなと予想します。