locked
CPU、メモリ共に余裕の状態で、一瞬パフォーマンスが急に落ちる現象について RRS feed

  • 質問

  • ファイルサーバにある共有フォルダー内のファイルにクライアントPCからアクセス

    していると、CPU、メモリ共に余裕の状態にもかかわらず、パフォーマンスが急に

    落ちる事があります。具体的には、「共有フォルダーへのアクセスが、1~2秒程度

    無反応になります。(ファイルの書き込みや読み込みなど、アクセス行為全て)」
    この現象は、不定期に発生します。


    原因の調査中で、IndexServiceを停止しましたが、効果を得ませんでした。
    タスクマネージャーを確認しても特別高負荷のものは見当たりません。

    何かご存知の方がいらっしゃれば、教えて頂きたくお願い致します。

     

    環境
    OS:Windows 2003 Server R2 SP2
    MM:1G
    CPU:Xeon1G
    Disk:50G
    サーバはファイルサーバとしてのみ利用
    アクティブディレクトリ配下

    2007年12月26日 3:46

回答

  • 御世話になっております。

    私が、共有アクセスの内部的な動作をよく分かっていないので、参考になるレスでは

    ありませんが;w;

     

    ・ 既定で15分経つとセッションがタイムアウトするので、再接続までの時間

    ・ ログイン資格情報の確認時間

    ・ ディレクトリやファイル一覧を取得するための時間

    ・ クライアントにファイルを転送するための時間

    ・ サーバ側の優先処理のために待たされる時間

     

    などが待ち時間になると思っております。

    他にもあるかもしれませんが、どこで時間がかかっているのか切り分けたいですね。

     

    どう調べるかが難題だと思いますけど><

     

    思いつくのは15分以上間隔をあけた場合に遅いのか、それとも、こまめにアクセス

    しているにもかかわらず、不定期に遅くなる場合があるのか、といったところですね。

     

    以下は個人的にも試した経験がないのですが、

    クライアント側にネットワークモニタ(またはWireshark等のパケットキャプチャソフト?)

    をインストールしてみて、パケットのタイムスタンプで間隔が空いている部分を見つけて

    転送中に中断しているのか、資格情報や接続処理で時間がかかっているのか、

    分かるかもしれませんが、見方が??です。。

     

    あまり参考にならないレスでごめんなさい。

     

    2007年12月27日 0:48
  •  

    ちなみにハードウェアはどのような構成でお使いでしょうか?

    過去に私の経験のある事例としましては

    1.broadcom のネットワークカードを使用している場合

    2.SASのコントローラ、およびHDDのファームウェアの問題(SASの構成の場合)

    などがありました。

     

    1.の場合の回避策としては

    設定で Large Send Offload の設定を Enable から disable に変更

    または

     

    http://support.microsoft.com/kb/942861/ja

     

    などに記載の方法があるかと思います。

     

    2.の場合は

    SASのコントローラのファームウェアのアップデートとHDDのファームウェアのアップデートなどが

    必要と思われます。

    メーカ製のサーバなどでしたらアップデータなどがhpなどに載っていればとりあえず最新のものにして

    動作を確認してみてはいかがでしょうか

     

    ご参考になれば幸いです。

    2007年12月27日 15:10

すべての返信

  • 御世話になっております。

    私が、共有アクセスの内部的な動作をよく分かっていないので、参考になるレスでは

    ありませんが;w;

     

    ・ 既定で15分経つとセッションがタイムアウトするので、再接続までの時間

    ・ ログイン資格情報の確認時間

    ・ ディレクトリやファイル一覧を取得するための時間

    ・ クライアントにファイルを転送するための時間

    ・ サーバ側の優先処理のために待たされる時間

     

    などが待ち時間になると思っております。

    他にもあるかもしれませんが、どこで時間がかかっているのか切り分けたいですね。

     

    どう調べるかが難題だと思いますけど><

     

    思いつくのは15分以上間隔をあけた場合に遅いのか、それとも、こまめにアクセス

    しているにもかかわらず、不定期に遅くなる場合があるのか、といったところですね。

     

    以下は個人的にも試した経験がないのですが、

    クライアント側にネットワークモニタ(またはWireshark等のパケットキャプチャソフト?)

    をインストールしてみて、パケットのタイムスタンプで間隔が空いている部分を見つけて

    転送中に中断しているのか、資格情報や接続処理で時間がかかっているのか、

    分かるかもしれませんが、見方が??です。。

     

    あまり参考にならないレスでごめんなさい。

     

    2007年12月27日 0:48
  • こちらこそ、お世話になっております。

    早速のレスありがとうございます。

     

    > ・ 既定で15分経つとセッションがタイムアウトするので、再接続までの時間

    について試してみたのですが、現象を確認することができず、小気味良いレ

    スポンスで処理できてしまいました。

     

    こまめにアクセスしていてもこの現象は出ていたと記憶しています。

    不定期に発生するもので、条件をなかなか特定できないでいます。

     

    他の懸念事項についても、調査してみたいと思います。(難しそうですが…)

     

    今後とも、よろしくお願いします。

     

     

    2007年12月27日 3:20
  •  

    ちなみにハードウェアはどのような構成でお使いでしょうか?

    過去に私の経験のある事例としましては

    1.broadcom のネットワークカードを使用している場合

    2.SASのコントローラ、およびHDDのファームウェアの問題(SASの構成の場合)

    などがありました。

     

    1.の場合の回避策としては

    設定で Large Send Offload の設定を Enable から disable に変更

    または

     

    http://support.microsoft.com/kb/942861/ja

     

    などに記載の方法があるかと思います。

     

    2.の場合は

    SASのコントローラのファームウェアのアップデートとHDDのファームウェアのアップデートなどが

    必要と思われます。

    メーカ製のサーバなどでしたらアップデータなどがhpなどに載っていればとりあえず最新のものにして

    動作を確認してみてはいかがでしょうか

     

    ご参考になれば幸いです。

    2007年12月27日 15:10
  • こんにちは、フォーラム オペレータの鈴木裕子です。

     

    Kumaぽんず さん、great_kabukicho さん、

    大変参考になる投稿をありがとうございました!

     

    suraMetabo さん、

    その後いかがでしょうか。問題は解決されましたか?

    Kumaぽんず さん、great_kabukicho さんの投稿が、

    大変参考になる内容でしたので、回答済みチェックをつけさせて頂きました。

     

    回答済みチェックが付くことにより、有用な情報を探している方が情報を見つけやすくなります。
    問題解決につながる回答、参考になる回答があった場合は、

    なるべく回答済みボタンを押してチェックを付けてくださいね

     

    suraMetabo さんは設定を元に戻すこともできますので、もし不適切でしたら、修正をお願いいたします

    また何かありましたら、フォーラムの情報を参考になさってください

    2008年1月9日 2:49