none
demigrator.exeを一時的に停止できる? RRS feed

  • 質問

  • 初めまして。

    タイトルの通り、demigrator.exeを一時的に停止すると何か問題が起きますでしょうか?

     

    実はTV番組の録画データをREGZAからWHSへ移動する時、demigrator.exeが1時間おきにゴリゴリ始まってしまい、転送が追いつかずREGZA側で「周辺機器にエラーが発生したため移動を中止しました」とメッセージを表示して完了しないのです。

     

    ネットワーク利用率はデータ移動中、通常3~4%程度なのですが他のプログラム(この場合、demaigrator.exeだけでなくqsm.exeなども含む)が走ると(CPU使用率が30~70%)ネットワーク利用率が一瞬ドロップする状態が現れます。demigrator.exe以外のプログラムでもこのドロップは見られますがエラー終了までは至りません。

     

    もちろんdemaigrator.exeは1時間おきなので、それまでに移動完了できる短時間の番組データは問題なく移動できます。また、長編(2時間番組など)でも、地デジ録画データなら何とかエラーにならず終了する時もありますが、WOWOWなどのHDデータは必ずdemigrator.exeに邪魔されエラー終了になります。

     

    以前、INTEL製イーサネットアダプターを使用していたときはこんなエラーは発生しておらず、現在使用しているRealtek製イーサネットアダプターの性能と評判がイマイチなのは何となく判ってるのですが、何とかならないものかと思いまして・・・

     

    demigrator.exeをこの移動の間だけ停止しても問題ないものか、または他に原因となるものがありそうか、是非お助け下さい。よろしくお願いします。

     

    M/B: ZOTAC G43-ITX

    Memory: 4GB

    HDD: HD203WI、HD154UI、WD20EARS

     

    イーサネットはRealtek PCIe GBE Family Controllerで、Realtekのサイトに最新のServer2003用ドライバがあったのでそれを当ててみましたがダメでした。

    2010年7月21日 1:46

