データベース管理は私の得意分野ではないので、いくつか質問があります。
これはすべて、私が見ているWebサイトのパフォーマンスに関連しており、かなりの時間を調査/診断に費やしてきました。
テストサイトとは対照的に、ライブサイトではページの読み込み時間がはるかに長いことに気付きました。
テストサイトの仕様は非常に低い-14GBのVPS 2仮想プロセッサRAMおよび同じVPSで実行されているSQL + Webサイト
ライブウェブサイトの仕様は、すべて8つの仮想プロセッサと16GB RAMを備えた4つの専用サーバーです。
ライブサイトでは、16個の仮想プロセッサと112GBのRAMを備えたSQL用に別の専用サーバーを使用します
Webサイトの平均同時ユーザー数は常に平均120人ですが、70から150まで変動する可能性があり、メールキャンペーンを送信すると、400に達する可能性があります。400に達すると、ユーザーのアクションによっては、CPUが100%に達する可能性があります。ウェブサイトでやっているのですが、RAMと同じぐらいうまくいきます。
実際のウェブサイトは実際にはテストウェブサイトよりもパフォーマンスが高いと思いますが、これは事実ではありません。私はコードを調べましたが、それはデータベースが原因であると強く信じています。バックアップ中のライブWebサイトのデータベースサイズは50GBを超え、テストサイトは4GBです。
両方のデータベースはかなり断片化されており、断片化がパフォーマンスにどの程度影響する可能性があるのでしょうか。
また、ライブWebサイトはテストサイトより何倍も大きいため、高い断片化はテストサイトよりもライブサイトのパフォーマンスに大きな影響を与えますか?
これは、productsテーブルのインデックスの1つのキャプチャです。
インデックスの再構築/更新に関するいくつかのヒントは何ですか?.
インデックスを再構築/更新している間、誰もテーブルを操作できないように、Webサイトをメンテナンスモードにする必要がありますか?
12個のインデックスと40000個の製品を含むテーブルでどれくらい時間がかかりますか?
ありがとう
あなたが提供したデータに基づいて-
合計67ページです。このような小さなテーブルのインデックスの断片化はパフォーマンスに影響しません。私はあなたが言及したテーブルのインデックスの断片化について心配しません。
SQLサーバーがより良いクエリプランを生成できるように、テーブル統計を更新する必要があります。
トラブルシューティングを開始する
読み取り: SQL Serverの断片化に関する心配をやめる
インデックスは、使用(時間)の過程でフラグメントにバインドされます。重要なのは、それがパフォーマンスに影響を与えているかどうかです。
通常、page_count <500のインデックスについては気にしません。(私たちのチームと同じですが)、特定のpage_countには厳格な規則はありません。以前のショップでは、Olaスクリプトに1000の制限を設定していました。ページ数。しかし、そうです。インデックスにpage_count = 67が指定されている場合、断片化は常に高い側にあります。
現在のpage_countでの断片化について心配する必要はありません。
以下のPaul Randalのブログ投稿をご覧ください。
テストサーバーとライブサーバーの主な違いはConcurrency
です。
テストサーバーでConcurrency
テストを実行していません。
Concurrency
は、Liveサイトが遅くなる主な理由の1つです。
あなたが接続文字列で書いたもののように、どのようなコードがフロントエンドアプリケーションで書かれています。 connection pool
と同様に、各トランザクションの後でconnection
が適切にclose
であるかどうか。これが、速度低下の主な理由です。
次に、フロントエンドコードの他の部分。
SPに書き込まれるクエリ。同時ユーザーによるdeadlock
の問題かどうか。
同時ユーザーが同じ行のセットを更新しようとする状況はありますか?レース状態をどのように処理しますか?
12 index
レコードのみの単一のテーブルに40000
があるのはなぜですか?
すべてのインデックスとともにテーブル構造をスローしてください。