過去事例から学ぶ SharePoint パフォーマンス問題とその対策

過去事例から学ぶ

SharePoint パフォーマンス問題とその対策

Community Open Day 2012

荒川剛史日本マイクロソフト株式会社コマーシャルテクニカルサポートオフィスシステムサーバーサポートエスカレーションエンジニア

Agenda

• 過去事例の紹介その１「SQL ブロッキング問題」

• 過去事例の紹介その２「セキュリティクロール問題」

• 問題を未然に防止するための Tips

過去事例の紹介その１

SQL ブロッキング問題

ある日の朝・・・

• 社長：いつものように役員向けのサイトを開いたら、真っ白なページのまま固まってしまった！

• 管理者：複数のユーザーで同様の事象が報告されているようです。・・・想定外です。

想定される原因

• ハードウェア障害

• ネットワーク障害 (通信、DNS 等)

• 認証の問題 (DC 障害等)

• IIS 障害 (w3wp.exe)

• カスタムソリューション (Web パーツ等)

• SQL Server 障害 (デッドロック、ブロッキング等)

問題の切り分けポイントについて考える

SQL ブロッキングの問題

• 一般的にパフォーマンス問題の原因となる可能性が最も高い

• ユーザーのオペレーションとデータ量に依存

• 一度に大量のレコードに対して更新を行うような処理 (ワークフローや SharePoint 内部動作) に注意

問題の傾向

SQL ブロッキングの問題ロックエスカレーションの仕組み

SQL Server

SQL ステートメント

大量の行ロックを生成


SQL Server


テーブルロックにエスカレーション


SQL Server



メモリの節約


SQL Server



後続の処理

ロック解除まで待たされる (ブロッキング)


• デッドロックとは異なりブロック元の処理の完了を待てばいずれは利用可能

• SQL Server 側でデッドロックが検出されない為ロールバックされない

デッドロックとの違い


• ブロックの要因となり得る処理を中断する

• IIS リセット

• タイマーサービスの再起動

• トレースフラグ 1224 の設定

実際に発生した場合の対処


ロックエスカレーションの条件

• 使用メモリ (既定：データベースエンジンによって使用されるメモリの 24%)

• ロックの数 (既定：1テーブルで 5000 個のロック)

詳細については以下の資料参照

ロックエスカレーションの仕組み

MSDN ライブラリ：ロックのエスカレーション (データベースエンジン) http://msdn.microsoft.com/ja-jp/library/ms184286(v=SQL.105).aspx


1) [Microsoft SQL Server 2008] -> [構成ツール] -> [SQL Server 構成マネージャ]を起動します。

2) SQL Server のサービス -> SQL Server (MSSQLSERVER) を右クリックし、プロパティを開きます。

3) 詳細設定タブ -> 起動時のパラメータの先頭に、次の文字列を追加します。

-T1224;

4) OK を押して完了します。

5) SQL Server を再起動します。

トレースフラグ 1224 の設定

MSDN ライブラリ：トレースフラグ (Transact-SQL) http://msdn.microsoft.com/ja-jp/library/ms188396(v=sql.105).aspx


• 一つのリストに格納するアイテム数を制限する (≦ 5000 件目安)

• 一度に大量のアイテムを更新するワークフローを実装しない

• 大量のデータを扱うときはアーカーブ用のサイトとデータ更新用のサイトを分ける

• サイトコレクションごとにコンテンツデータベースを分割する

問題を未然に防止するための対策

TechNet ライブラリ：大きなリストを設計し、リストのパフォーマンスを最大限に高める (SharePoint Server 2010) http://msdn.microsoft.com/ja-jp/library/ms188396(v=sql.105).aspx


Demo

過去事例の紹介その２

セキュリティクロールの問題

ある日の午後・・・

• 社長：今朝自分が投稿した社長ブログの記事が検索結果にヒットしない。どうなってるんだ！！

• 管理者：本来であれば1時間程度で完了するはずの増分クロールに10時間以上かかっています。・・・想定外です。

想定される原因

• クロール停止 (プロパゲート失敗、インデックス破損、検索サービスハング等)

• ネットワーク障害 (プロキシタイムアウト等)

• フルクロール (コンテンツ DB アタッチ、デタッチ)

• 既知の不具合 (KB956056, KB930887 等)

• セキュリティクロール

問題の切り分けポイントについて考える


• 一般的に増分クロールパフォーマンス問題の原因となる可能性が最も高い

• ユーザーのオペレーションとデータ量に依存

• コンテンツ量が多く、SharePoint サイトの権限変更を頻繁に行う環境では要注意

問題の傾向

セキュリティクロールの問題セキュリティクロールの仕組み


アクセス権が親から継承されたコンテンツ


親のアクセス権の変更


継承されたアクセス権も変更される


変更されたコンテンツのアクセス権情報のみを内部クロール


• 検索管理画面から見たとき、クロールのステータスが「増分クロール中」となっている。