回答

  • 以前、INTEL製イーサネットアダプターを使用していたときはこんなエラーは発生しておらず、現在使用しているRealtek製イーサネットアダプターの性能と評判がイマイチなのは何となく判ってるのですが、何とかならないものかと思いまして・・・

      DEMigrator.exeプロセスによるパフォーマンスの低下の大半はディスクIO負荷によるものなので、Intel製のNICを利用していた場合に起きなかったということが個人的には疑問ですが、もしもそれが正しいとするならばDEMigrator.exeプロセスを停止させることを考慮するよりもIntel製のNICを利用したほうが早道に思います。
    もっと申し上げると、DE管理下のHDD(サーバーの記憶域)ではなく、DE管理外の(サーバーの記憶域に追加しない)HDDを用意してそれを共有したほうがずっとシンプルかと思います。

     DEMigrator.exeプロセスによるディスクI/O負荷の影響については、WHSを録画サーバーとして利用したい方を中心に以前から問題となっていますが、このプロセスを停止することはドライブエクステンダーの機能の一部を停止することとなるため、推奨しません。

      あくまで私見ですが、1時間毎に実施されているDEMigrator.exeプロセスを時折停止させるくらいであれば、DEへのクリティカルな影響にはならないのではないかと推測します。24時間以上継続して実施できないと、確実にファイルの競合エラーの原因となります。
    (停止させる機能は当然WHS側には用意されていませんので、具体的に停止させる場合には手動またはご自身でスプリクトを書く等対処が必要かと思いいますが、そこはご自身で対処してください)

      参考までに、このDEMigrator.exeプロセス等によるサーバーの記憶域のパフォーマンスに関する問題は、Vailに搭載されるDE V2では改善される予定です。

    2010年7月21日 13:37
    モデレータ
  •     お世話になっております。

    ただ、このM/Bを使用している頃は何度もREGZAから録画番組をムーブさせたり直接録画先に指定しているのに一度も今回のようなエラーが発生していないのは本当なんです!!今回はまだ直接録画は試していませんが・・・

     このドライブIO負荷はM/Bによってそれほど違いがあるものなのでしょうか?コントローラの性能の違いなのでしょうか?それともHDDの性能の違いでしょうか?
    素人考えでは明らかにD945GCLF2よりG43-ITXの方がCPU処理能力も含め全てにおいて性能は良いように思えてしまうのですが・・・
    ひょっとすると、HDDが増えた為にIO負荷が高くなるか高負荷状態が長く続く事が原因でしょうか?

      これはWOWOWなどのHDデータも含めてエラーが発生しなかったのでしょうか?
    NIC、ディスクIO、CPU、マスストレージコントローラー等々要素が多数あるため、どこがあるいは複数要素の組み合わせでどれとどれがボトルネックとなっているかは断定はこの段階では不可能です。
      たとえば考えられる要素として一つ例をあげると、サーバーの記憶域にWDのCaviar Greenシリーズの2TB HDDが追加されているようですが、これはジャンパまたはAlign Toolを適用するなどのAdvanced Format対策は実施されていらっしゃるのでしょうか?仮に対策を実施していないとすると、このHDDのパフォーマンスがサーバーの記憶域全体のパフォーマンスを引き下げている可能性も想定されます。
      

    この場合、DE管理外のHDDの共有は通常行う共有手順と同じでよろしいのでしょうか?

     

      "通常行う共有手順"とは、WHSでコンソールから共有フォルダを作成することを指していますか?
    それとも、WHS以外の一般的なWindowsクライアントやWindows Serverで共有フォルダを作成することを指していますでしょうか?DEの管理外ですから、前者は不可能で、後者ならば(推奨外の操作となりあくまで自己責任のもととなりますが)可能です。
    現在はWHSコンソールにてREGZA専用フォルダを作成し、ユーザーでGuestアカウントを有効にしてそのフォルダにアクセス権を与えているのですが、このGuestアカウントの有効化はDE管理外の共有フォルダにも有効なのでしょうか?
      "Guestアカウントの有効化"という言葉を正しく解釈するならばアカウントに対する行為ですから有効ですが、共有フォルダにGuestアカウントのアクセス権を設定するという意味でお使いでしたら、DEの管理外ですから不可能です。

    コンソールからは当然DE管理外の共有フォルダのアクセス権は設定できませんよね?

       ご認識の通りです。

     

    直接コントロールパネルからユーザーアカウントを触っても大丈夫なのでしょうか?

      "Guestアカウントの有効化"自体はWHSコンソールから可能ですから、コントロールパネルからユーザーアカウントを触る必要はありません。ユーザーアカウントを操作することは、もっともやってはいけないことの一つです。
      必要となるのはDE管理外のHDD上に対して、Windowsエクスプローラー上から共有フォルダを作成し適切なアクセス権を設定するということです。

      そもそもWHSにリモートデスクトップ接続をして操作をすること自体がサポート外です。この点はよく認識して頂きたく存じます。
    特定のプロセスを停止するという行為よりは、DE管理外のHDDを用意して共有フォルダを作成するほうが同じ推奨外の行為とはいいつつも、リスクは遥かに小さくなるかと思います。

    2010年7月22日 13:51
    モデレータ

