none
長時間運用について RRS feed

  • 質問

  • 以下の様なテーブルから、主キーを指定して
    100ms 毎に1件の検索するプログラムを作成しています。
    その他、100ms 毎に 以下を実施しています。
    ・更新処理 2回
    ・追加処理 1件

    20時間実施した時の、検索の平均時間は、
    0.45ms となるのですが、24時間経過後等、
    まれに検索時間が、100ms を超えることがあります。
    100ms を超えないようにしたいのですが、
    どの様な施策が考えられますでしょうか?
    また、原因となるような定期処理があれば、
    教えてください。




    環境
    サーバ
    Windows 2008 server standard SP1
    SQL Server 2008 Workgroup SP1

    クライアント
    Windows XP SP3

    開発ソフト
    Visual Studio 2008 SP1
    .net Framework 3.5 SP1


    テーブルの列

    create table Table01 (
     KEY_01 nvarchar(7) not null,
     ITEM_01 nvarchar(2),
     ITEM_02 nvarchar(8),
     ITEM_03 nvarchar(16),
     ITEM_04 nvarchar(20),
     ITEM_05 nvarchar(4),
     ITEM_06 nvarchar(60),
     ITEM_07 nvarchar(100),
     ITEM_08 binary (520),
     ITEM_09 binary (520)
      CONSTRAINT PK_KEY PRIMARY KEY CLUSTERED
      (
        KEY_01
      ),
    )
    Go
    2010年4月15日 2:26

回答

  • こんにちは、nagino です。

    既にご確認済みかもしれませんが、一般的に良くある話ですと、
     -1.ページ分割
     -2.統計情報の更新
     -3.データファイルの拡張
     -4.データキャッシュの更新
     -5.HDDのサーマルキャリブレーション
     -6.ネットワークのコリジョン
    などがあります。
    -1. はデータの特性に併せたクラスタ化インデックスを設計することで回避、-2. や -3. は DB 構築時の初期設定/設計で適切に対応するべきこと、-4. は本質的に不可避(最悪時のパフォーマンスが問題であれば -4. 発生時のパフォーマンスをベースに機器選定されているはず)ですので、稼動テストの段階で発生するようなものではありませんね。

    そういう意味では、M_Lewis 様がご指摘の内容が気になります。
    あとは -5. や -6. のような他要因が無いかも念のためご注意ください。

    ただ、PC サーバー自体がベストエフォートというか、負荷が無いときは最大限早く処理するという設計のアーキテクチャですので、最悪時のパフォーマンスを保障するというスタンスとはそもそも相容れないところはありますね。
    そのため SLA などでも測定値の 90% に対する要件を定義したりしますので・・・。

     


    MCITP(Database Developer/Database Administrator)
    • 回答としてマーク DoubleBurger 2010年4月16日 2:46
    2010年4月15日 13:55

すべての返信

  • 何か別の処理とバッティングしてるんじゃないですかね。サーバー側トレースをとってみて時間がかかるときは何に負担がかかっているのか(CPUとかI/Oとか)調べて、差がなければ同時に何かやってないか調べて、それもないなら他のプロセスがシステム リソースを使ってないか調べる、というのが定石でしょう。
    回答が得られたら、もらった回答の [回答済み] ボタンをクリックしてスレッドを回答済みにしましょう
    2010年4月15日 2:48
  • こんにちは、nagino です。

    既にご確認済みかもしれませんが、一般的に良くある話ですと、
     -1.ページ分割
     -2.統計情報の更新
     -3.データファイルの拡張
     -4.データキャッシュの更新
     -5.HDDのサーマルキャリブレーション
     -6.ネットワークのコリジョン
    などがあります。
    -1. はデータの特性に併せたクラスタ化インデックスを設計することで回避、-2. や -3. は DB 構築時の初期設定/設計で適切に対応するべきこと、-4. は本質的に不可避(最悪時のパフォーマンスが問題であれば -4. 発生時のパフォーマンスをベースに機器選定されているはず)ですので、稼動テストの段階で発生するようなものではありませんね。

    そういう意味では、M_Lewis 様がご指摘の内容が気になります。
    あとは -5. や -6. のような他要因が無いかも念のためご注意ください。

    ただ、PC サーバー自体がベストエフォートというか、負荷が無いときは最大限早く処理するという設計のアーキテクチャですので、最悪時のパフォーマンスを保障するというスタンスとはそもそも相容れないところはありますね。
    そのため SLA などでも測定値の 90% に対する要件を定義したりしますので・・・。

     


    MCITP(Database Developer/Database Administrator)
    • 回答としてマーク DoubleBurger 2010年4月16日 2:46
    2010年4月15日 13:55
  • 100msecの範囲での話しだと色々な待ちが考えられると思いますので

    どこに原因があるのか少しづつ切り分ける必要があると思います。

    ・サーバ側だけで処理した場合(network,clientの問題かどうか)

    ・検索にNOLOCKヒントを入れてみる(ロックの問題かどうか)

    ・統計情報の自動更新をOffにしてみる

    等々

     

    その他DMVで待ちの統計も調査してみてもよいかもしれません。

    http://msdn.microsoft.com/ja-jp/library/ms189741.aspx

    http://msdn.microsoft.com/ja-jp/library/ms179984.aspx

     

    2010年4月16日 0:15
    モデレータ
  • 頂いた情報を元に、頻繁に更新のかかる項目と
    そうでない項目を分割するなど、テーブル構成を見直しました。
    また、統計情報を更新しないようにしました。

    昨日から修正版を走らせて、35時間程度、100ms を
    超えることはないので、効果があったのだと思います。
    ありがとうございました。
    2010年4月16日 9:06