• mssearch.exe プロセスを見る限り、CPU 使用率は変動しているのでどうやら動作しているように見える。

• クロールログを見ても殆ど何も更新されていないように見える。

• IIS ログでクローラーがコンテンツを取得した形跡が無い。

現象発生時の特徴


• パフォーマンスカウンタの確認

• クロール履歴の確認

• 診断ログの確認

クロールが正常に動作しているかの判断


パフォーマンスカウンタの確認

• Office Server Search Gatherer オブジェクト

• Document Entries カウンタ

• Documents Successfully Filtered カウンタ

※MOSS 2007 では Office Server Search Gatherer オブジェクトの Document Entries カウンタおよび Documents Successfully Filtered カウンタ



パフォーマンスカウンタの確認



クロール履歴の確認



診断ログの確認

--- 診断ログの例 ---

04:21.0 mssearch.exe (0x092C) 0x09A8 Search Server Common GathererSql 0 Medium CGatherer::CommitTransaction succeeded, URL sts3://site/siteurl=/siteid={ee7f629c-a36c-4327-b5f1-0652878fa4a3}/weburl=docs/webid={ba2b56ba-27d1-4cfb-90b4-e638d3f3b0ed}/listid={4d587236-3886-440f-a0d7-0d33622724cd}/folderurl=/itemid=27, CrawlID 51, SourceDocID 229 - File:d:¥office¥source¥search¥search¥gather¥server¥gatherobj.cxx Line:9449

------

※既定では上記ログは出力されないため、サーバーの全体管理の診断ログの設定において「MS Search 詳細トレース」のトレースログのレベルを「中」に変更する必要がある。


TechNet ブログ：セキュリティクロールについて http://blogs.technet.com/b/sharepoint_support/archive/2011/10/14/3459245.aspx


• アクセス権の付与を AD グループ経由で実施する

• コンテンツソースを分割して異なるスケジュールでクロールする

• 大量のデータを扱うときはアーカーブ用のサイトとデータ更新用のサイトを分ける

問題を未然に防止するための対策

TechNet ライブラリ：クロールとフェデレーションの計画を立てる (SharePoint Server 2010) http://technet.microsoft.com/ja-jp/library/cc262926.aspx


Demo

まとめ

問題を未然に防止するために

問題を未然に防止するために運用環境における潜在的な問題を探る

ベストプラクティスに沿ったキャパシティプランニング

ユーザー数

コンテンツに加える変更とその影響

ハードウェア性能

パフォーマンスベースライン

コンテンツ量


- OS 全般

• Memory

• Process

• Processor

• System

• PhysicalDisk

• Network Interface

• Server

標準パフォーマンスカウンター

- SharePoint 関連

• OSS Search Gatherer

• OSS Search Gatherer Database

• ASP.NET

• ASP.NET Applications

• .NET CLR Memory

- SQL Server 関連

• SQLServer:Buffer Manager

• SQLServer:Memory Manager

• SQLServer:Databases

• SQLServer:SQL Statistics

• SQLServer:General Statistics


• 1コンテンツDBあたり200GBを目安にする =>これを超える場合はデータを適度に静的に維持するよう心掛ける

• 一つのリストに5000件を超えるアイテムを格納しない =>これを超える場合は一度に大量のコンテンツに対する変更を加えないように工夫する

• コンテンツのアクセス権に 1000 を超えるユーザー、グループを付与しない =>可能な限り AD グループを経由してアクセス権を付与するように工夫する

コンテンツ量のガイドライン


• コンテンツ量が多い環境では事前にトレースフラグ 1224 の設定を検討する

• アーカイブサイトの活用 =>データが静的に維持されるアーカイブサイトを計画する

• コンテンツソースを適切に分割する =>サイトコレクション単位で分割が可能

運用のガイドライン

問題を未然に防止するために参考資料

Technet ライブラリ：SharePoint Server 2010 の容量管理: ソフトウェアの境界と制限 http://technet.microsoft.com/ja-jp/library/cc262787.aspx Technet ライブラリ：パフォーマンスと容量のテスト結果と推奨事項 (SharePoint Server 2010) http://technet.microsoft.com/ja-jp/library/ff608068.aspx Technet ライブラリ：パフォーマンスと容量に関する技術的なケーススタディ (SharePoint Server 2010) http://technet.microsoft.com/ja-jp/library/cc261716.aspx Technet ライブラリ：SharePoint 2010 による数テラバイトのコンテンツデータベースの管理 (ホワイトペーパー) http://technet.microsoft.com/ja-jp/library/hh307867.aspx

ある日の夕方・・・

• 社長：今日は色々とトラブルが起きたが、今後はこのような事が無いよう、きちんと対策するように。・・・じゃ、とりあえず飲みに行く？

• 管理者：・・・想定外です。

Q&A

Q&A

Thank you!!

ありがとうございました！！ご意見、ご感想、その他ご不明点はこちらまで！！

tarakawa＠microsoft.com

想定外のご相談もOK!!