すべての返信

  • 以前、INTEL製イーサネットアダプターを使用していたときはこんなエラーは発生しておらず、現在使用しているRealtek製イーサネットアダプターの性能と評判がイマイチなのは何となく判ってるのですが、何とかならないものかと思いまして・・・

      DEMigrator.exeプロセスによるパフォーマンスの低下の大半はディスクIO負荷によるものなので、Intel製のNICを利用していた場合に起きなかったということが個人的には疑問ですが、もしもそれが正しいとするならばDEMigrator.exeプロセスを停止させることを考慮するよりもIntel製のNICを利用したほうが早道に思います。
    もっと申し上げると、DE管理下のHDD(サーバーの記憶域)ではなく、DE管理外の(サーバーの記憶域に追加しない)HDDを用意してそれを共有したほうがずっとシンプルかと思います。

     DEMigrator.exeプロセスによるディスクI/O負荷の影響については、WHSを録画サーバーとして利用したい方を中心に以前から問題となっていますが、このプロセスを停止することはドライブエクステンダーの機能の一部を停止することとなるため、推奨しません。

      あくまで私見ですが、1時間毎に実施されているDEMigrator.exeプロセスを時折停止させるくらいであれば、DEへのクリティカルな影響にはならないのではないかと推測します。24時間以上継続して実施できないと、確実にファイルの競合エラーの原因となります。
    (停止させる機能は当然WHS側には用意されていませんので、具体的に停止させる場合には手動またはご自身でスプリクトを書く等対処が必要かと思いいますが、そこはご自身で対処してください)

      参考までに、このDEMigrator.exeプロセス等によるサーバーの記憶域のパフォーマンスに関する問題は、Vailに搭載されるDE V2では改善される予定です。

    2010年7月21日 13:37
    モデレータ
  •   DEMigrator.exeプロセスによるパフォーマンスの低下の大半はディスクIO負荷によるものなので、Intel製のNICを利用していた場合に起きなかったということが個人的には疑問ですが、

     ださっち様の言う通りでした・・・

     以前使用していたM/BがINTELのD945GCLF2でしたので、てっきりINTEL製NICであると思い込んでいたようです。改めて調べてみたらこちらもRealtekでした、お恥ずかしい限りです。

     ただ、このM/Bを使用している頃は何度もREGZAから録画番組をムーブさせたり直接録画先に指定しているのに一度も今回のようなエラーが発生していないのは本当なんです!!今回はまだ直接録画は試していませんが・・・

     このドライブIO負荷はM/Bによってそれほど違いがあるものなのでしょうか?コントローラの性能の違いなのでしょうか?それともHDDの性能の違いでしょうか?
    素人考えでは明らかにD945GCLF2よりG43-ITXの方がCPU処理能力も含め全てにおいて性能は良いように思えてしまうのですが・・・
    ひょっとすると、HDDが増えた為にIO負荷が高くなるか高負荷状態が長く続く事が原因でしょうか?

            以前の構成      →      今回の構成
    M/B:     D945GCLF2              G43-ITX
    CPU:     Atom330                        Pentium DC E6500
    mem:            2G                                       4G
    HDD:        HD154UI X 2                    HD203WI(SYS) X 1
                                                             WD20EARS X 1
                                                               HD154UI X 2

    結果としては、ださっち様が仰るようにDE管理外のHDDを共有させるのが一番シンプルなのかもしれません。(そもそもムーブや直接録画した番組はファイル容量が大きいので複製をしない設定にしてますので)

    この場合、DE管理外のHDDの共有は通常行う共有手順と同じでよろしいのでしょうか?
    現在はWHSコンソールにてREGZA専用フォルダを作成し、ユーザーでGuestアカウントを有効にしてそのフォルダにアクセス権を与えているのですが、このGuestアカウントの有効化はDE管理外の共有フォルダにも有効なのでしょうか?
    コンソールからは当然DE管理外の共有フォルダのアクセス権は設定できませんよね?直接コントロールパネルからユーザーアカウントを触っても大丈夫なのでしょうか?

    質問ばかりで申し訳ありませんが、宜しくお願い致します。

    2010年7月22日 1:50
  •     お世話になっております。

    ただ、このM/Bを使用している頃は何度もREGZAから録画番組をムーブさせたり直接録画先に指定しているのに一度も今回のようなエラーが発生していないのは本当なんです!!今回はまだ直接録画は試していませんが・・・

     このドライブIO負荷はM/Bによってそれほど違いがあるものなのでしょうか?コントローラの性能の違いなのでしょうか?それともHDDの性能の違いでしょうか?
    素人考えでは明らかにD945GCLF2よりG43-ITXの方がCPU処理能力も含め全てにおいて性能は良いように思えてしまうのですが・・・
    ひょっとすると、HDDが増えた為にIO負荷が高くなるか高負荷状態が長く続く事が原因でしょうか?

      これはWOWOWなどのHDデータも含めてエラーが発生しなかったのでしょうか?
    NIC、ディスクIO、CPU、マスストレージコントローラー等々要素が多数あるため、どこがあるいは複数要素の組み合わせでどれとどれがボトルネックとなっているかは断定はこの段階では不可能です。
      たとえば考えられる要素として一つ例をあげると、サーバーの記憶域にWDのCaviar Greenシリーズの2TB HDDが追加されているようですが、これはジャンパまたはAlign Toolを適用するなどのAdvanced Format対策は実施されていらっしゃるのでしょうか?仮に対策を実施していないとすると、このHDDのパフォーマンスがサーバーの記憶域全体のパフォーマンスを引き下げている可能性も想定されます。
      

    この場合、DE管理外のHDDの共有は通常行う共有手順と同じでよろしいのでしょうか?

     

      "通常行う共有手順"とは、WHSでコンソールから共有フォルダを作成することを指していますか?
    それとも、WHS以外の一般的なWindowsクライアントやWindows Serverで共有フォルダを作成することを指していますでしょうか?DEの管理外ですから、前者は不可能で、後者ならば(推奨外の操作となりあくまで自己責任のもととなりますが)可能です。
    現在はWHSコンソールにてREGZA専用フォルダを作成し、ユーザーでGuestアカウントを有効にしてそのフォルダにアクセス権を与えているのですが、このGuestアカウントの有効化はDE管理外の共有フォルダにも有効なのでしょうか?
      "Guestアカウントの有効化"という言葉を正しく解釈するならばアカウントに対する行為ですから有効ですが、共有フォルダにGuestアカウントのアクセス権を設定するという意味でお使いでしたら、DEの管理外ですから不可能です。

    コンソールからは当然DE管理外の共有フォルダのアクセス権は設定できませんよね?

       ご認識の通りです。

     

    直接コントロールパネルからユーザーアカウントを触っても大丈夫なのでしょうか?

      "Guestアカウントの有効化"自体はWHSコンソールから可能ですから、コントロールパネルからユーザーアカウントを触る必要はありません。ユーザーアカウントを操作することは、もっともやってはいけないことの一つです。
      必要となるのはDE管理外のHDD上に対して、Windowsエクスプローラー上から共有フォルダを作成し適切なアクセス権を設定するということです。

      そもそもWHSにリモートデスクトップ接続をして操作をすること自体がサポート外です。この点はよく認識して頂きたく存じます。
    特定のプロセスを停止するという行為よりは、DE管理外のHDDを用意して共有フォルダを作成するほうが同じ推奨外の行為とはいいつつも、リスクは遥かに小さくなるかと思います。

    2010年7月22日 13:51
    モデレータ
  • ださっち様

    回答有難うございます。
    以前D945GCLF2を使用している時はWOWOWのHDデータを含め、直接録画、ムーブ共に問題ありませんでした。

    と言うのも、WHSをアップグレードする為に以前D945GCLF2の頃に録画、ムーブしてあった番組データを一度別のPC(XP)に移動し、WHSをG43-ITXへアップグレードした後に再度PC(XP)→新WHSへ戻そうとしてのトラブルだからです。


    ちなみに、追加しているWD20EARSはジャンパで対処しています。

    昨晩DE配下のHDDを一つ解除し、管理外のHDD(Eドライブ)のまま共有しました。
    夜遅かったのでデータ移動はまだ試せていませんが・・・
    結果はまた報告させていただきます。

     

    2010年7月23日 2:06
  • お世話になります。

    週末に、WOWOWの2時間HD番組を含むいろいろなデータ(XP→WHS、NAS→WHS、USBHDD→WHS)をムーブしてみましたがエラーは発生しませんでしたので、このまま使用します。

    有難うございました。 また、何かに行き詰まった際には宜しくお願いいたします。

    2010年7月26日 2:58