SharePoint Online の HTTP 調整 (応答コード 429) に関して

SharePoint Online は、データセンターの安定稼働のため、HTTP アクセスの一部をブロックして負荷調整する機能が備わっております。 SharePoint Online では、様々な利用者がファーム環境を共有しており、それぞれのお客様の利用状況に合わせて様々な HTTP 要求が送信されています。 サービス提供者の立場から、各利用者の利用状況や負荷状況の事前予測は不可能であり、個別に異なった運用対処もできません。このような予測しない高負荷が発生した際に、データセンターを守るための共通の基盤を用意する必要があります。 HTTP 調整は、上記背景のもとサービスの継続稼働のため、データセンター側の各種様々なパフォーマンス カウンタ値をもとに、HTTP アクセスに重みづけのルールを考慮して、高負荷と判断される際に優先度の低い HTTP 要求から受信直後・処理開始前にブロックし、負荷を自動調整 (縮退運転) するような設計で実装されています。 以下に例を記載します。データや指標などについては理解を促すための完全に恣意的なものです。 優先度 A の HTTP 要求は 15:00 のみにブロックされています。 優先度 B の HTTP 要求は 15:00 と 18:00 にブロックされています。 優先度 C の HTTP 要求は 12:00, 15:00, 18:00 にブロックされています。 優先度により、それぞれ異なったしきい値があるため、このように異なった結果になる例となります。   HTTP アクセスの優先度付けについて SharePoint Online への HTTP アクセスは重みづけされ、優先度が判断されます。 例えば、通常ブラウザー アクセス、JavaScript…

0

SharePoint Online で発行機能を有効にする場合の留意点

サイト コレクションの作成後に SharePoint Server 発行インフラストラクチャ/SharePoint Server 発行機能を有効にする場合、主にパフォーマンスの観点で以下のような留意すべき事項があります。 ・ナビゲーション ・ページ (Pages) ライブラリ   一般的に運用の開始後は設定や構成の変更が難しくなりますので、本稿の内容を構築の段階で考慮いただくことを、推奨いたします。   なお、サイト コレクションの作成時に、”発行ポータル” (英語: Publishing Portal) テンプレートを利用される場合は後述の内容は考慮された状態でサイト コレクションが作成されます。 このため、発行機能の利用を検討される場合は、サイト コレクションの作成時に、”発行ポータル” テンプレートを利用することもご検討ください。   ナビゲーション サイト コレクションの作成後に SharePoint Server 発行インフラストラクチャ機能を有効にすると、ナビゲーションに構造ナビゲーションが設定されます。 以下のブログ投稿でも紹介していますが、構造ナビゲーションを利用すると深刻なパフォーマンスの劣化が生じる可能性があるため、SharePoint Server 発行インフラストラクチャ機能を有効にした場合は、ナビゲーションを管理ナビゲーションに変更することが強く推奨されます。   タイトル : SharePoint Online のパフォーマンス チューニングについて アドレス : https://blogs.technet.microsoft.com/sharepoint_support/2018/06/25/spo-performance-tuning/   タイトル : SharePoint Online で管理ナビゲーションを使用する アドレス : https://blogs.technet.microsoft.com/sharepoint_support/2018/07/02/using-managed-navigation-in-sharepoint-online/    …

0

SharePoint Online のパフォーマンス チューニングについて

今回の投稿では、SharePoint Online のパフォーマンス チューニングについて、特に重要な点をご案内いたします。 一般的に運用の開始後は設定や構成の変更が難しくなりますので、パフォーマンス チューニングについては、構築の段階から考慮いただくことが重要となります。 後述の通り、SharePoint Online と SharePoint オンプレミスのアーキテクチャの相違もパフォーマンスに大きく影響するため、SharePoint オンプレミスから SharePoint Online へ移行を検討する場合においても、本稿の内容は非常に重要になります。   クラウドサービスについては継続して動作が変更されるため、今後もパフォーマンス チューニングについての考慮点は段階的に追加や変更がされる可能性がありますが、以下にご案内する機能については今後パフォーマンスの改善を予定しておりません。 SharePoint Online をベストな状態でご利用いただくためには、可能な限り本稿の内容を考慮いただくことを、お願いいたします。   パフォーマンス チューニングの必要性 SharePoint Online はクラウド サービスとなりますので、データセンター側でサーバーの稼働状況を継続的に自動で監視し、必要に応じて適切なスケーリングを実施しています。 しかし、SharePoint Online は柔軟なサイト デザインや、カスタマイズ機能を提供していることから様々な利用方法が想定され、データセンター側のインフラにおけるスケーリングのみでは十分なパフォーマンスが得られないことがあります。 また、一部の機能においては深刻なパフォーマンス劣化が生じる可能性があるものの、データセンター側のスケーリングが対応しておりません。 このため、ご利用者様においても、パフォーマンス チューニングについては意識していただく必要があります。   パフォーマンス チューニングに関する情報は今後も随時して公開していく予定ですが、データセンター側のスケーリングが対応していない機能については、特に注意いただく必要があります。 詳細は次項にてご案内いたします。   データセンター側のスケーリングに対応していない機能 SharePoint Server 発行インフラストラクチャ/SharePoint Server 発行機能 (以下、発行機能) を有効にしているサイト コレクション/サイトで利用可能な以下の機能については、SharePoint Online のパフォーマンスに大きく影響する可能性があります。 ・構造ナビゲーション ・コンテンツ クエリ Web…

