E3abc
21
youfo 様
こんにちは！ ライちゃんです。
わかりにくい表現ですいません。「スケジュールを設定するのは一般的な使い方ではないように思います」というのは、ノートンユーザーでカスタムスキャンのスケジュール設定を使いクイックスキャンを実行しているユーザがどれだけ居るのかということです。
私見ですが、そのような使い方をしている人はほとんどいないと思います。一般のユーザーはそんな機能があること自体知らないと思いますし、アイドルタイムスキャンの機能がありますからカスタムスキャンを設定する必要もありません。
＞スキャンスケジュールで、スキャンの実行 アイドル時のみ というのが、上記スケジュールでスキャンできなかった場合に、
＞アイドル時になったら、スキャンする というオプション => ライちゃんさん、オプションの意味を理解しました
すいません、この部分の意味がわかりませんでした。
「スキャンの実行、アイドル時のみ」の項目は「スキャンできなかった場合に、アイドル時になったら、スキャンする」という意味ではありません。スケジュールした予定時刻が来た場合、アイドル状態を判断して実行するのか、アイドル状態に関係なく実行するかの区分です。
チェックをはずす・・・アイドル状態に関わらずスケジュール通りに実行する（アイドル状態を無視して実行する）。
チェックする・・・予定時刻に到達した時にアイドル状態なら実行する。アイドル状態でなければ実行しない。
E3abc
22
＞ライちゃんさん
つまり、スケジュールされたクイックスキャンの場合、ソフトのインストールなどの途中にスキャンが始まってしまう可能性があるということでしょうか？
E3abc
23
E3abc 様
こんにちは！ ライちゃんです。
カスタムスキャンでスケジュールを設定するとすると、「アイドル時のみ」のチェックを外して登録することになりますよね（そうでなければ意味がないと思います）。
その場合、予定したスケジュールが来るとＰＣの操作をしているときにもスキャンを実行します。スケジュールが合えばソフトのインストールの途中にもスキャンされるのではないでしょうか。
あと、スケジュールは毎週何曜日の何時とか、毎日何時に実行といった設定をしますが、そのタイミングで実行できなかった場合、別の機会に再実行する仕組みがあるのではないかと思いますので、今スキャンして欲しくないのにスキャンされたみたいなことはあるかもしれません。
E3abc
24
手動スキャンはccsvchstが通常優先度で直接に各ファイルにアクセスして検査を行います。 これに対してバックグラウンドプロセスとして実行されるスキャンはccsvchtからキックされたsvchostが低優先度で各ファイルにアクセスして検査を行い、ccsvchtはsvchostから報告された検査結果をまとめてNIS内部の検査履歴データベースを更新します。 注意しなくてはならないのは手動スキャンの実施実績はバックグラウンドスキャンのスケジュールに何の影響も及ぼさないこと、また検査結果は検査データベースに一切反映されないこと、つまり手動スキャンとバックグラウンドスキャンはまったく独立で無関係のようです。 従って、手動スキャンを実施しておくことで近未来にバックグラウンドスキャンが走行しだすことが無いようにすることは出来ません。 飛行機への搭乗前にトイレを済ませておいて、機内でトイレに行かなくてもいいようにしておくようなことは出来ないのです。
バックグラウンドスキャンのスケジューリングはOSのATコマンドのようにタイマー割り込みによって特定のプログラムを実行するような作りではなくて、ccsvchtの動作管理データベース上のパラメーターを書き換えることで、ccsvchtの内部フローを制御するつくりだと思います。 そして、スケジュールされるのは「起動」だけであり、「動作」ではありません。「サイレントモード」を指定していない状況下では、走り出してしまえば、何があってもそのまま走り続けてしまうという特徴があります。 アイドル状態になってスキャンが走り出した直後にマシンを使い始めると「重い」状態で作業しなくてはいけなくなりますので、注意が必要です。 完全スキャンで100GBが10MB/secでスキャンされることを想定すると、１万秒：3時間程度走り続けるのです。 クイックスキャンだとスキャン対象容量は小さくて1GB以下で３０分以内で終わるとは思いますが、性能の低いマシンで作業するユーザーではスケジュールを制御したいという要求があってもおかしくはありません。
また、スケジュール設定は「起動」のタイミングを規定するものと捉えるのではなくて、「起動」を禁止する時間帯を指定するものだと捕らえたほうが実態に即しているように思います。 指定期日時刻に起動するという設定を、前回実行終了時点から指定期日までは起動させないという設定だと捉えるとわかりやすいと思います。 即ち、指定時刻以降であれば実行される(アイドル時指定があれば、アイドルになるまでは実行されない)という指定です。 「このスキャンのスケジュールを設定しない」というのは、スキャンしないという指定ではなくて、禁止期間を設けないということでしょう。 即ち、初期のccsvcht抑制時間経過以降は禁止されない(=実行可能)で「アイドル時のみ」指定がある場合はアイドルになるまで待って開始、指定なしだと無条件開始ですね。 但し、何回も即座にスキャンを繰り返えすのは無駄で、パフォーマンスを損ねるだけなので、スキャン完了後の一定時間(多分半日だと思う)はスキャンが抑止されることになっているようです。 デフォルトの設定では、「スキャンスケジュール未設定」＆「アイドル時のみ」ですので、マシンを立ち上げて1時間ほど放置して、NISが定義する「アイドル状態」を持続して、その間のNIS2013の動きを観察してみると、バックグラウンド動作の抑止時間(デフォルトでは20分)が経過すれば、クイックスキャンが走り出すことが確認できます。
E3abc
25
ライちゃんは書きました。
「アイドルタイムスキャン（クイックスキャン）の実行中、マウスやキーボード操作を行うとスキャンを中止します。この場合、次回アイドル状態になった時に再度実行します。」
Symantecの説明でも、このように書かれていたと思いますが、正確にはこれは「ウソ」だと思います。
バックグラウンドスキャンは低い優先度(priority)で実行されているので、通常優先度のプロセスが出てくると、割り当てられるCPUタイムが小さくなって、動きが鈍くなっているだけなのです。 「マウス、キーボード操作で中止する」という表現は、一般的にはマウス割り込み、キーボード割り込みによってsignal()関数による分岐でprocessをexit()する内部構造を連想させますが、ccsvchtの活動を観察した限りでは、そのような作りになっている様には思えません。 確かにシングルコアの低性能マシンではスキャンされるファイルへのI/O(read)が途切れ途切れになって、I/Oアクセス間隔が数10秒にもなるので「中止」しているように見えます。 ８コアのマシンだと全体の性能そのものが高いので、GUI操作主体でリソース消費が少ないexcelなどのoffice系アプリを動かした程度ではバックグラウンドスキャンの稼働状況はさほど変化せず、priorityは低いものの、スキャンはちゃんと動き続けていることがわかります。 １CPUで10コア20スレッドのXeonも登場している昨今で、サーバー機だけでなくワークステーションや、ノートPCまでもがマルチコアが当たり前になってきていますので、Symantecも正確な表現で説明しておかないと、「ウソ」がばれて、信頼を失うのではないでしょうか？
E3abc
26
kawamoto76 様
こんにちは！ ライちゃんです。
＞「アイドルタイムスキャン（クイックスキャン）の実行中、マウスやキーボード操作を行うとスキャンを中止します。この場合、次回アイドル状態になった時に再度実行します。」
これは「本当」のことです。私が実際に実験した結果ですので間違いありません。
プログラムの動きが鈍くなっているとかスキャンを一時中断している訳ではなくて、完全にキャンセルされます。ノートンタスクの画面でスキャンの実行状況を確認できますが、スキャンを中止したことが確認できます。また、再度アイドル状態に移行した時に再実行することが確認できます。
※通常のアイドルタイムスキャン（クイックスキャン）の場合です。NIS2012の強制的にスキャンされるタイプは中断できません。
※Windows付属のツールを使い、ディスクI/Oも無くなるのを確認しています。
また、前回kawamoto76 様が投稿された「手動スキャンの実施実績はバックグラウンドスキャンのスケジュールに何の影響も及ぼさない」というのが、アイドルタイムスキャン（クイックスキャン）のことを指しているのでしたら、事実とは異なります。手動でクイックスキャンを行うと、アイドルタイムスキャン（クイックスキャン）の実行スケジュールに影響を及ぼします。こちらも実験により確認しています。
もうひとつ、他人の文章を引用して「ウソ」と発言するのはよくないと思います。もう少し表現に気をつけられた方が良いのではないでしょうか。
E3abc
27
「厳密正確には正しくない」ことを強調したかったので「ウソ」と書いてしまいました。 ご不快を感じさせたことをお詫びします。
＊windows付属のツールではプロセスごとのI/O頻度、i/oバイト量は調べられますが、どのファイルにアクセスしているかを調べることは出来ません。 バックグラウンドスキャンの挙動を調べるには、read/writeされているファイル名毎の頻度/プロセス名をリアルタイムモニターできるツールが必要です。
＊バックグラウンドスキャンの仕様については時々刻々バージョンによって変化していると思われ、また同一バージョンであってもOS種別が異なれば、動きが異なることが予想されます。 私も書き漏らしていましたが、情報提供では動作OS種別とNISバージョン(レビジョン)を併記することが必須です。 これら併記がないと他の環境での事態が自分のマシンでも当てはまるという誤認を犯してしまう危険性がありますので、以後気をつけたいと思います。
当方はVista64-ultimate上のNIS2013-20.4.0.40ですが、マウスクリックでバックグラウンドスキャンが中断しないことは簡単に確認できます。 ProcessExplorerでI/Oされているファイルのリストを表示しておいて、バックグラウンドスキャン(クイックスキャン)が走り出したことを確認し、Giga-LAN経由でマウントしたネットワークドライブから総量100GB超のファイルをC:以外の任意ドライブにコピーを開始して、ファイルI/Oを継続モニターします。ファイルコピー指示の操作でマウスがクリックされているので、Symantecが言うとおりであるならば、コピー指示のマウスクリックでバックグラウンドスキャンが停止するはずですが、相変わらず*.exeや*.dllのreadは継続しており、且つコピー速度がスキャン非走行時から大幅に低下してしまっている状態がスキャンが終了するまで続きます。 数分間のbusy状態継続を判断してスキャン禁止フラグを立てる仕組みがあるのかも知れませんが、あったとしても機能していません。 また、少なくともマウス／キーボード割り込みでの即時スキャン停止はしていません。 6GbpsのFSB帯域幅があるシステムなので、バックグラウンドスキャンが走っていない時には80-100MB/sec(全2重、ジャンボフレーム利用)のコピー速度が出ますが、バックグラウンドスキャンが走っていると速度が大幅に低下してしまい、高々20MB/sec程度にしかなりません。 100GBを100MB/sec転送だと20分弱で終わりますが、20MB/secだと1時間半かかってしまい、業務効率は大幅に低下します。 このコピーの例ではコピー対象ファイルを書き込むのは「system」であり、「explorer」が動作監視する状況になっていますので「サイレントモード」は使えず、バックグラウンドスキャンが終了するまでじっと我慢するしかありません。
コピープロセス自体ではDMA転送によるI/O占有率が高いもののCPU占有率は極めて低い状態であり、マウス/キーボード割り込みもない状態です。 普段の使用でもファイルコピー/転送中に、突然転送速度が低下し、調べてみるとファイルコピー/転送中であるにもかかわらずバックグラウンドスキャンが走り出したことを発見することがしばしばあることから、NISはこの大容量ファイル転送の実行状態を「busy」ではなくて「idle」と判定しているようです。
マルチコアワークステーションでは動画コーデックの変換処理時や科学技術計算実行時にはCPU利用率が90%を超えますが、
通常のファイル操作やofficeアプリ処理ではCPU利用率が20%を超えることは殆ど無いので、NISは起動時を除きマシンを常時
「idle」と判定してしまい、「busy」と判定することがないのかもしれません。
E3abc
28
kawamoto76 様
こんにちは！ ライちゃんです。
バックグラウンドスキャンという言葉を使いますと範囲が広く意味が違ってきますが、私が言っていたのはアイドル状態で自動的に行うクイックスキャンのことです。ヘルプを読みますとアイドルタイムスキャン（クイックスキャン）という呼称が使われています。
アイドルタイムスキャン（クイックスキャン）は、スキャン中にマウスやキーボードを操作すると中止します。kawamoto76 様がツールを使って確認された現象は、キーボード等の操作で中止しなかったとのことですから、アイドルタイムスキャン（クイックスキャン）ではありません。
考えられるのは、ノートンがファイルの監視のためにスキャンをしているか、または強制的に実行されるクイッククスキャンだと思います。ファイルの監視は、各種アプリケーションやOSが動作するときのスキャンですから停止することはできません。
強制的に実行されるクイックスキャン（強制クイックスキャン）はNIS2012の時に一時問題とされましたが、ノートンのインストール方法によって発生する場合があります。
強制クイックスキャンはNIS2011からNIS2012に上書きインストールした時に発生します。NIS ver.20をご利用とのことですが、NIS2011からNIS2012、ver.20と上書きインストールしているのならver.20でも発生するのかもしれません（ver.20での発生は未確認）。
強制クイックスキャンが実行されているかどうかの見分け方ですが、現象発生時にノートンタスクでクイックスキャンを実行しているかどうかで確認できます。実行した覚えの無いクイックスキャンが実行中でマウス、キーボードの操作で中断しないのであれば強制クイックスキャンです。
その現象が強制クイックスキャンでもファイルの監視でも無いという可能性はありますが、アイドルタイムスキャン（クイックスキャン）で無いことは間違いありません。
E3abc
29
ライちゃんさま。 たびたびの情報提供ありがとうございます。
情報提供では動作OS種別とNISバージョン(レビジョン)を併記することが必須です。 これら併記がないと他の環境での事態が自分のマシンでも当てはまるという誤認を犯してしまう危険性があります。
また、不具合解析や動作検証ではマニュアルの表記や画面に表示されるメッセージは「常に正しいわけではない」という前提で取り組む必要があり、マニュアルや画面表示にSelfConsistencyが失われている場合に、特定の記述部分を正しいものとして他の特定の部分の異常を疑う「先入観」も放棄して取り組むべきで、事実の積み上げがもっとも重要です。 アプリケーションの修正が完了して動作そのものは変更されているのだが、画面のメッセージやマニュアルの修正は未了という状況は、多くの市販アプリで日常的に目にしますので、ユーザーとしては「事実」を積み上げることにより、現時点での仕様書(これはどこにも存在しない)を頭中に描くことになります。
アプリケーションの性格上、アイドルタスクスケジューリングの詳細仕様を公開できないという事情にあるのだと思いますが、NIISの内部構造(設計仕様)やスケジューリング詳細機構が開示されていない現状は、パフォーマンス維持しての運用管理上、困ることが多いので、Symantecにも必要最小限の仕様開示をお願いしたいところです。