SQLサーバーの同時実行パフォーマンス

本番環境でパフォーマンスの問題が発生しました。

アクティブセッションが25を超えると、CPUの使用率が100％に達し、停止するまでに長い時間がかかることがわかりました。

私たちが持っている環境：

製品Microsoft SQL Server Enterprise Edition 9.3（sp2）

CPU 2（Xeon 2.13）

メモリ7G

セッション詳細のスナップショット1

アクティブセッション 25

アクティブなトランザクション 496

アイドルセッション 289

ブロックされたトランザクション29

セッション詳細2のスナップショット

アクティブセッション 59

アクティブトランザクション 885

アイドルセッション 267

ブロックされたトランザクション49

知りたい：

1. 2CPUが25のアクティブセッション（500のアクティブトランザクション）を適切に処理できるかどうか。PS：同時実行要求なしで、5つのテーブルを読み書きする1つのトランザクションがアプリケーションレベルで約1秒かかることをテストしています。

2. ブロックされたトランザクションがより多くのCPU使用率をとるかどうか。PS：ブロックされたトランザクションは、主に2つのテーブルのロックが原因です。

解決策は何ですか：CPUを追加するか、アプリケーション（java / hibernate）を調整して、このトランザクションを短縮し、テーブルのブロックを減らしますか？

すべてがクロールしているときの状況を適切に把握するためのオプション：

• サーバー側のトレースを使用して、最も長く最も重いセッションを確認する
• Adam MachanicによるWho is Activeストアドプロシージャを使用する-サーバーが読み込まれた瞬間の情報を保存する-素晴らしい無料のスクリプト
• Management Studioのアクティビティモニターを使用して、視覚的に一目で確認します（CpuとIOは、私が最も有用であると判断したものです）-Management Studioに含まれている非常に優れたツール
• サードパーティの無料ツールであるConfio Ignite Freeを使用してください。これは、すべてが遅く、待機統計、ブロッキングなどの詳細を確認する必要がある場合に非常に適しています。-素晴らしい無料ツール
• 最新の統計をチェックします
• インデックスがフラグメント化されているかどうかを確認し、フラグメント化されている場合はデフラグします
• 欠落しているインデックスをチェックする他のアドバイスに従い、設計する
• データベースでスナップショット分離レベルを使用する可能性を確認します（ブロッキングが高いため、現在の分離レベルが本当に必要かどうかを確認することをお勧めします）

そして、問題を調査する幸運:-)。

あなたの問題は、以下の原因により、クエリのパフォーマンスが低い可能性が高い

• 貧弱なデザイン
• 不十分なインデックス

テーブルのスキャンにすべての時間が費やされているため、ロック/ブロッキングはインデックス作成が不十分であることが原因です。CPUはここでは無関係です。

簡単な修正として、この記事の情報を使用して、欠落しているインデックスを確認してください：http : //blogs.msdn.com/b/bartd/archive/2007/07/19/are-you-using-sql-s-missing- index-dmvs.aspx

GBNとマリアンに同意します。

25個のリクエストを処理する2 CPUに関する質問に答えるには、約750のユーザー接続と1秒あたりの4Kバッチリクエストの実行平均をサポートする2 CPUシステムがあります。いくつかの項目は私にとって重要です：設計、管理、およびチューニング。アプリケーションとデータベースの設計が悪い状態から始めると、ロードで失敗します（スケーリングを考える）。

CPU使用率が高い場合は、メモリが不足している可能性があります。SQL Serverが使用できるメモリは7 GBしかないとおっしゃっています。インデックスのパフォーマンスが低い（インデックスが多すぎる、インデックスが正しくない、またはインデックスがない）場合、適切なインデックスがある場合、システムはさまざまな要求のためにデータベースのメモリにページを追加します。インデックスを作成すると、行の更新（Create-Update-Delete）操作中に更新が必要になる可能性があるため、インデックスが間違っていると害を及ぼすので注意してください。

また、ミッシングインデックスDMVを使用するには、推奨される各インデックスを実装するだけでなく、アプリケーションとデータベースについて知っていることを使用する必要があります。ここで、インデックスに関するKimberly Trippのブログエントリをチェックアウトします。[インデックス]セクションの後で、他のカテゴリを確認すると役立つ場合があります。

1つのトランザクションで5つのテーブルのJava / Hibernate更新がデータベースへの複数のラウンドトリップを介して更新を実行している場合、競合（ブロックされたCRUD要求）にさらされています。アプリケーションがタイムリーにデータベースに戻ることができない場合、問題はさらに悪化します。アプリケーション内では、関連付けられたアクティブなトランザクションが他の要求の処理をブロックし、要求のタイムアウトを引き起こす可能性があります。

上記の2つの問題を一緒に追加すると、パフォーマンスの頭痛の厄介なケースが発生し始めます。

単一トランザクションのコンテキスト内でのデータベースラウンドトリップの数を減らすことは、追求すべき非常に良いことです。おそらく、ストアード・プロシージャーが役立ちます。

残りの部分では、アプリケーションをスケーリングするための作業が必要になります。また、メモリを検討することもできますが、それは設計とパフォーマンスのレビューが完了した後に行う必要があり、メモリをすぐに追加するために必要な変更を実装すると、問題が隠されます。

マリアンが概説した提案に絶対に従ってください。

私はあなたが自分自身に素晴らしい挑戦を見出し、あなたが大きな成功を収めることを望みます！

1. 私の経験では、2つのCPUと30を超えるアクティブセッションと1000を超えるトランザクションを備えたMS SQL Server 2000があります。サーバーするのは大変でしたが、うまくいきました。
2. ロックがより多くのCPUを使用するかどうかはわかりません。ロックとCPU使用率は、私の意見では、2つの異なるパフォーマンスの問題です。

解決策として、最初にあなたの主な問題がCPUであることを確認する必要があります。この問題を読んで問題の原因を見つけ、適切な解決策を見つけてください。Finnaly、あなたがあなたのトランザクションをできるだけ小さくすることができるなら-それをしてください。

私の最初の考えは、トランザクションの数を減らし、ブロッキングの量を減らすことです。一部のトランザクションを複数のビットに分割できますか？トランザクションからいくつかのクエリをプルできますか？Alex_lが述べたように、可能な限り最小のトランザクションがここでは理想的です。

私はGBNに同意します、インデックスを追加することも役立つかもしれません。

別の考えは、私もあなたのロックを見てみると思います。単一の行のみを更新しているときに、テーブルレベルのロックを解除していますか？SQL Serverに行レベルのロックを提案することを検討してください。それは多くの問題を解決します。（確かに、5つのテーブルがある場合、それはおそらく当てはまりませんが、単なる考えです。）

最後に、あなたが使用しているテーブルを見てみましょう。全員が特定のテーブルをブロックしている場合、そのテーブルのロジックをトランザクションの最後に移動できますか？その需要の高いテーブルでロックを保持する時間を短縮できる場合、それが役立ちます。