0

PowerShell で SharePoint CSOM を使用する際の Tips

こんにちは、SharePoint サポートの秋山 雅裕 (makiyama) です。   今回の投稿では、SharePoint Server / SharePoint Online に対して、クライアント サイド オブジェクト モデル (以下、CSOM) をリモートで実行する PowerShell スクリプトを記述する際の Tips をご紹介します。   CSOM を使用することで、SharePoint にログインすることなくサイト コレクション配下のオブジェクトを操作するバッチなどを実装することが可能です。 また、PowerShell を使用することで、Visual Studio などをインストールすることなくスクリプトが実行できます。   <目次> 事前準備 ツール 基本的な CSOM の実装 ラムダ式の利用 ファイル出力   事前準備 対象となる SharePoint によって利用可能な API が異なるため、適切な CSOM のアセンブリを取得します。 SharePoint の更新に合わせて CSOM のアセンブリも更新されるため、定期的に最新版を確認、取得いただくことをお勧めします。   SharePoint Online…

0

見落とされやすいパフォーマンス問題の原因

こんにちは。SharePoint サポートチームの荒川です。 これまでにも何度かブロッキング関連のトラブルについて記事を書いてきましたが、今回は見落とされやすいブロッキング要因について解説します。   この記事の趣旨 一つのコンテンツデータベースにデータ量が多いサイトコレクションとデータ量の少ないサイトコレクションを混在させた場合、パフォーマンスおよびブロッキング問題の原因になることがあるため、データ量が多いサイトコレクションには専用のコンテンツデータベースを設けることを強くお勧めします。   問題シナリオ 以下の問題について考えます。 サイトにアクセスするとしばらく (30秒から1分以上) 待たされ、サイトが開けることもあるがタイムアウトエラーになりアクセスできないこともある。 この問題は時々発生し、すべての Web サーバーを IIS リセットするか、SQL サーバーを再起動またはフェールオーバーすることで改善されるがしばらくすると再発する。   上記のような問題が発生している場合、可能性が高い原因として SQL サーバーのブロッキング問題が挙げられます。 ブロッキング問題が発生しているときの特徴には以下のようなものがあり、これらの状況が複数一致しているようであればブロッキング問題に遭遇している可能性が高くなります。  サイトにアクセスするとすぐにエラーになるのではなく、しばらく砂時計の状態で待たされる 最終的にタイムアウトエラーとなる場合もあれば、一定時間で解消することもある 問題が断続的に発生し、IIS リセットや SQL サーバーの再起動で解消される ブロッキングが発生してクエリのパフォーマンスが低下している状況では、SharePoint の診断ログに以下のような「Slow Query Duration」の警告が複数出力されることがあります。このログはクエリが完了したタイミングで記録されるものになりますので、ブロッキングが長時間におよびクエリが全く成功しない状況ではログが出力されない場合もあり、一様に判断基準にすることはできませんが、パフォーマンス問題の診断の参考として利用できる情報です。 <診断ログの例> 07/01/2016 17:15:05.35 w3wp.exe (0x1234) 0x0123 SharePoint Foundation Database fa43 High Slow Query Duration: 4562406.84626119 c6dd1b44-7004-46ff-xxxx-d2b1b9ca5ec0   上記のログが出力される場合少なくとも SQL Server に対してクエリは実行されており、そのクエリの実行に時間がかかっているということが判断できますので、SQL Server…


SharePoint ブロッキング問題の調査手法 (後編)

