SharePoint サーバーの突発的高負荷は統計情報の再作成で回復する、こともある

決して一般的な障害ではないものの、SharePoint 環境において、突然、データベースサーバが過負荷状態に陥りサービスダウンする、という問題が発生することがあります。この原因は直接のトリガは定かではないのですが、実例としての「解決策」だけは明確です。

この障害は、まったく予期できないタイミングで発生します。コンテンツデータベースのあるサーバの CPU 使用率が突然「天井」状態になり、そのため SharePoint が事実上サービスダウンします。一旦こうなってしまうと、なかなか回復できません。

しかし、いくつかの事例では明確な回復手段があります。

解決策:コンテンツデータベース(SQL)の統計情報の再作成を実行する

これで、魔法のように負荷がおちつきます。

統計情報(statistics)は SQL データベースがデータアクセスを効率化する為に自動的に作成するインデックスです。ある意味、データベースという仕組みの中核部分と言えるかもしれません。(注:私は SQL エンジニアではないため、適当な説明です)

例えば、コンテンツに非常に大きな変更(削除など)が加えられた場合、既存の統計情報ではアクセスが非効率になります。そこで、SQL サーバは自動的に統計情報を更新します。そのため、普段の運用でユーザーが統計情報を意識することはありません。

しかし…ここがよく判らないところのですが、統計情報がほぼ最新で、SharePoint のコンテンツにもほとんど変更が加えられていない筈の状況(例えば深夜に更新が行われた翌日の朝など)でも、この高負荷が発生することがあります(ありました)。

この原因については、かなり追求したのですが、どうしてもトリガーが判らず、残念ながら不明のままです。

SharePoint と統計情報に関して言えば、実は SharePoint 2010 はタイマージョブで定期的に統計情報を更新しています。そのため、SQl 側では統計情報の自動更新はオフに設定することが推奨されおり、既定でオフになっています。

一方、SharePoint 2007 にはこのタイマージョブがありません。そのため、こちらは SQL 側の機能に依拠していて、既定はオンです。

ところが、SharePoint 2007 も SP2 で統計情報を更新するタイマージョブが実装されました。すると、データベース(SQL)側とタイマージョブ(SharePoint)側で更新のバッティングが懸念されます。実際、タイマージョブ側を止めた、という話もあるようです。

参考:
Optimizing SQL for SharePoint
Storage and SQL Server capacity planning and configuration (SharePoint Server 2010)

もしこれが関係しているとすると「SP2 を適用した SharePoint 2007 環境」と「SharePoint 2007 からバージョンアップした 2010 環境」が危ないかもしれませんね。

その他の点としては(サンプリング数が少ないためあくまで皮膚感覚ですが)、コンテンツ(アイテムやファイル)が大量に登録されていて、かつあちこちに個別権限が設定されているサイトコレクション(を含むコンテンツデータベース)が危険であるような気がします。

皆さんの環境では如何でしょうか?もし同じような事例、あるいは関連した情報、あわよくば原因と解決策(笑)などありましたら、ぜひコメント頂けると嬉しいです。

追記:2012/9/30
SQL MVP の Masayuki Ozawa さんが 2010 について検証して下さいました。テーブル/クエリレベルまでの詳細な解説は必見です。
SEの雑記:SharePoint 2010 の Health Analyzer とデータベースのメンテナンスについて


Author

中村 和彦(シンプレッソ・コンサルティング株式会社 代表)が「ユーザ視点の SharePoint 情報」を発信します。元大手製造業 SharePoint 運用担当。現SharePoint コンサルタント。お仕事のお問い合わせはこちらまでお願いします。当ブログにおける発信内容は個人に帰属し所属組織の公式発信/見解ではありません。
Twitter : @saruhiko
FB : 中村 和彦
MS MVP SharePoint 2009/10-2011/9
MS MVP Office 365 2012/10-

FaceBook Activity