• Toute la Communauté
    • Toute la Communauté
    • Forums
    • Idées
    • Blogs
Avancé

Pas ce que vous cherchiez ? Demandez aux experts !

Remerciements0

32bitOS上と64bitOS上で重さがぜんぜん違うNIS2013-20.3.1.22

(1)WinXP-Pro(32bit) Pentium-M(1GHz,シングルコア) MEM=1GB  NIS2013-20.3.1.22

(2)WinVista-Ultimate(64bit) Xeon-X5460×2(3.16GHz、全8コア) MEM=64GB NIS2013-20.3.1.22

NIS2013を導入した(1)レガシーな32bit低速ノートPCと(2)大容量メモリー搭載64bitの超高速ワークステーションとを比較してみました。 両機とも5月度のOSのWindowsUpdate適用済み、NISは自動LiveUpdate設定です。  (1)の32bit機はパワーON後10分程度で平穏安定状態になりメモリー使用量は250MB程度とNIS2012より使用メモリーが少なく、NIS2012のときと同等な応答速度でアプリケーションを動かせます。 NISのLiveUpdate時には何の不具合もありません。

  これに対し、(2)の64bit機では電源投入後、OSが立ち上がってからc:\ProgramData\Norton配下のファイルへのアクセスが続いており、平穏安定状態になるには2時間~3時間かかります。 NISはいったい何をしているのでしょうか。 加えて、shutdown時に電源が切れない(http://communityjp.norton.com/t5/forums/forumtopicpage/board-id/NIS_NAV/thread-id/3241)問題や、LiveUpdate後のエラーで以後のLiveUpdateが失敗しshutdown電源切断不可につながる(http://communityjp.norton.com/t5/forums/forumtopicpage/board-id/NIS_NAV/thread-id/3241)という問題があり、他にもMS-OfficeファイルScanが出来なくなったりします。 他のユーザーからも、Win-7/64bit、Win8/64bitでは不具合が多数報告されています。 また、NIS2012ではおきたことがありませんが、NIS2013に変えた後ではexplorerから動画ファイルを開こうとした際、「ファイルが見つかりません」と応答があり、しばらく待った後ではちゃんと同じファイルが開けるようになっていたことがありました。 別にアイドルスキャンが動いていたわけではなく、NIS2013を導入したというだけでファイルシステム操作のパフオーマンスが大きく阻害されているようです。 Vista-ultimate(64bit)ではccsvchst/Systemが各ドライブの管理ファイルをロックしている時間比率が余りにも高く、chkdsk*32の次回予約ですらロックが解除される時間帯を待たねばならないのでなかなか動けません。

こうなるともう32bitOS上のNIS2013と64bitOS上のNIS2013は別物として別けて考えなくてはなりません。

(1)(2)両機共にセキュリティの観点からCTRL+ALT+DELを押してユーザー名とパスワードの入力枠があるログオン画面を出して、ここにユーザー名とパスワードを入力してログオンするように設定しています。 低性能の(1)の場合、順序がわかりやすく、「ログオンするにはCTRL+ALT+DELを押してください」という画面(CTRL+ALT+DEL要請画面)が出てすぐにCTRL+ALT+DELを押してログオン画面を出してもすぐにはキーボード入力が受け付けられません。 結局はCTRL+ALT+DEL要請画面が出てから5分以上経過した時に受付可能になるようです。 受付可能になってからログオン画面を出してくれれば混乱しないのに。。。 NIS2012ではこのようなことは無く、ログオン画面表示直後から入力可能でしたが、NIS2012よりNIS2013が立ち上がり処理が重くなっていることは間違いないようです。 ( 他のユーザーからNISの製品アイコンの表示が遅いという投稿(http://communityjp.norton.com/t5/forums/forumtopicpage/board-id/NIS_NAV/thread-id/2141/page/2)がありましたが、やはり完全に立ち上がってから出してくれるほうがトラブルの種がなくなると思います。 )   高性能の(2)では(1)と同じ状況なのかも知れませんが、高速に並行処理できますので入力に問題はありません。 不可解なのは低性能の(1)で10分程度で終わるものが、なぜ数段高性能な(2)で2時間以上もかかってしまうのかです。 確かに(2)ではWindowsSerchやシャドウコピーなどの立ち上げ時backgroundがあり、その分手間取ることになりますがNIS抜きで確認するとVista64自体は30分もあれば平穏安定になるのです。

 現状で私は64bit機におけるshutdown不具合の原因推定の過程で以下の仮説を考えています。 NIS2013は立ち上がり時にパターンファイルデータベースとマシン上のユーザーのファイル群のスキャン履歴データベースの整合性チェックを行い、システム完全立ち上がり以後はユーザーのアプリ実行やLiveUpdateでのシンパターンファイルダウンロードによって都度これらデータベースを更新していって、且つこれらを参照してリアルタイム保護活動を行うが、Vista-ultimate(64bit)上ではこの初期の立ち上げ時の初期化処理が長時間を要した挙句、パターンファイルデータベース更新は成功するものの、スキャン履歴データベースは更新が失敗して終了し、データベース更新完了フラグは記録されない。 LiveUpdateでの新規パターンファイルダウンロード後の処理は(A)関連サービスの停止、(B)パターンファイルの更新、(C)サービスの再起動を行った後、パターンファイルデータベースの更新、パターン情報のスキャン履歴データベースへの反映処理を行うが、後者は失敗するものの、通常では前者は成功し、継続して新規LiveUpdateを受け取れる。 このとき、ccsvchstは「自殺可能」なので、shutdownでは正常に電源が切れるが、次回立ち上げた場合にはデータベース構築が最初からやり直しになるので、立ち上げるたびに毎回2~3時間ディスクアクセスが続くことになる。 32bitOS上では正常にデータベース構築されるので、次回からの立ち上がりも早いし、スキャンでの読み飛ばしなどが使えて、2012よりも快適に使えるのだが、64bitOS(少なくともVista-ultimate)上ではデータベース構築の毎回失敗によってデータベースの恩恵が受けられないだけでなく、システム安静までの完全立ち上がりに2~3時間かかってしまうという弊害が出ている。

何らかの要因でLiveUpdateの見かけ成功(上記(A)(B)(C)のみ正常終了)後にパターンファイルデータベース更新が失敗する場合は多分内部でループが発生していると思う。 このときにはパターンファイルデータベース更新処理が終わっていないので新規のLiveUpdateを受け取ることは出来ず、またループ発生によってccsvchstが「自殺不能」になっているので死ぬことが出来ず、shutdownは正常には完了しない。 「自殺不能」状態ではNortonFrameworkハングやOfficeファイルスキャン不能、メール受信不能のほか、Chatや電話相談時のNortonからの遠隔操作プログラムもインストールもできない事態になる。

shutdownで電源が落ちない事態になり、SW長押しで強制切断しても、次回立ち上げ時には「Windowsが正常終了しませんでした」という画面が出ることなく正常に立ち上がるのは、多分windowsの正常終了が記録された後の、shutdown最終段階でccsvchstが死ぬという順序になっていると思われる。 こう考えるとつじつまが合う。

Réponses

Remerciements0

Re: 32bitOS上と64bitOS上で重さがぜんぜん違うNIS2013-20.3.1.22

(1)WinXP-Pro(32bit) Pentium-M(1GHz,シングルコア) MEM=1GB  NIS2013-20.3.1.22

(2)WinVista-Ultimate(64bit) Xeon-X5460×2(3.16GHz、全8コア) MEM=64GB NIS2013-20.3.1.22

NIS2013を導入した(1)レガシーな32bit低速ノートPCと(2)大容量メモリー搭載64bitの超高速ワークステーションとを比較してみました。 両機とも5月度のOSのWindowsUpdate適用済み、NISは自動LiveUpdate設定です。  (1)の32bit機はパワーON後10分程度で平穏安定状態になりメモリー使用量は250MB程度とNIS2012より使用メモリーが少なく、NIS2012のときと同等な応答速度でアプリケーションを動かせます。 NISのLiveUpdate時には何の不具合もありません。

  これに対し、(2)の64bit機では電源投入後、OSが立ち上がってからc:\ProgramData\Norton配下のファイルへのアクセスが続いており、平穏安定状態になるには2時間~3時間かかります。 NISはいったい何をしているのでしょうか。 加えて、shutdown時に電源が切れない(http://communityjp.norton.com/t5/forums/forumtopicpage/board-id/NIS_NAV/thread-id/3241)問題や、LiveUpdate後のエラーで以後のLiveUpdateが失敗しshutdown電源切断不可につながる(http://communityjp.norton.com/t5/forums/forumtopicpage/board-id/NIS_NAV/thread-id/3241)という問題があり、他にもMS-OfficeファイルScanが出来なくなったりします。 他のユーザーからも、Win-7/64bit、Win8/64bitでは不具合が多数報告されています。 また、NIS2012ではおきたことがありませんが、NIS2013に変えた後ではexplorerから動画ファイルを開こうとした際、「ファイルが見つかりません」と応答があり、しばらく待った後ではちゃんと同じファイルが開けるようになっていたことがありました。 別にアイドルスキャンが動いていたわけではなく、NIS2013を導入したというだけでファイルシステム操作のパフオーマンスが大きく阻害されているようです。 Vista-ultimate(64bit)ではccsvchst/Systemが各ドライブの管理ファイルをロックしている時間比率が余りにも高く、chkdsk*32の次回予約ですらロックが解除される時間帯を待たねばならないのでなかなか動けません。

こうなるともう32bitOS上のNIS2013と64bitOS上のNIS2013は別物として別けて考えなくてはなりません。

(1)(2)両機共にセキュリティの観点からCTRL+ALT+DELを押してユーザー名とパスワードの入力枠があるログオン画面を出して、ここにユーザー名とパスワードを入力してログオンするように設定しています。 低性能の(1)の場合、順序がわかりやすく、「ログオンするにはCTRL+ALT+DELを押してください」という画面(CTRL+ALT+DEL要請画面)が出てすぐにCTRL+ALT+DELを押してログオン画面を出してもすぐにはキーボード入力が受け付けられません。 結局はCTRL+ALT+DEL要請画面が出てから5分以上経過した時に受付可能になるようです。 受付可能になってからログオン画面を出してくれれば混乱しないのに。。。 NIS2012ではこのようなことは無く、ログオン画面表示直後から入力可能でしたが、NIS2012よりNIS2013が立ち上がり処理が重くなっていることは間違いないようです。 ( 他のユーザーからNISの製品アイコンの表示が遅いという投稿(http://communityjp.norton.com/t5/forums/forumtopicpage/board-id/NIS_NAV/thread-id/2141/page/2)がありましたが、やはり完全に立ち上がってから出してくれるほうがトラブルの種がなくなると思います。 )   高性能の(2)では(1)と同じ状況なのかも知れませんが、高速に並行処理できますので入力に問題はありません。 不可解なのは低性能の(1)で10分程度で終わるものが、なぜ数段高性能な(2)で2時間以上もかかってしまうのかです。 確かに(2)ではWindowsSerchやシャドウコピーなどの立ち上げ時backgroundがあり、その分手間取ることになりますがNIS抜きで確認するとVista64自体は30分もあれば平穏安定になるのです。

 現状で私は64bit機におけるshutdown不具合の原因推定の過程で以下の仮説を考えています。 NIS2013は立ち上がり時にパターンファイルデータベースとマシン上のユーザーのファイル群のスキャン履歴データベースの整合性チェックを行い、システム完全立ち上がり以後はユーザーのアプリ実行やLiveUpdateでのシンパターンファイルダウンロードによって都度これらデータベースを更新していって、且つこれらを参照してリアルタイム保護活動を行うが、Vista-ultimate(64bit)上ではこの初期の立ち上げ時の初期化処理が長時間を要した挙句、パターンファイルデータベース更新は成功するものの、スキャン履歴データベースは更新が失敗して終了し、データベース更新完了フラグは記録されない。 LiveUpdateでの新規パターンファイルダウンロード後の処理は(A)関連サービスの停止、(B)パターンファイルの更新、(C)サービスの再起動を行った後、パターンファイルデータベースの更新、パターン情報のスキャン履歴データベースへの反映処理を行うが、後者は失敗するものの、通常では前者は成功し、継続して新規LiveUpdateを受け取れる。 このとき、ccsvchstは「自殺可能」なので、shutdownでは正常に電源が切れるが、次回立ち上げた場合にはデータベース構築が最初からやり直しになるので、立ち上げるたびに毎回2~3時間ディスクアクセスが続くことになる。 32bitOS上では正常にデータベース構築されるので、次回からの立ち上がりも早いし、スキャンでの読み飛ばしなどが使えて、2012よりも快適に使えるのだが、64bitOS(少なくともVista-ultimate)上ではデータベース構築の毎回失敗によってデータベースの恩恵が受けられないだけでなく、システム安静までの完全立ち上がりに2~3時間かかってしまうという弊害が出ている。

何らかの要因でLiveUpdateの見かけ成功(上記(A)(B)(C)のみ正常終了)後にパターンファイルデータベース更新が失敗する場合は多分内部でループが発生していると思う。 このときにはパターンファイルデータベース更新処理が終わっていないので新規のLiveUpdateを受け取ることは出来ず、またループ発生によってccsvchstが「自殺不能」になっているので死ぬことが出来ず、shutdownは正常には完了しない。 「自殺不能」状態ではNortonFrameworkハングやOfficeファイルスキャン不能、メール受信不能のほか、Chatや電話相談時のNortonからの遠隔操作プログラムもインストールもできない事態になる。

shutdownで電源が落ちない事態になり、SW長押しで強制切断しても、次回立ち上げ時には「Windowsが正常終了しませんでした」という画面が出ることなく正常に立ち上がるのは、多分windowsの正常終了が記録された後の、shutdown最終段階でccsvchstが死ぬという順序になっていると思われる。 こう考えるとつじつまが合う。

Accepted Solution
Remerciements0

Re: 32bitOS上と64bitOS上で重さがぜんぜん違うNIS2013-20.3.1.22

いまのところ、「20.3.0.40」 でやっと64bitでも「使える」アプリになったようだ。

20.3.0.40を5台のマシンに導入後、1日以上経過し、運用しているが、トラブルも無く快調に動作出来ています。 64bitOS上で発生しているさまざまの不具合が、一見、20.3.0.40でFIXされたようにも見えるのだが、諸々の不具合の各々についてのNIS2013-20.3.1.22での不具合発生原因の特定とその修復の報告がない以上、完全には解決されているとは言い切れない。 継続して、観察を続けることにする。 とわいえ、やっと64bitOSで使えるレベルになってきたと評価できる。

本フォーラム、またUSのフォーラムを見る限り、発売当初のNIS2013は64bitOS上では「余りにも不具合が多すぎて、使い物にならない」という悪評が高く、とりあえずNIS2012に戻してSymantecでの開発修正状況の様子を見るというユーザーが多かったように思われるが、今回の20.3.0.40のリリースでやっと使えるものになってきたようである。 「安静化時間」を立ち上げ処理が全て終わって、大半のバックグラウンド処理が終了し、タイマー起動が予約されているタスクは抱えるものの、ユーザーの指示待ち状態で、空回り状態となるのに要する時間と定義することにするが、NIS2013-20.3.1.22の場合、Win-Vista64では毎回の起動時における安静化時間が3時間程度かかっており、NISの管理用データベースが毎回立ち上げる毎に作り直されているとしか考えられない動きであったが、20.3.0.40に更新した後では安静化時間が初回こそ3時間程度ではあるものの、以後の立ち上げ時には30分~1時間程度になっており、前回構築済みの管理用データベースを継続使用することによって、安静化時間を短縮できるようになったことが確認できた。 やはり、NIS2013-20.3.1.22の64bitOS下使用では管理用データベースの構築が欠陥含みの不完全に終わっていたものと思われる。