<連載> SharePoint ブロッキング問題の調査手法 (前編) SharePoint ブロッキング問題の調査手法 (後編)   こんにちは。SharePoint サポートチームの荒川です。 前回に引き続き、ブロッキングの要因となった操作を特定する方法について解説します。 前編では、利用状況モニターを使用してリアルタイムにブロッキングを確認する方法について解説しましたが、利用状況モニターを見ただけではブロッキングの発生有無は確認できてもその原因となった操作までは特定できませんでした。ブロッキングの原因となった操作を特定するためには、SQL Server 側の情報と合わせて、SharePoint 側の情報も確認する必要があります。   SQL Server 側での情報採取 SharePoint 側の処理を特定する前に、SQL Server 側で先頭ブロックの SQL クエリの内容と、セッション情報を取得する必要があります。前編でも述べたとおり、ブロッキングは通常 SharePoint 側からは単なる処理の遅延として扱われるため、SharePoint 側のログには一目でそれとわかるようなエラー情報は出力されません。タイムアウトエラーが記録されたときには既に遅く、ブロッキングの原因となっているアクセスに関するログはそれよりずっと前に記録されていることが殆どであり、診断ログの情報量はとても多いため、問題の発生個所の特定は容易ではありません。このため、SQL Server 側からのアプローチが必要になります。 利用状況モニターの情報は、リアルタイムでの調査には向いていますが、データを採取しておき後から調べるのには向いていませんので、利用状況モニターと同様の情報に加えて後の調査に必要となる様々な情報を一括で採取できるスクリプトを使用します。以下のスクリプトの内容をコピーして [新しいクエリ] に貼り付けて実行してみましょう。このスクリプトでは、ブロッキングに関するセッション情報、ブロッキングに関連しているプロセスで実行されているクエリ、ロックされているオブジェクトを特定するためのオブジェクト情報の一覧がまとめて採取できます。 すぐに調査しない場合であっても、[クエリ] メニューの [結果の出力] で「結果をファイルに出力」を選択して結果を保存しておけば、後から調査する際の参考データとしても使用できます。 /*出力1 – セッション一覧*/ SELECT [Session ID] = s.session_id, [Last Request Start Time] = s.last_request_start_time, [Host Name] = ISNULL(s.host_name,…


SharePoint ブロッキング問題の調査手法 (前編)

<連載> SharePoint ブロッキング問題の調査手法 (前編) SharePoint ブロッキング問題の調査手法 (後編)   こんにちは。SharePoint サポートチームの荒川です。 以前に「SharePoint と SQL ブロッキングの話」と題して SharePoint Server におけるブロッキング問題について解説しましたが、今回は SharePoint ブロッキング問題の調査手法について、より実践的な内容に踏み込んで解説したいと思います。   はじめに お客様からお問い合わせいただくパフォーマンス問題の大半を占める問題として SQL Server のブロッキング問題が挙げられます。ブロッキングとデッドロックは異なるもので、デッドロックはエラーとして検出されすぐにクライアント側にエラーが返されますが、ブロッキングは単に処理に時間がかかっている場合に発生する待ち状態になります。従ってプログラム上は正常に動作している範疇にあるものと捉えますので、これを「問題」ととらえるか否かは、ブロッキングの程度とユーザーの許容範囲に依るものとなり、その性質が、トラブルシュートをより難しいものにしています。 私の経験上、ブロッキングが発生する環境では同一コンテンツ データベース内に複数のサイト コレクションが存在し、さらに一部のサイトコレクションのデータ テーブルに数万件単位の大量のレコードが存在することが多いように見受けられます。レコードの内容は単純にリストやライブラリのアイテム数であったり、ユーザー権限や監査ログ等に関するレコードであったり、個人用 Web パーツやリンク情報といったユーザーの運用方法に大きく依存するため、一様にお伝えすることができないのが現状です。特にユーザーのアクセス毎にデータを登録したり、バッチ処理で大量のデータを処理するなどカスタマイズによる自動化が組み込まれた環境において発生しやすい傾向に感じます。 今回は私の検証環境を用いて実際に SharePoint 上でブロッキングが発生する状況を作り出し、その環境下で原因の特定を作業を進めていきますが、大規模なブロッキングを起こすようなデータ状態をすぐに再現することは難しいため、シンプルにブロッキングの調査手法をご理解いただくことを目的として、以下のような検証環境を作成してみました。 SharePoint Server 2013 SP1 オールインワン (SQL を含む) 環境 検証用リストにフォルダーを作成 フォルダー配下にアイテムを10万件登録 この環境で試しにルートフォルダーのリネームを実施したところ、およそ 40 秒程度の時間を要し、その間に別の IE ウインドウから該当フォルダー配下のアイテムのリネームを実施したところ、フォルダーのリネーム処理が完了するまでの間アイテムのリネーム処理が待たされる (ブロッキングされる) 状況を作り出すことができました。あまり頻繁に発生するようなシナリオではないかもしれませんが、ブロッキング調査の方法を理解するためのサンプルシナリオとして採用しています。   問題がブロッキングに依存するものかどうかの判断基準 ブロッキング問題にはサイトのパフォーマンスが若干低下する程度のものから、サイトに全くアクセスできなくなるものまで様々な程度があります。 パフォーマンスが一時的に低下するだけであれば、致命的な問題とはならず、エンドユーザーからの問い合わせも発生しない場合もありますが、重度なものでは長時間にわたりサイトに全くアクセスができなくなるなど致命的な問題に至る可能性もあります。…


ダンプの取り方について

こんにちは。 SharePoint サポートの木田です。   今回はプロセス ダンプの取り方について紹介します。   SharePoint サポートでは SharePoint に関連するプロセスの CPU 使用率やメモリ使用率が高い、特定の操作で反応が遅い場合などのお問い合わせを頂くことがあります。この場合、イベント ログや診断ログからは原因が特定できな場合がほとんどで、プロセス内の詳細な状況を調べる必要があるときに有効な情報となるのがプロセス ダンプになります。ダンプを取得する最も多いシナリオとして、サイトにアクセスしようとした際に、なかなかサイトが開かない場合や、反応が返ってこないような状況になります。この場合、SharePoint のサイトを提供している IIS のプロセス (w3wp.exe) のダンプ ファイルが必要となります。今回は IIS のプロセスのダンプを取る方法を例に、ダンプの取得方法について紹介します。   ダンプの取り方はいくつかありますが、主な 2 つの方法について紹介します。   方法 1. タスク マネージャーからダンプを取得 方法 2. ツールを使ってダンプを取得   事前準備 ・取得対象のプロセス ID を特定   w3wp.exe プロセスは複数起動しているため、特定の w3wp.exe プロセスに対してダンプを取得するにはプロセス ID を指定する必要があります。その為、事前にプロセス ID の確認が必要となります。   設定手順   1) 現象を確認しているサーバーでタスク マネージャーを起動します。…

0

SharePoint と SQL ブロッキングの話 Part3

<関連記事> SharePoint と SQL ブロッキングの話 Part1 SharePoint と SQL ブロッキングの話 Part2 SharePoint と SQL ブロッキングの話 Part3 皆さんこんにちは SharePoint サポートチームの荒川です。 前回、前々回に引き続き、SharePoint と SQL ブロッキングの話をします。これで一応最後です。   ■イベントログから発生の有無を診断できるのか 前回説明したとおり、実際にブロッキングが起きたかどうかを後から正確に判断する術はありません。しかし、私は多くの経験のなかから、ブロッキング問題が発生した際によく見かける特徴的なイベントを見つけていますので、これがヒントになるかもしれません。 ブロッキング問題が起きた際には、多くの場合 Web サーバーのイベント ログに以下のイベント ID 2262 が記録されます。   アプリケーションイベントログ イベントの種類: 警告 ソース:   W3SVC-WP 分類: なし イベント ID: 2262          日付: <日付> 時刻: <時刻> ユーザ: N/A       コンピュータ: <コンピュータ名>  説明: 次の理由のため、ISAPI ‘C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll’…


SharePoint と SQL ブロッキングの話 Part2

<関連記事> SharePoint と SQL ブロッキングの話 Part1 SharePoint と SQL ブロッキングの話 Part2 SharePoint と SQL ブロッキングの話 Part3 皆さんこんにちは SharePoint サポートチームの荒川です。 前回に引き続き、SharePoint と SQL ブロッキングの話をします。 ここから先はさらに詳しい解説となります。Community Open Day の限られた時間内に収められなかった部分でもありますので、技術的により深い内容を得たい方はご参考いただければ幸いです。   ■どのようなシナリオでブロッキングが発生し得るのか 私が手元で再現して実際に動作を確認しのは、以下のパターンです。先述の Community Open Day セッションのデモでもこちらの例を使用しています。 ・大量のアイテムが格納されているライブラリの親フォルダ名の変更 ・大量のアイテムを含むサイトデータのごみ箱からの削除   上記以外に、過去のユーザー事例から、以下のような状況でもブロッキングが発生する可能性があることを確認しています。詳細な条件等は残念ながら確認できておらず、点在する情報からの判断となります。 ・ワークフローによる大量のアイテム更新 ・大量のコンテンツに複雑な権限を付与した環境での権限の継承、切断   ■ブロッキングの有無を確認する方法 実際に問題が起きた後で、ブロッキングの有無を確認する方法はあるのでしょうか? 答えとしては、ありません。残念ながら既に問題が起きた後、ブロッキングが原因でサイトの応答が停止していたことを断定する手段は無いのです。 したがって、問題を特定するには、サイトの応答が停止している時、つまり SQL Server でブロッキングが起きている最中に、SQL Server 側で利用状況モニターを確認する必要があります。   利用状況モニターの詳細な解説についてはここでは触れませんが、簡単な確認方法を参考まで、紹介しておきます。(利用状況モニターの詳細について知りたい方は SQL Server の…