ソフトウェアの境界と制限 (SharePoint Server 2016 および 2019)
適用対象:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
この記事では、SharePoint Server 2016 および 2019 のソフトウェアの境界と制限について説明します。これには次のものが含まれます。
境界： 設計上超えることができない静的制限
しきい値: 特定の要件に適合させるためには超過させることのできる構成可能な制限
サポートされる制限: 既定でテスト済みの値に設定されている構成可能な制限
注:
このドキュメントの容量計画に関する情報は、計画のためのガイドラインを提供するものです。 これは Microsoft が現実に即した各種の特性を使って行ったテストに基づいています。 ただし、実際に得られる結果は、使用する環境とサイトに実装する機能によって変動します。
Microsoft 365 での SharePoint の制限について説明します。
境界と制限の概要
この記事では、SharePoint Server 2016のパフォーマンスと容量に関するテスト済みの制限を把握するのに役立つ情報を提供し、許容範囲のパフォーマンスに関連する制限のガイドラインを示します。 この記事の情報を利用して、計画中の展開が許容範囲のパフォーマンスと容量の制限内になるかどうかを判断し、使用する環境に応じた制限を構成してください。
この記事で提供されるテスト結果とガイドラインは、1 つの SharePoint Server ファームに適用されます。 インストールにサーバーを追加しても、この記事の後半の「 制限と境界 」セクションの表に記載されているオブジェクトの容量制限が増えない可能性があります。 一方、サーバー コンピューターを追加すると、多数のオブジェクトを使用する場合の許容範囲のパフォーマンスの実現に必要となりうるサーバー ファームのスループット向上が得られます。 状況によっては、ソリューションで大量のオブジェクトを使用する要件として、ファーム内のサーバー数増加が必要になります。
特定の環境のパフォーマンスに影響を与える可能性がある多くの要因があり、これらの各要因が異なる領域のパフォーマンスに影響を与える可能性があります。 この記事の一部のテスト結果と推奨事項は、環境内に存在しない機能やユーザー操作に関連している可能性があるため、ソリューションには適用されません。 独自の環境に応じた正確なデータを取得するには、詳細なテストが必要です。
境界、しきい値、およびサポートされる制限
SharePoint Server には、設計上、超えることができない特定の制限と、ファーム管理者によって変更される可能性がある既定値に設定されているその他の制限があります。 また、Web アプリケーションごとのサイト コレクションの数など、構成可能な値で表されない特定の制限もあります。
境界は、設計上超えることができない絶対制限です。 これらの制限を理解して、ファームを設計するときに誤った仮定をしないようにすることが重要です。
境界の例としては、10 ギガバイト (GB) のドキュメント サイズ制限があります。10 GB を超えるドキュメントを格納するように SharePoint Server 2016 を構成することはできません。 この境界は組み込みの絶対値であり、設計上超えることはできません。
しきい値は、値が変更されない限り超過できない既定値です。 しきい値は、特定の状況では、ファーム設計の差異に対応するために超過する可能性があります。 しきい値を超えると、他の制限の有効な値に加えて、ファームのパフォーマンスに影響する可能性があることを理解することが重要です。
一部のしきい値では、既定値の超過は絶対最大値までに制限されます。 ドキュメント サイズ制限もその 1 つです。 既定では、既定のドキュメント サイズのしきい値は 2 ギガバイト (GB) に設定されていますが、10 GB の最大境界をサポートするように変更できます。
サポートされる制限は、パラメーターごとのテスト済み値を定義します。 このような制限の既定値は、テスト結果に基づいて定義されており、製品の既知の制限を示します。 サポートされる制限を超えると、予期しない結果、パフォーマンスの著しい低下など、悪影響が発生する可能性があります。
サポートされる制限の一部は、既定で推奨値に設定される構成可能なパラメーターですが、サポートされるその他の制限は、構成可能な値で表されないパラメーターに関連します。
たとえば、ファームごとのサイト コレクション数もサポートされる制限の 1 つです。 この場合のサポートされる制限は、テスト時にパフォーマンス ベンチマークに適合した、Web アプリケーションごとのサイト コレクションの最大数です。
このドキュメントで提供される制限値の多くは、リソースの負荷の増加と、値の増加に伴うパフォーマンスの低下を表す曲線内のポイントを表していることを理解することが重要です。 そのため、Web アプリケーションごとのサイト コレクションの数など、特定の制限を超えると、ファームのパフォーマンスが低下する可能性があります。 ただし、ほとんどの場合、確立された制限付近で動作することはベスト プラクティスではありません。許容可能なパフォーマンスと信頼性の目標は、ファームの設計が制限値の妥当なバランスを提供する場合に最適です。
しきい値とサポートされる制限のガイドラインは、パフォーマンスに基づいて確認されています。 つまり、既定の制限値より大きくすることはできますが、制限値を大きくするとファームのパフォーマンスやその他の制限の有効値に影響することがあります。 SharePoint Server 2016 では多くの制限を変更できますが、特定の制限を変更することがファームの他の部分にどのように影響するかを理解することが重要です。
制限値の確認方法
SharePoint Server では、ファーム サービスと操作が有効な運用制限に達するまでの負荷の増加に伴うファームの動作のテストと観察によって、しきい値とサポートされる制限が確立されます。 ファームのサービスとコンポーネントには、他のサービスやコンポーネントより高い負荷をサポートできるものもあるので、場合によっては、複数の要素の平均値に基づいて制限値を割り当てる必要があります。
たとえば、サイト コレクションを追加して負荷に対するファームの動作を観察すると、許容範囲外の長い待機時間を示す機能と、許容可能なパラメーター範囲内で動作する機能があります。 したがって、サイト コレクションの数に割り当てられる最大値は絶対値ではありませんが、ほとんどの状況で、指定された制限でファームの全体的なパフォーマンスが許容される予想される使用特性のセットに基づいて計算されます。
制限値のテストに使用したパラメーターより大きい値のパラメーターでサービスを使用する場合には、一部のサービスの有効な制限値は当然低下します。 そのため、その環境の有効な制限を確立するには、厳密な容量管理を実行し、特定のデプロイのテスト演習をスケーリングすることが重要です。
注:
制限は複数のファームと環境から収集されたため、このドキュメントの制限の検証に使用されたハードウェアについては説明しません。
パイにたとえた解説
ハードウェア リソース、負荷、およびパフォーマンスの関係を理解するには、関連する要素、およびその要素が互いにどのような影響を及ぼすかを可視化することが重要です。
ファームの容量を円グラフと見なします。そのサイズは、サーバー、CPU や RAM などのハードウェア リソース、ストレージ容量、ディスク IOPS、ネットワーク帯域幅、待機時間などの要因の集計を表します。 したがって、円グラフのサイズは、ファームの全体的なリソースに関連します。リソース (ファーム サーバーなど) を追加すると、パイのサイズが大きくなります。
この円グラフは、ユーザー要求、検索クエリ、インストールされている機能に対する操作、タイマー ジョブ、オペレーティング システムのオーバーヘッドなど、さまざまなソースからの負荷を表すスライスに分かれています。 これらの各セクションでは、使用可能なファーム リソースを共有する必要があります。 1 つのスライスのサイズが大きくなる場合、他のスライスのサイズは比例して減少する必要があります。 ファームの負荷は静的ではないので (たとえば、ユーザーの要求は 1 日の特定の時間にのみ重要な場合があります)、スライスの相対的なサイズは絶えず変化します。 ただし、各スライスは、正常に動作するために必要な最小サイズを維持する必要があります。また、各スライスで表される関数は相互に依存するため、1 つのスライスのサイズを大きくすると、使用できるリソースが減るだけでなく、他のスライスに負荷がかかる可能性があります。
このたとえを使用すると、ファームの設計目標は、ピーク負荷時にパイの各切片の必要サイズを収容できるほどにパイを大きくすることになります。
次に、ユーザー要求がベースラインより 100% 増加するシナリオを考えてみましょう。 要求の約半分が検索クエリであり、残りの半分の編集リストとドキュメントであるとします。 この負荷の増加により、他の円グラフスライスが絞り込まれますが、一部のファームフィーチャも補正を難しくする必要があります。 Search Serviceはより多くのクエリを処理する必要があります。そのほとんどはキャッシュによって処理されますが、一部のクエリはデータベース サーバーに渡され、負荷も増加します。 データベース サーバーの負荷が大きすぎると、ディスク キューの長さが長くなり、他のすべての要求の待機時間が長くなります。
制限と境界
このセクションでは、ソリューションに含めることのできるオブジェクトの一覧を示し、許容範囲のパフォーマンスを得るためのガイドラインをオブジェクトの種類別に示します。 許容されるパフォーマンスとは、テスト済みのシステムがその数のオブジェクトをサポートできることを意味しますが、パフォーマンスの低下や関連する制限の値の減少がなければ、その数を超えることはできません。 オブジェクト一覧は、階層別と機能別に記載します。 制限データには、その制限値の収集に使用した条件に関する説明と、追加情報がある場合にはその情報へのリンクを付記します。
この記事で示すガイドラインを使用して、ソリューション計画全体をレビューしてください。 ソリューション計画において、1 つ以上のオブジェクトの推奨ガイドラインを超過している場合は、以下のいずれかまたは複数の対策を行ってください。
ソリューションを評価し、他の分野で相殺されていることを確認します。
展開の構築時に、テストと監視の対象分野をフラグ設定します。
容量ガイドラインを超えないようにソリューションを再設計またはパーティション分割します。
階層別の制限
このセクションでは、制限を SharePoint Server 2016 ファームの論理階層別に示します。
Web アプリケーションの制限
以下の表に、Web アプリケーションの推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| Web アプリケーション |
ファームごとに 20 個 |
サポートされている |
できるだけ Web アプリケーションの数を制限することをお勧めします。 Web アプリケーションを追加する代わりに、可能な場所では、ホスト名の付いたサイト コレクションを追加で作成します。 |
| 領域 |
Web アプリケーションごとに 5 個 |
境界 |
1 つのファームに定義されるゾーンの数は、5 個にハードコードされています。 既定、イントラネット、エクストラネット、インターネット、およびユーザー設定のゾーンがあります。 |
| ホスト名の付いたサイト コレクションの管理パス |
ファームごとに 20 個 |
サポートされている |
ホスト名の付いたサイト コレクションの管理パスは、ファーム レベルで適用します。 作成した管理パスはそれぞれ、どの Web アプリケーションでも適用できます。 |
| パスベースのサイト コレクションの管理パス |
Web アプリケーションごとに 20 個 |
サポートされる |
管理パスは Web サーバーにキャッシュされ、管理パス リストを求める着信要求の処理に CPU リソースが使用されます。 パスベースのサイト コレクションの管理パスは、Web アプリケーション レベルで適用します。 各 Web アプリケーションに異なる管理パスのセットを作成できます。 Web アプリケーション 1 つあたりの管理パスが 20 個を超えると、要求ごとに Web サーバーにかかる負荷が増えます。 Web アプリケーションで 20 個を超える管理パスを使用することを計画している場合、許容範囲のシステム パフォーマンスが得られるかテストすることをお勧めします。 |
| ソリューション キャッシュのサイズ |
Web アプリケーションごとに 300 MB |
しきい値 |
ソリューション キャッシュでは、ソリューション取得を高速化するために InfoPath Forms Service でソリューションをキャッシュに保持できます。 キャッシュ サイズの上限を超えると、ソリューションをディスクから取得することになり、応答速度が遅くなることがあります。 ソリューション キャッシュのサイズを構成するには、「Set-SPInfoPathFormsService」を参照してください。 |
SharePoint Server の制限
以下の表に、ファーム上の Web サーバーの推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| アプリケーション プール |
Web サーバーごとに 10 個 |
しきい値 |
最大数はハードウェアの能力によって決まります。 この制限は以下の要素に依存します。 Web サーバーに割り当てられるメモリ容量 ユーザー ベースと使用特性など、ファームにかかる負荷 (使用率の高いアプリケーション プールは、1 つで 10 GB 以上を使用できます) |
コンテンツ データベースの制限
以下の表に、コンテンツ データベースの推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| コンテンツ データベースの数 |
ファームごとに 500 個 |
サポートされる |
ファームごとのコンテンツ データベースの最大数は 500 個です。 Web アプリケーションあたり 500 のコンテンツ データベースでは、サイトやサイト コレクションを開くなどのエンド ユーザー操作は影響を受けません。 ただし、新しいサイト コレクションの作成など、管理操作のパフォーマンスは低下します。 コンテンツ データベースが多数あると、管理用インターフェイスの応答が遅くなることがあり、操作が困難になるので、その場合の Web アプリケーションの管理には PowerShell を使用することをお勧めします。 SharePoint Server 2016 では、コンテンツ データベースあたり 200 GB、ファームあたり 500 のコンテンツ データベースで、ファームごとに 100 TB のデータがサポートされています。 |
| コンテンツ データベースのサイズ (一般的な使用シナリオ) |
コンテンツ データベースごとに 200 GB |
サポートされる |
この表の以下の行の状況に当てはまる場合を除いて、コンテンツ データベースのサイズを 200 GB に制限することを強くお勧めしました。 リモート BLOB ストレージ (RBS) を使用している場合、コンテンツ データベース内のリモート BLOB ストレージとメタデータの合計ボリュームが 200 GB の制限を超えてはなりません。 |
| コンテンツ データベースのサイズ (すべての使用シナリオ) |
コンテンツ データベースごとに 4 TB |
サポートされる |
以下の要件が満たされる場合、最大 4 TB のコンテンツ データベースがサポートされます。 ディスク サブシステムのパフォーマンスは、GB あたり 0.25 IOPS です。最適なパフォーマンスを得るには、GB あたり 2 つの IOP が推奨されます。 高可用性、障害復旧、将来の容量、およびパフォーマンス テストの計画を作成しておく必要があります。 また、以下の要因を慎重に考慮する必要があります。 200 GB を超えるコンテンツ データベースの場合、ネイティブの SharePoint Server 2016 のバックアップでは、バックアップおよび復元の要件が満たされないことがあります。 特定の環境に最適なソリューションを決定するには、SharePoint Server 2016 のバックアップ ソリューションと代替バックアップ ソリューションを評価してテストすることをお勧めします。 SharePoint Server 2016 およびSQL Serverインストールのプロアクティブな熟練した管理者管理を行うことを強くお勧めします。 SharePoint Server 2016 でのカスタマイズと構成の複雑さによって、複数のコンテンツ データベースへのデータのリファクタリング (つまり分割) が必要になる場合があります。 高い技能を持つ専門のアーキテクトからの助言を求めてテストを実行し、ユーザーの実装に応じた最適なコンテンツ データベース サイズを決定します。 複雑さの例としては、カスタム コードのデプロイ、プロパティ昇格での 20 を超える列の使用、または以下の 4 TB を超えるセクションで使用しないように記載されている機能などがあります。 サイト コレクションのリファクタリングでは、SharePoint Server 2016 実装を複数のコンテンツ データベースにわたってスケールアウトできます。 これにより、SharePoint Server 2016 実装を無制限に拡大できます。 コンテンツ データベースが 200 GB 未満の場合、このリファクタリングをより容易に短時間で行うことができます。 バックアップと復元を容易にするために、コンテンツ データベース内の個々のサイト コレクションを 100 GB に制限することをお勧めします。 詳細については、「 サイト コレクションの制限」を参照してください。 重要: ドキュメント アーカイブ シナリオ (この表の次の行で説明) を除き、4 テラバイト (TB) を超えるコンテンツ データベースの使用はお勧めしません。 将来的に SharePoint Server 2016 のインストールのアップグレードが必要になった場合に、このようなコンテンツ データベース内ではサイト コレクションのアップグレードが非常に困難で時間がかかるものになる可能性があります。 > 1 つのコンテンツ データベースで 4 TB を超えるデータではなく、複数のコンテンツ データベース間でスケールアウトすることを強くお勧めします。 |
| コンテンツ データベースのサイズ (ドキュメント アーカイブ シナリオ) |
コンテンツ データベースに対する明示的な制限なし |
サポートされている |
以下の要件が満たされる場合、ドキュメント アーカイブ シナリオでの使用に関して、明示的なサイズ制限のないコンテンツ データベースがサポートされます。 この表の前述の "コンテンツ データベースのサイズ (すべての使用シナリオ)" 制限に含まれるすべての要件を満たす必要があり、その制限の "メモ" フィールドで説明されているすべての要因を慎重に考慮したことを確認する必要があります。 SharePoint Server 2016 サイトは、 ドキュメント センター サイト テンプレートまたは レコード センター サイト テンプレートに基づく必要があります。 毎月平均でコンテンツ データベース内の 5% 未満のコンテンツがアクセスされ、毎月平均で 1% 未満のコンテンツが変更または書き込まれます。 コンテンツ データベース内の SharePoint Server 2016 オブジェクトでは、アラート、ワークフロー、リンクの修正、またはアイテム レベルのセキュリティを使用しないでください。 > [!注]> ドキュメント アーカイブ コンテンツ データベースは、コンテンツ ルーティング ワークフローからドキュメントを受け入れるように構成できます。 |
| コンテンツ データベースのアイテム |
ドキュメントおよびリスト アイテムを含む、6,000 万アイテム |
サポートされる |
SharePoint Server 2016 でテストされたコンテンツ データベースあたりの最大アイテム数は、ドキュメントおよびリスト アイテムを含め、6,000 万アイテムでした。 SharePoint Server 2016 に 6,000 万個を超えるアイテムを格納する計画がある場合は、複数のコンテンツ データベースを展開する必要があります。 |
| コンテンツ データベースごとのサイト コレクション |
最大 10,000 個 (非個人用サイト コレクションが 2,500 個と個人用サイトが 7,500 個、または個人用サイトだけで 10,000 個) |
サポートされる |
1 つのコンテンツ データベース内のサイト コレクションの数を 5,000 個に制限することを強くお勧めします。 ただし、データベース内のサイト コレクションは最大 10,000 個までサポートされています。 サイト コレクションの合計が最大 10,000 個のコンテンツ データベースでは、最大 2,500 個のサイト コレクションを個人用以外のサイト コレクションにすることができます。 コンテンツ データベース内の唯一のサイト コレクションである場合は、10,000 個の個人用サイト コレクションをサポートできます。 データベース内のサイト コレクション数の制限は、複数のサイト コレクションが含まれるコンテンツ データベースのサイズ制限に依存します。 したがって、データベース内のサイト コレクション数が多くなると、そのデータベースに含まれるサイト コレクションの平均サイズは小さくなります。 サイト コレクション数が制限の 5,000 個を超えると、アップグレード時のダウンタイムが長くなる可能性があります。 5,000 個を超えるサイト コレクションを使用する予定の場合は、停止期間の長さや操作への影響に対処する明確なアップグレード戦略を計画し、データベースに影響するソフトウェア更新とアップグレードを高速化できる追加のハードウェアを用意することをお勧めします。 Exceeding the 5,000 site collection limit puts you at risk of longer downtimes during upgrades. 5,000 個を超えるサイト コレクションを使用する予定の場合は、停止期間の長さや操作への影響に対処する明確なアップグレード戦略を計画し、データベースに影響するソフトウェア更新とアップグレードを高速化できる追加のハードウェアを用意することをお勧めします。 コンテンツ データベース内のサイト数について警告レベルと最大レベルを設定するには、PowerShell コマンドレット Set-SPContentDatabase に WarningSiteCount パラメーターを指定して使用します。 詳細については、「 Set-SPContentDatabase」を参照してください。 |
| ネットワーク接続ストレージ (NAS) 上のリモート BLOB ストレージ (RBS) ストレージ サブシステム |
NAS からの応答の先頭バイト受信時間は 40 ミリ秒 (時間の 95%) を超えることはできません。 |
境界 |
RBS を使用するように SharePoint Server 2016 を構成し、BLOB が NAS ストレージ上にある場合、以下のサポートされる限界を考慮する必要があります。 SharePoint Server 2016 の BLOB 要求時から NAS からの先頭バイト受信までの時間は、40 ミリ秒 (時間の 95%) を超過できません。 |
サイト コレクションの制限
以下の表に、サイト コレクションの推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| ファームごとのサイト コレクション |
サイト コレクションあたり 250,000 個 / 500,000 個の個人用サイト / ファームあたり 250,000 の他のサイト |
サポート対象 |
ファームごとのサイト コレクションの推奨最大数は、個人用サイトが 500,000 個と、その他すべてのサイト テンプレートが 250,000 個です。 すべてのサイトを 1 つの Web アプリケーションに存在させることも、複数の Web アプリケーションに分散させることもできます。 この制限は、特定のコンテンツ データベースでサポートできるサイト コレクションの有効な数を減らす可能性がある他の要因の影響を受けます。 コンテンツ データベースのように、コンテナー オブジェクトに他のオブジェクトが多数含まれる場合、サポートされる制限を超えないように注意する必要があります。 たとえば、ファームに含まれるコンテンツ データベースの総数は少ないが、各コンテンツ データベースに含まれるサイト コレクションが多い場合、サポートされているサイト コレクション数の制限に達するより、かなり前からファームのパフォーマンスに悪影響が出ることがあります。 メモリ使用量は、使用パターンおよび、所定の時間枠にアクセスされるサイトの数に依存するので、Web サーバー上のメモリ使用量を監視する必要があります。 同様に、クロール対象のメモリ使用率が高くなることもあります。 ただし、各コンテンツ データベースに 10,000 個のサイト コレクションが含まれている場合、この数はコンテンツ データベースでサポートされていますが、ファーム内のサイト コレクションの合計数は 2,000,000 であり、Web アプリケーションあたりのサイト コレクション数の制限を超えています。 Web サーバーのメモリ使用量は、使用パターンと、特定の期間内にアクセスされているサイトの数によって異なりますので、監視する必要があります。 同様に、クロール ターゲットでもメモリ負荷が発生する可能性があります。そのため、任意の Web サーバーで使用可能なメモリが 2 GB 未満に低下する前に、アプリケーション プールをリサイクルするように構成する必要がある場合。 |
| Web サイト |
サイト コレクションあたり 250,000 個 / ファームあたり 250,000 個 / ファームあたり 500,000 の個人用サイト |
サポート |
サイト コレクション内の Web サイトの数については、サポートされる制限は 250,000 個ですが、推奨される制限は 2,000 個です。 Web サイトの数がサイト コレクションで 2,000 個を超えると、パフォーマンスが低下することがあります。 重要: サイト コレクションあたり 2,000 個未満の Web サイトを使用することを強くお勧めします。 サイト コレクションごとに最大 2,000 個の Web サイトを含む複数のサイト コレクションを作成することで、非常に多くの Web サイトを作成できます。 たとえば、それぞれ 2,000 の Web サイトを含む 125 のサイト コレクションは、ファーム内の 250,000 の Web サイトに相当します。 これは、個人用以外のサイトの最大推奨制限と見なされます。 250,000 個のサイト コレクションがある場合、すべて個人用サイト テンプレートではないルート Web サイトを含み、それらのルート Web サイトのいずれかにサブ Web サイトを追加すると、250,000 の Web サイト境界を超えることになります。 サイト コレクションごとの推奨 Web サイト数の上限である 2,000 を超えた場合、次の問題が発生する場合があります。 Web サイトを削除または作成すると、同じサイト コレクション内の他の Web サイトの可用性に影響を与える可能性があります。 Web サイトが削除されている間、サイト コレクション内の Web サイトへのアクセスは制限されます。 多数の Web サイトを同時に作成しようとした場合にも、操作が失敗することがあります。 2,000 以上の Web サイトがある場合、既存のファームに新しいサーバーを追加する際に PSConfig を実行するなどの操作、または SharePoint の更新プログラムをインストールした後の操作のパフォーマンスが大幅に減少します。 stsadm -o checklocalupgradestatus 操作の実行、または 製品バージョン ジョブ タイマー ジョブの日ごとの実行の完了までに数時間かかる可能性があります。 サーバーの全体管理 Web サイトで [データベースの状態の確認 ] ページ (<your_SharePoint_CentralAdmin_URL>/_admin/UpgradeStatus.aspx) を参照すると、タイムアウトになる可能性があります。 |
| サイト コレクションのサイズ |
コンテンツ データベースの最大サイズ |
サポートされる |
A site collection can be as large as the content database size limit for the applicable usage scenario. For more information about the different content database size limits for specific usage scenarios, see the Content database limits table in this article. 一般に、以下の理由から、サイト コレクションのサイズを 100 GB に制限することを強くお勧めします。 Certain site collection actions, such as site collection backup/restore or the PowerShell cmdlet Move-SPSite, cause large SQL Server operations which can affect performance or fail if other site collections are active in the same database. For more information, see Move-SPSite. SharePoint サイト コレクションのバックアップと復元は、サイト コレクションの最大サイズが 100 GB の場合にのみサポートされます。 これより大きいサイト コレクションでは、コンテンツ データベース全体をバックアップする必要があります。 100 GB を超える複数のサイト コレクションが 1 つのコンテンツ データベースに含まれる場合、バックアップおよび復元操作に長い時間がかかる可能性があり、バックアップおよび復元操作が失敗する恐れがあります。 |
| 発行サイト コレクションごとのデバイス チャネルの数 |
10 |
境界 |
発行サイト コレクションごとのデバイス チャネルの許容最大数は 10 個です。 |
リストとライブラリの制限
以下の表に、リストとライブラリの推奨ガイドラインを示します。 詳細については、「大きなリストを設計し、リストのパフォーマンスを最大限に高める (SharePoint Server 2010)」を参照してください。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| リストの行サイズ |
行ごとに 8,000 バイト |
境界 |
Each list or library item can only occupy 8,000 bytes in total in the database. 300 bytes are reserved, leaving 7700 bytes for end-user columns. For details on how much space each kind of field consumes, see Column limits. |
| ファイルのサイズ |
10 GB |
境界 |
既定のファイル サイズは 2 ギガバイト (GB) (2,047 MB) です。 ただし、大きなファイルが大量にあると、ファームのパフォーマンスに影響することがあります。 メモ: SharePoint Server 2019 では、ファイルの制限は 15 GB です。 |
| ドキュメント |
ライブラリごとに 30,000,000 個 |
サポートされている |
フォルダーを入れ子にしたり、標準ビューとサイト階層を使用したりすると、大規模なドキュメント ライブラリを作成できます。 この値は、ドキュメントとフォルダーの構造、および保存するドキュメントの種類とサイズに依存します。 |
| メジャー バージョン |
400,000 |
サポートされている |
この制限を超えると、ファイルを開く操作、ファイルの保存と削除、バージョン履歴表示など、基本的なファイル操作を正常に実行できなくなることがあります。 |
| マイナー バージョン |
511 |
境界 |
マイナー ファイル バージョンの最大値は 511 です。 この制限を超えることはできません。 |
| アイテム |
リストごとに 30,000,000 個 |
サポートされている |
標準ビュー、サイト階層、メタデータ ナビゲーションを使用すると、非常に大きなリストを作成できます。 この値は、リスト内の列数およびリストの使用方法に依存します。 |
| 一括操作 |
一括操作ごとに 100 アイテム |
境界 |
ユーザー インターフェイスからは、一括操作に最大 100 個までのアイテムを選択できます。 |
| リスト ビュー参照のしきい値 |
クエリごとに 12 個の結合操作 |
しきい値 |
Specifies the maximum number of joins allowed per query, such as those based on lookup, person/group, or workflow status columns. If the query uses more than eight joins, the operation is blocked. これは、1 つの項目操作には適用されません。 オブジェクト モデルから (ビュー フィールドを指定せず) 最大ビューを使用すると、最大で最初の 12 個の参照が返されます。 |
| リスト ビューのしきい値 |
5,000 より大きい |
しきい値 |
管理者によって設定される、クエリが制限されない時間帯の範囲外で、クエリなどのデータベース操作が同時に処理できるリストまたはライブラリのアイテムの最大数を指定します。 列のインデックスを追加または削除する場合、既定のしきい値は 20,000 です。 リストまたはフォルダーを削除する場合、既定のしきい値は 100,000 です。 同じライブラリ内のフォルダーの名前を変更する場合、既定のしきい値は 100,000 です。 |
| 監査者と管理者に対するリスト ビューのしきい値 |
20,000 |
しきい値 |
データベース操作 (クエリなど) が適切なアクセス許可を持つ監査員または管理者によって同時に処理できるリストまたはライブラリ項目の最大数を指定します。 この設定は [オブジェクト モデルの上書きを許可する] と併せて機能します。 |
| サブサイト |
サイト ビューごとに 2,000 個 |
しきい値 |
特定の Web サイトのサブサイトを列挙するためのインターフェイスがうまく動作せず、サブサイトの数が 2,000 を超えています。 同様に、サブサイト数が増えると、[すべてのサイト コンテンツ] ページおよびツリー ビュー コントロールのパフォーマンスが著しく低下します。 |
| リスト |
Web サイトあたり 2,000 |
しきい値 |
テストでは、エントリが 2,000 を超えるとリスト ビュー パフォーマンスが低下することが示されています。 |
| .docx, .pptx、および .ppsx ファイルに対する Word と PowerPoint の共同編集 |
ドキュメントごとに 10 人の同時編集者 |
しきい値 |
同時編集者の推奨最大数は 10 人です。 境界は 99 人です。 同じドキュメントを共同編集用に開いて同時に編集しているユーザーが 99 人いる場合、それ以降のユーザーには "ファイルが使用中です" というエラー メッセージが表示され、ドキュメントは読み取り専用でのみ開くことができます。 共同編集者が 10 人を超えると、競合の発生が多くなってユーザーの操作性が次第に低下し、サーバーへの変更のアップロードが正常に終了するまで、ユーザーがアップロード操作を何度も繰り返す必要がある場合があります。 |
| セキュリティ スコープ |
リストごとに 50,000 個 |
しきい値 |
リストに設定されている一意のセキュリティ スコープの最大数は、50,000 を超えることはできません。 ほとんどのファームでは、この制限値を低くして固有のスコープを 5,000 個に制限するよう検討することをお勧めします。 大きなリストの場合は、使用する固有のアクセス許可数ができるだけ少なくなる設計を採用するように検討することをお勧めします。 1 つのリストに設定する固有のセキュリティ スコープの数が、リスト ビューのしきい値 (既定では 5,000 リスト アイテムに設定) を超える場合、リストを表示するときに余計な SQL Server のラウンド トリップが起こります。これにより、リスト ビューのパフォーマンスが悪影響を受けることがあります。 スコープは、セキュリティ保護可能なオブジェクトと、別のセキュリティ境界が定義されていない子のセキュリティ境界です。 スコープには、アクセス制御リスト (ACL) が含まれますが、NTFS ACL とは異なり、スコープには、SharePoint Server 2016 固有のセキュリティ プリンシパルを含めることができます。 スコープの ACL のメンバーには、Windows ユーザー、Windows ユーザー以外のユーザー アカウント (フォーム ベース アカウントなど)、Active Directory グループ、SharePoint グループを含めることができます。 |
| セキュリティ スコープ (ACL) の伝達 |
一意のスコープを持つ 500 個の子オブジェクト |
しきい値 |
ACL 伝達中に更新できる一意のセキュリティ スコープを持つ子オブジェクトの最大数は、500 を超えることはできません。 ACL 伝達を使用して子オブジェクトを更新するようにスコープの更新を設定すると、一意にスコープを限定されたアイテムとアクセス許可を継承するアイテムが更新されます。 子への ACL 伝達を含む親スコープの更新中に、一意のスコープを持つ子オブジェクトの最大数が 500 を超えると、更新される可能性がある一意のスコープを持つ子の一部について伝達が失敗します。 一意のスコープを持つ子オブジェクトの最大数が 500 を超える場合は、ACL 伝達を使用しないでください。 |
列の制限
SharePoint Server 2016 データは SQL Server テーブルに格納されます。 列の種類ごとにバイト単位でサイズ値を示します。 SharePoint リスト内のすべての列の合計は、8,000 バイトを超えることはできません。
| 制限 | 最大列数 | 制限の種類 | 列ごとのサイズ | メモ |
|---|---|---|---|---|
| 1 行テキスト |
255 |
しきい値 |
30 バイト |
|
| 複数行テキスト |
350 |
しきい値 |
22 バイト |
|
| 選択肢 |
255 |
しきい値 |
30 バイト |
|
| 選択肢 (複数選択) |
350 |
しきい値 |
22 バイト |
|
| 数値 |
550 |
しきい値 |
14 バイト |
|
| 通貨 |
550 |
しきい値 |
14 バイト |
|
| 日付と時刻 |
550 |
しきい値 |
14 バイト |
|
| 参照 |
750 |
しきい値 |
10 バイト |
|
| はい/いいえ |
1000 |
しきい値 |
7 バイト |
|
| ユーザーまたはグループ |
750 |
しきい値 |
10 バイト |
|
| ハイパーリンクまたは画像 |
127 |
しきい値 |
60 バイト |
ハイパーリンクまたは画像の列には、ストレージの列が 2 つ割り当てられています。1 つは URL 用、もう 1 つは説明用です。 |
| 集計値 |
255 |
しきい値 |
30 バイト |
SQL Server行の折り返しは、SharePoint リスト内の 8 列ごとに行われます。 したがって、行の折り返しが既定値の 6 行の場合、1 つの SharePoint リストに最大 48 個 (6 * 8 = 48) の集計値列を含めることができます。 |
| GUID |
350 |
しきい値 |
22 バイト |
SQL Server の行の折り返しは、SharePoint リスト内の 1 列ごとに発生します。 したがって、行の折り返しが既定値の 6 行の場合、1 つの SharePoint リストに最大 6 個 (6 * 1 = 6) の GUID 列を含めることができます。 |
| 整数 |
750 |
しきい値 |
10 バイト |
|
| 管理メタデータ |
190 |
しきい値 |
先頭列に 60 バイト、それ以降の各列に 40 バイト |
リストに追加される先頭の管理メタデータ フィールドには、以下の 4 つの列が割り当てられます。 実際のタグ用の参照フィールド 文字列値用の隠し文字フィールド 集約用の参照フィールド 集約のあふれ用の参照フィールド リストに追加されるそれ以降の管理メタデータ フィールドごとに、以下の 2 つの列が追加されます。 実際のタグ用の参照フィールド 文字列値用の隠し文字フィールド マネージド メタデータの列の最大数は (14 + (16 * (n-1))) として計算されます。n は行マッピング値 (既定値は 6) です。 |
| 位置情報 |
2 |
しきい値 |
30 バイト |
外部データ列には、プライマリ列とセカンダリ列という概念があります。 外部データ列を追加するときは、リストに追加する外部コンテンツ タイプのセカンダリ フィールドを選択できます。 たとえば、"ID"、"Name"、"Country"、"Description" などのフィールドを持つ外部コンテンツ タイプ "Customer" を指定すると、"Customer" 型の外部データ列をリストに追加すると、セカンダリ フィールドを追加して顧客の "ID"、"Name"、"Description" を表示できます。 全体としては、以下の列が追加されます。
プライマリ列: テキスト フィールドです。
非表示 ID 列: 複数行のテキスト フィールド。
セカンダリ列: 各セカンダリ列は、ビジネス データ カタログ モデルで定義されているセカンダリ列のデータ型に基づいて、テキスト、数値、ブール値、複数行テキストなどになります。 たとえば、"ID" は数値列に、"Name" は 1 行テキスト列に、"Description" は複数行テキスト列に割り当てられることが考えられます。
ページの制限
以下の表に、ページの推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| Web パーツ |
Wiki または Web パーツ ページごとに 25 個 |
しきい値 |
This figure is an estimate based on simple Web Parts. パフォーマンスに影響することなく 1 つのページに使用できる Web パーツ数は、Web パーツの複雑度に応じて異なります。 |
セキュリティの制限
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| 1 人のユーザーが属することのできる SharePoint グループの数 |
5,000 |
サポートされている |
これはハード制限ではありませんが、Active Directory のガイドラインと一致します。 以下の項目がこの値に影響します。 ユーザー トークンのサイズ グループのキャッシュ: SharePoint Server 2016 には、ユーザーが属するグループがアクセス制御リスト (ACL) で使用されるとすぐに、グループ数をキャッシュするテーブルがあります。 セキュリティ チェック時間: ユーザーがメンバーになっているグループの数が増加すると、アクセス チェックに要する時間も増加します。 |
| 1 つのサイト コレクション内のユーザー |
サイト コレクションごとに 200 万人 |
サポートされている |
個々のユーザーではなく Microsoft Windows セキュリティ グループを使用してセキュリティを管理すると、Web サイトに数百万人のユーザーを追加できます。 この制限は、管理性とユーザー インターフェイスにおけるナビゲーションの容易さに基づいています。 サイト コレクション内に大量の (1000 を超える) エントリ (ユーザーのセキュリティ グループ) がある場合、UI ではなく PowerShell を使用してユーザーを管理してください。 そのほうが管理の操作性が向上します。 |
| 1 つの SharePoint グループ内の Active Directory プリンシパル/ユーザー |
SharePoint グループごとに 5,000 |
サポートされる |
SharePoint Server 2016 では、SharePoint グループにユーザーまたは Active Directory グループを追加できます。 1 つの SharePoint グループ内のユーザー (またはユーザーの Active Directory グループ) の数が最大 5,000 までの場合、許容範囲のパフォーマンスが得られます。 この制限によって以下のアクティビティが特に影響を受けます。 権限を検証するためのユーザーのフェッチ。 グループ内のユーザー数が増えるほど、この操作の所要時間は長くなります。 ビューのメンバーシップのレンダリング。 この操作は常に時間を要します。 |
| SharePoint グループ |
サイト コレクションごとに 10,000 個 |
サポートされている |
グループ数が 10,000 個を超えると、操作実行時間が著しく増加します。 特に、既存のグループへのユーザーの追加、新しいグループの作成、グループ ビューのレンダリングが影響を受けます。 |
| セキュリティ プリンシパル: セキュリティ スコープのサイズ |
アクセス制御リスト (ACL) ごとに 5,000 個 |
サポートされている |
The size of the scope affects the data that is used for a security check calculation. This calculation occurs every time that the scope changes. ハード制限はありませんが、スコープが大きいほど、計算にかかる時間は長くなります。 |
機能別の制限
このセクションでは、制限を機能別に示します。
検索の制限
検索の推奨ガイドラインは、影響のある検索の側面に従って構成されています。これらの側面には、トポロジ、アイテムのサイズ、辞書、クロール、スキーマ、クエリと結果、ランク付け、インデックスがあります。
検索: トポロジの制限
トポロジの制限は、検索コンポーネント間の効率的な通信を確保します。 Exceeding these limits slows down the communication between search components, which can result in longer query latencies and ultimately outage of search.
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| 分析処理コンポーネント |
Search service アプリケーションごとに 6 個、サーバーごとに 1 個 |
サポートされている |
|
| 分析レポート データベース |
Search service アプリケーションごとに 4 個 |
しきい値 |
特定の要件を満たさなければならない場合は、この制限を超えることができます。 スケーリング時に、デプロイされた分析データベースのサイズが合計サイズ 250 GB または合計行数 20 M に達したときに、分析レポート データベースを追加します。 こうすると、パーティション再分割のバランスが極力維持されます。 |
| リンク データベース |
Search Service アプリケーションごとに 4 個 |
サポートされている |
リンク データベースに含めることができる最大テスト済みアイテム数は 1 億個です。 |
| クロール コンポーネント |
Search service アプリケーションごとに 16 個、サーバーごとに 1 個 |
サポートされている |
|
| インデックス コンポーネント |
Search service アプリケーションごとに 60 個、サーバーごとに 4 個 |
サポートされている |
存在するインデックス コンポーネント数を計算するには、インデックス パーティション数とインデックス レプリカ数を乗算します。 |
| インデックス パーティション |
Search Service アプリケーションごとに 25 個 |
サポートされている |
インデックス パーティションには、Search service アプリケーションのインデックスのサブセットが含まれます。 インデックス パーティションの数を増やすと、各パーティションに含まれるインデックスのサブセットが小さくなり、インデックス コンポーネントをホストするサーバーに必要な RAM とディスク容量が少なくなります。 |
| インデックス レプリカ |
インデックス パーティションごとに 3 個 |
サポートされている |
インデックス パーティションごとに、レプリカのセットを設定できます。 インデックス レプリカの数を増やすと、クエリのパフォーマンスによい影響を与え、フォールト トレランスが改善されます。 ただし、インデックス パーティションに追加するレプリカが多すぎる場合は、インデックス作成に悪影響を及ぼすことがあります。 インターネット サイトのシナリオは、一般に高いクエリ レートで低いコンテンツ ボリューム (パーティションごとに 400 万アイテム未満) ですが、このシナリオでサポートされる制限はパーティションごとに 6 個のインデックス レプリカです。 |
| コンテンツ処理コンポーネント |
サーバーごとに 1 個 |
サポートされる |
検索トポロジはコンテンツ処理コンポーネント数のスケール アウトをサポートします。 特定の物理ホストまたは仮想マシンでは複数のコンテンツ処理コンポーネントがサポートされますが、1 つのコンテンツ処理コンポーネントを使用することによって、CPU 容量の使用率が向上します。 それは、組み込みのメカニズムによって、フィーディング セッションの数が、利用できる CPU コアに従って調節されて、CPU 使用率が最大になるからです。 複数のフィーディング セッションによって、コンテンツ処理コンポーネントは受信ドキュメントを並行して処理できます。 このメカニズムでは、ホストごとに 1 つのコンテンツ処理コンポーネントが想定されています。 ホスト上の物理コアの数が N と等しい場合、コンテンツ処理コンポーネントにはN K のフィード セッションがあります。K は初期値 3 の定数係数です。4 コア サーバーには 12 個のフィード セッションがあります。つまり、コンテンツ処理コンポーネントは 12 個のドキュメントを並列で処理できます。K の値を変更するには、Search Service アプリケーションの NumberOfCssFeedersPerCPUForRegularCrawl プロパティを設定します。SharePoint Server 2016 では、サーバーに 12 個を超える物理コアがある場合でも、N の値を 12 に制限します。そのため、16 コア サーバーには NK = 12 * 3 = 36 のフィード セッションがあります。 それでもアイドル状態の CPU 時間がある場合には、さらにコンテンツ処理コンポーネントを追加する代わりに、K 係数を増やすことを考えます。 K 係数を増やす場合、利用できるメモリがホストに十分あることを確認する必要があります。 |
| クエリ処理コンポーネント |
サーバーごとに 1 個 |
サポートされる |
SharePoint Server 2016 は、物理マシンまたは仮想マシンごとに 1 つのクエリ処理コンポーネントのみサポートします。 |
| 検索コンポーネント |
Search Service アプリケーションごとに 64 個 |
サポートされている |
この制限にはクロール コンポーネントは含まれません。 他のすべての検索コンポーネントの合計をこの制限内にする必要があります。 |
| Search service アプリケーション |
ファームごとに 20 個 |
サポートされている |
検索のコンポーネントとデータベースを別個のサーバーに割り当てることができるので、同じファームに複数の Search service アプリケーションを展開できます。 この制限値は、1 つのファーム内のサービス アプリケーションの総数に対する制限より少ない値です。 |
| コンテンツ ソース |
Search Service アプリケーションごとに 500 個 |
境界 |
各コンテンツ ソースにはオーバーヘッドが関連付けられているため、クロールの優先順位やスケジュールの違いなど、他の運用要件を満たす最小数のコンテンツ ソースを作成することをお勧めします。 |
検索: アイテム サイズの制限
アイテム サイズの制限は、クロール パフォーマンスとインデックス サイズを保護します。 これらの制限が検索に与える影響について、次に例を示します。
アイテムを検索しても結果が得られなかった場合は、そのアイテムが大きすぎる可能性があります。 クロール ログに、ファイルがクローラーがダウンロードできる最大サイズを超えたことを示す警告が表示されます。
If you search for text in an item and only get results from the first part of the text, the content processing component may have truncated the item because it exceeded some of item size limits. When the content processing component truncates an item, it indicates this by setting the managed property IsPartiallyProcessed to True. A warning will also show up in the Crawl Log, stating why the item was truncated.
アイテム サイズの制限を調整する場合は、この表の順番で行うことをお勧めします。
| 極限 | 最大値 | 制限の種類 | メモ |
|---|---|---|---|
| クロール コンポーネントでダウンロード可能なドキュメント サイズ |
64 MB (Excel ドキュメントの場合は 4 MB) |
しきい値 |
検索では、ドキュメントからメタデータとコンテンツが最大ドキュメント サイズに達するまでダウンロードされます。 残りのコンテンツはダウンロードされません。 検索では、ドキュメントのメタデータは必ずダウンロードされます。 You can change the default limit for the maximum document size. Do this by using Microsoft PowerShell cmdlets to change the Search service application property MaxDownLoadSize or MaxDownloadSizeExcel. MaxDownLoadSize doesn't impact the maximum size for Excel documents. Enter the value in megabytes. The maximum value for the maximum document size is 1024 MB, also for Excel documents. 最大ドキュメント サイズの上限を大きくすると、より多くのコンテンツにインデックスが付けられるため、より多くのディスク領域が必要になります。 |
| 解析されるコンテンツ サイズ |
200 万文字 |
境界 |
検索は、アイテムの添付ファイルを含む最大 200 万文字のコンテンツを解析した後、アイテムの解析を停止します。 検索では 1 つの項目とその添付ファイルの解析に最大 30 秒を使用するため、解析された実際の文字数がこの制限を下回る可能性があります。 検索が項目の解析を停止すると、項目は部分的に処理済みとしてマークされます。 解析されていないコンテンツは処理されないため、インデックスは作成されません。 |
| ワード ブレーカーによって生成される文字 |
1,000,000 |
境界 |
検索では、コンテンツが個々の単語 (トークン) に分割されます。 ワード ブレーカーは、アイテムの添付ファイルを含む、1 つのアイテムの最初の 1,000,000 文字からトークンを生成します。 検索では単語区切りで最大 30 秒を使用するため、処理された項目の実際の数がこの制限を下回る可能性があります。 残りのコンテンツは処理されないため、インデックスは作成されません。 |
| インデックス付きの管理プロパティ サイズ |
検索可能/クエリ可能な管理プロパティごとに 512 KB |
しきい値 |
この制限の種類は、"検索可能" または "クエリ可能" に設定されている管理プロパティの最大サイズの既定値です。 You can configure this limit by using PowerShell cmdlets and the schema object model to set the MP.MaxCharactersInPropertyStoreIndex attribute. 値はバイト単位で入力します。 この最大サイズの最大値は 2097152 バイトです。 この制限を増やす場合は、管理プロパティごとにより多くのデータのインデックス作成を有効にします。 管理プロパティごとのデータのインデックス処理量が増加すると、使用するディスク容量が増加し、検索システム全体の負荷が増加します。 |
| 取得可能な管理プロパティのサイズ |
管理プロパティごとに 16 KB |
しきい値 |
この制限の種類は、取得可能な管理プロパティの最大サイズの既定値です。 この制限を増やす場合は、管理プロパティごとにより多くのデータのインデックス作成を有効にします。 この制限を大きくすると、検索時に検索結果として、管理プロパティごとにより多くのデータを取得することもできます。 管理プロパティごとに、より多くのデータのインデックスを作成および取得すると、システム全体の負荷が増加し、より多くのディスク領域を使用することになります。 PowerShell コマンドレットとスキーマ オブジェクト モデルを使用して P.MaxCharactersInPropertyStoreForRetrieval 属性を設定すると、管理プロパティごとにこの制限を構成できます。 値はバイト単位で入力します。 この最大サイズの最大値は 2097152 バイトです。 この制限を増やす場合は、管理プロパティごとにより多くのデータのインデックス作成を有効にします。 この制限が増加すると、検索結果で管理プロパティごとに取得するデータも増加させられます。 それで、管理プロパティごとにインデックス処理および取得を行うデータ量が増加します。 |
| 並べ替え可能で絞り込み可能な管理プロパティのサイズ |
管理プロパティごとに 16 KB |
境界 |
この制限の種類は、並べ替え可能で絞り込み可能なマネージド プロパティの最大サイズです。 |
| トークン サイズ |
可変 |
境界 |
検索では、任意の長さのトークンにインデックスを付けることができます。 ただし、検索時にトークンの生成に使用されるワード ブレーカーがトークン長を制限できます。 ワード ブレーカーはコンテンツを単一の単語 (トークン) に分割する言語対応コンポーネントです。 カスタム ワード ブレーカーを作成することもできます。 そのため、トークン サイズの制限はワード ブレーカーに依存します。 次に、西洋言語のワード ブレーカーの制限を示します。 ワード ブレーカーは、トークンの最初の 1,000 文字しか分割対象として考慮せず、残りの文字は無視します。 ワード ブレーカーは、300 文字を超えるトークンを 300 文字を超えるトークンが存在しないように複数のトークンに分割します。 たとえば、612 文字のトークンは 2 つの 300 文字のトークンと 1 つの 12 文字のトークンに分割されます。 |
| 管理プロパティ 1 つあたりの一意のインデックス付きトークン数 |
1,000,000 |
しきい値 |
この制限の種類は、1 つのマネージド プロパティの検索インデックスに追加できる一意のトークンの最大数です。 この制限は変更できません。 制限を超えた場合、インデックスにはマネージド プロパティからの最初の 1,000,000 トークンが含まれており、ファイルは IsPartiallyProcessed プロパティを true に設定することで部分的に処理済みとしてマークされます。 例外: ACL 関連の管理プロパティが上限に達した場合、同管理プロパティからのトークンはインデックスに追加されません。 |
| アイテムへのアクセス権を持つ重複しないユーザー数または AD セキュリティ グループ数 |
1,000,000 |
しきい値 |
アイテムへのアクセス権を持つ重複しないユーザーまたは AD セキュリティ グループの数が 1,000,000 を超える場合、いずれのユーザーもそのアイテムを検索できません。 そのようなアイテムは、セキュリティ/コンプライアンス センターでの電子情報開示クエリの一部としてのみ返されます。 |
検索: 辞書の制限
辞書の制限は、メモリ、コンテンツ処理の効率、およびクエリ結果を保護します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| 類義語辞典のエントリ数 |
100 万個 |
サポートされている |
類義語辞典にはクエリ用語の同義語が含まれています。 このテスト済み制限を超えると、メモリの使用量が増加し、クエリの応答時間が長くなる可能性があります。 |
| カスタムのエンティティ抽出辞書のエントリ数 |
100 万個 |
サポートされている |
このテスト済み制限を超えると、メモリの使用量が増加し、インデックス付けが遅くなり、クエリの応答時間が長くなる可能性があります。 |
| カスタムの検索辞書のエントリ数 |
テナントごとに 5,000 用語 |
境界 |
この制限の種類では、クエリのスペル修正と会社の抽出のために包含辞書と除外辞書に許可される用語の数が制限されます。 この制限を超える用語を用語ストアに保存できますが、検索ではテナントごとに 5,000 用語しか使用されません。 |
検索: スキーマの制限
スキーマの制限は、メモリ リソースを保護し、管理操作のオーバーヘッドを受け入れ可能なレベルに維持します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| クロールされたプロパティ |
Search Service アプリケーションごとに 500,000 個 |
サポートされている |
クロールが、クロールされたプロパティとして表現されるアイテムのコンテンツとメタデータ。 これらのクロールされたプロパティを管理プロパティにマップすることができます。 クロールされたプロパティの数がこのサポートされている制限を超えると、インデックス作成速度が低下します。 |
| 管理プロパティ |
Search service アプリケーションごとに 50,000 個 |
サポートされている |
検索ではクエリ内で管理プロパティが使用されます。 クロールされたプロパティは管理プロパティにマップされます。 管理プロパティのサポートされた制限を超えると、インデックス付けの速度が低下します。 |
| 管理プロパティ マッピング |
管理プロパティごとに 100 個 |
サポートされている |
クロールされたプロパティは管理プロパティにマップすることができます。 この制限を超えると、クロールの速度とクエリのパフォーマンスが低下する可能性があります。 |
| 管理プロパティごとの値 |
1,000 |
境界 |
管理プロパティには同じ型の複数の値を使用できます。 この制限の種類は、ドキュメントごとのマネージドマルチ値管理プロパティあたりの値の最大数です。 この制限を超えると、残りの値が破棄されます。 |
| 認識されるメタデータ プロパティ |
クロールされたアイテムごとに 100,000 個 |
サポートされている |
この制限の種類は、クロール コンポーネントがアイテムをクロールするときに決定できるメタデータ プロパティの最大数です。 These metadata properties can be mapped or used for queries. クロールされたプロパティ数がこの値に近づくと、クロール速度が低下する可能性があります。 |
検索: クロールの制限
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| 開始アドレス |
コンテンツ ソースごとに 500 個 |
サポートされている |
|
| マシン ホスト名の文字数 |
15 文字 |
しきい値 |
NetBIOS は、マシン ホスト名の最大文字数をこの値に制限します。 |
| クロール データベース |
Search Service アプリケーションごとに 15 個 |
サポートされている |
検索: クエリと結果の制限
クエリと結果の制限により、大規模なクエリ式を実行して大きな結果セットを返すのを防ぐ検索エンジンが保護されます。 検索エンジンが大規模なクエリ式を実行して大きな結果セットを返すのを防ぐと、サービス拒否 (DoS) 攻撃を防ぎ、結果がタイムリーに返されるようにします。 さらに結果を取得する必要がある場合は、ページングを使用することをお勧めします。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| キーワード クエリ言語を使用したクエリのテキスト長 |
4 KB (4,096 文字) |
サポートされている |
この制限の種類は、探索クエリを除き、キーワード クエリ言語を使用して構築されたクエリの最大テキスト長のテスト済みおよび既定値です。 検出クエリの場合は、16 KB (16,384 文字) が既定の最大値です。 500 行 |
| SharePoint のホームページでのクエリのテキスト長 |
16 KB (16,384 文字) |
サポートされている |
この制限が適用されるのは、SharePoint Server 2019 パブリック プレビューのみです。 この制限の種類は、SharePoint ホーム ページで使用されるクエリの最大テキスト長のテスト済みおよび既定値です。 最大テキスト長の既定値を 20 KB (20,480) の境界まで増やすことができます。 |
| サポートされている |
500 行 |
サポートされる |
この制限の種類は、検出クエリを除き、結果セット内の行の最大数のテスト済みおよび既定値です。 検出クエリの場合は、10,000 行が既定値です。 結果セット全体を表示するには、より多くのページング クエリを発行します。 You can change the value for the maximum number of rows in a result set by using PowerShell cmdlets to change the Search service application property MaxRowLimit. MaxRowLimit defines the maximum value of the query property RowLimit and the Discovery query property RowLimit. RowLimit defines the number of rows each page contains in a result set. You can increase MaxRowLimit up to 10,000 rows, this is the supported boundary. |
| 結果の削除 |
無制限 |
サポートされている |
|
| 検索アラート クォータ |
Search Service アプリケーションごとに 100,000 アラート |
サポートされている |
エンド ユーザーは、クエリの結果セットの検索アラートを設定できます。 結果が変更または更新されると、検索によってエンド ユーザーに通知されます。 この制限の種類は、エンド ユーザー クエリ (75%) とアラート クエリ (25%) が混在するSearch Service アプリケーションのテスト済み制限です。 アラート クエリのみの Search Service アプリケーションの制限は 400,000 アラートです。 これらの制限は、1 秒あたりのクエリ数 (QPS) が 5 のシステムに基づいています。 |
検索: ランク付けの制限
ランク付けの制限は、アプリケーション サーバー メモリ、クエリ待機時間、およびインデックス サイズを保護します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| ランク付けモデル |
テナントごとに 1,000 個 |
境界 |
この制限に近づくと、システム全体のパフォーマンスに悪影響が出る可能性があります。 |
| ランク付けに使用する固有のコンテキスト |
ランク モデルごとに固有のコンテキストは 15 個 |
境界 |
この制限の種類はランク モデルごとの一意のコンテキストの最大数です。 |
| 優先するページ |
Search service アプリケーションごとに最優先するページ 1 つおよび 2 番目と 3 番目に優先するページ最小限数 |
サポートされている |
2 番目と 3 番目に優先するページ数は目的の関連性を得られるだけのできる限り少ない数を使用します。 境界は、各 Search service アプリケーションの関連性順位ごとに 200 個の優先ページになります。 このページ数を増やしても目的の関連性が得られないことがあります。 最優先するページとしてキー サイトを 1 つ追加します。 2 番目または 3 番目に優先するページとしてキー サイトを 1 つずつ追加します。 追加するたびに関連性を評価して目的の関連性効果が得られるかどうか確認してください。 |
検索: インデックスの制限
インデックスを制限すると、インデックスが境界を越えたり、使用可能なリソース数を超えたりしなくなります。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| インデックス内の固有の用語 |
2^31 (>20 億個の用語) |
境界 |
この制限の種類は Search Service アプリケーションのインデックス内に存在可能な固有の用語の最大数です。 |
| ユーザー定義のフルテキスト インデックス |
10 |
境界 |
この制限の種類は、フルテキスト インデックスの最大数です。 |
| インデックス付きのアイテム |
インデックス パーティションごとに 2,000 万個 |
サポートされている |
SharePoint Foundation 2013 では、インデックス処理するアイテムの最大数は、1 インデックス パーティションあたり 200 万アイテムです (2016 年 6 月公開の更新プログラムを適用する前)。 サーバーのメモリ量に関連してインデックス付き項目の数が多い場合、この不均衡はクエリ応答時間に悪影響を及ぼします。 |
User Profile Service の制限
以下の表に、User Profile Service の推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| ユーザー プロファイル |
サービス アプリケーションごとに 2,000,000 個 |
サポートされている |
User Profile Service アプリケーションでは、すべてのソーシャル機能を備えたユーザー プロファイルを最大 200 万個までサポートできます。 この値は、ディレクトリ サービスからユーザー プロファイル ストアにインポートできるプロファイルの数を表し、また、1 つの User Profile Service アプリケーションで、ソーシャル機能のパフォーマンスを低下させることなくサポートできるプロファイルの数を示します。 |
| ソーシャル タグ、メモ、および評価 |
ソーシャル データベースごとに 500,000,000 個 |
サポートされている |
ソーシャル データベースでは、パフォーマンスが大幅に低下することなく、最大 5 億個のソーシャル タグ、ノート、および評価がサポートされています。 ただし、上限値では、バックアップと復元など、データベースのメンテナンス操作のパフォーマンスが低下することがあります。 |
コンテンツ展開の制限
以下の表に、コンテンツ展開の推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| 複数のパスで実行されるコンテンツ展開ジョブ |
20 |
サポートされる |
同じソース コンテンツ データベース内のサイト コレクションに接続されているパスでジョブを同時に実行する場合、データベースでデッドロックが発生するリスクが高くなります。 For jobs that must run concurrently, we recommend that you move the site collections into different source content databases. 注: 同じパスでジョブを同時に実行することはできません。 コンテンツのデプロイにSQL Serverスナップショットを使用している場合、各パスによってスナップショットが作成されます。 このスナップショットパスの関連付けにより、ソース データベースの I/O 要件が増加します。 詳細については、「展開のパスとジョブについて」を参照してください。 |
ブログの制限
以下の表に、ブログの推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| ブログ投稿 |
サイトごとに 5,000 件 |
サポートされている |
ブログの投稿の最大数はサイトごとに 5,000 件です。 |
| コメント |
投稿ごとに 1,000 件 |
サポートされている |
コメントの最大数は投稿ごとに 1,000 件です。 |
Business Connectivity Services の制限
以下の表に、Business Connectivity Services の推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| ECT (メモリ内) |
Web サーバーごと (テナントごと) に 5,000 個 |
境界 |
1 つの Web サーバーで同時点にメモリにロードできる外部コンテンツ タイプ (ECT) 定義の合計数です。 |
| 外部システム接続 |
Web サーバーごとに 500 個 |
境界 |
特定の時点でのアクティブ/オープン外部システム接続の数。 既定値は 200 です。境界は 500 です。 この制限は、外部システムの種類 (データベース、.NET アセンブリなど) に関係なく、Web サーバー スコープで適用されます。既定の最大値は、接続の数を制限するために使用されます。 アプリケーションでは、実行コンテキストを使用して、より大きな制限を指定できます。境界では、既定値を尊重しないアプリケーションでも最大値が適用されます。 |
| 要求ごとに返されるデータベース アイテム |
データベース コネクタごとに 2,000 個 |
しきい値 |
データベース コネクタから返すことのできる要求ごとのアイテムの数です。 データベース コネクタでは、ページごとに返される結果の数を制限するために、既定の最大値 2,000 が使用されます。 アプリケーションでは、実行コンテキストを使用して、より大きな制限を指定できます。Absolute Max では、既定値を尊重しないアプリケーションでも最大値が適用されます。 この制限値の境界は、1,000,000 個です。 |
| 応答待ち時間 |
600 秒 |
しきい値 |
外部データ コネクタによって使用される、要求ごとのタイムアウトです。 既定値は 180 秒ですが、アプリケーションを構成して、最大 600 秒までの大きな値を指定できます。 |
| サービス応答サイズ |
150,000,000 バイト |
しきい値 |
外部データ コネクタが戻すことのできる、要求ごとのデータ量の上限です。 既定値は 3,000,000 バイトですが、アプリケーションを構成して、最大 150,000,000 バイトまでの大きな値を指定できます。 |
| フィルター記述子 (ストア内) |
ECT メソッドごとに 200 個 |
境界 |
ECT メソッドごとのフィルター記述子の数は最大 200 個です。 |
| ECT 識別子 (ストア内) |
ECT ごとに 20 個 |
境界 |
ECT ごとの識別子の数は最大 20 個です。 |
| データベース アイテム |
要求ごとに 1,000,000 個 |
しきい値 |
データベース コネクタが戻すことのできる、要求ごとのアイテム数の既定の最大値は 2,000 です。絶対最大値は 1,000,000 です。 The default max is used by the database connector to restrict the number of results that can be returned per page. アプリケーションでは、実行コンテキストを使用して、より大きな制限を指定できます。absolute max では、インデックス作成などの既定値を考慮しないアプリケーションでも、許可される最大値が適用されます。 |
ワークフローの制限
以下の表に、ワークフローの推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| ワークフローの延期のしきい値 |
15 |
しきい値 |
15 is the maximum number of workflows allowed to be executing against a content database at the same time, excluding instances that are running in the timer service. このしきい値に達すると、ワークフローをアクティブ化するための新しい要求は、後でワークフロー タイマー サービスによって実行されるようにキューに入れられます。 タイマー以外の実行が完了すると、新しい要求はこのしきい値に対してカウントされます。 この制限は、Set-SPFarmConfig PowerShell コマンドレットを使用して構成できます。 For more information, see Set-SPFarmConfig. 注: この制限は、進行中のワークフロー インスタンスの合計数を指すわけではありません。 代わりに、処理されているインスタンスの数です。 この制限値を大きくすると、ワークフロー タスクの開始と完了のスループットが増加しますが、コンテンツ データベースとシステム リソースに対する負荷も増加します。 |
| ワークフロー タイマーのバッチ サイズ |
100 |
しきい値 |
ワークフロー タイマー ジョブの各実行で収集され、ワークフローに配布されるイベントの数です。 PowerShell を使用して構成できます。 より多くのイベントを許可するために、SharePoint Foundation ワークフロー タイマー サービスのより多くのインスタンスを実行できます。 |
| ワークフローの関連付け |
リストごとに 100 個 |
サポートされている |
この制限を超えると、100 を超える関連付けとその状態列に対して大量のデータが読み込まれるため、ブラウザーのパフォーマンスが低下します。 |
| ワークフロー インスタンスを開始するために一括作成または一括アップロードできるリスト アイテムあるいはドキュメント |
5,000 アイテム |
サポートされている |
1 回の一括アップロードで最大 5,000 アイテムが作成される場合、すべてのワークフロー アクティブ化イベントがアイテム作成時のワークフローの関連付けで処理されることがテストで確認されています。 この制限を超えると、ワークフローの開始がタイムアウトになる場合があります。 |
| Web サイトごとの発行ワークフロー定義 |
Web サイトごとに 1,000 個 |
サポートされている |
Web サイトごとの発行ワークフロー定義の数は、サポートされている最大数で 1,000 個です。 |
| サイトごとのワークフローの関連付けの合計 |
サイトごとに 1,799 個 |
境界 |
サービス バスでは、範囲ごとに最大 1,799 個のサブスクリプションがサポートされます。 この最大値には、発行済みの関連付けと未発行の関連付けの両方の合計が含まれます。 |
| ワークフロー定義 (xaml) の最大サイズ |
5,120 KB |
境界 |
サイズ制限を超える xaml ファイルを発行しようとすると失敗します。 |
| xaml におけるワークフローのサブステップの最大震度 (ワークフローの複雑さ) |
121 レベル |
境界 |
xaml のノード深度には 125 というハード制限があります。 121 レベルという最大値は、SharePoint Designer が自動的に挿入する既定の動作 (ステージ、シーケンスなど) があるためです。 |
| Web サーバーごとの 1 秒あたりのワークフロー インスタンス アクティブ化 |
1 秒ごとに 6 個 |
境界 |
テストでは、SharePoint Web サーバーが 1 秒あたり最大 6 つのワークフロー インスタンスをアクティブ化できることを確認しました。 この数は累積的なので、ファーム内の Web サーバーの数に比例します。 たとえば、2 つの Web サーバーで 1 秒あたり 12 個のワークフロー インスタンスをアクティブ化でき、3 つの Web サーバーで 18 個のワークフロー インスタンスをアクティブ化できます。 |
| Web サーバーごとの 1 秒あたりの SharePoint ワークフローからのその他の呼び出し |
1 秒ごとに 60 個 |
サポートされる |
テストでは、SharePoint Web サーバーが SharePoint ワークフローから 1 秒あたり最大 60 回の rest 呼び出しを効果的に処理できることを確認しました。 このレベルのボリュームを超える場合は、負荷分散された Web サーバーを SharePoint ファームに追加することをお勧めします。 テストでは、1 つの Web サーバーに対して 1 秒あたり 120 回の休止呼び出しが発生し、CPU 使用率が 90 から 100% 維持されました。 2 つ目の Web サーバーを追加すると、両方のサーバーで CPU 使用率が 30 から 40% に低下しました。 3 つ目の Web サーバーを追加すると、1 秒あたり 180 回の呼び出しの処理が有効になり、3 台すべてのサーバーで CPU 使用率が 30 から 40% になります。 このテストに使用されたサーバーは、それぞれ 16 個のコア プロセッサと 24 GB の RAM を備えた Hyper-V 仮想マシンでした。 |
| ワークフロー変数の値のサイズ |
256 KB |
境界 |
1 つのワークフロー変数に格納できるデータの最大量は 256 KB です。 この制限を超えると、ワークフロー インスタンスが終了します。 |
| インデックスの付いていないフィールドへのワークフローの参照に対する最大リスト サイズ |
リスト ビューごとに 5,000 個のアイテム |
しきい値 |
この制限はビューの最大サイズの制限によるものです。 この制限を超えると、非管理ユーザーに対するインデックスのないフィールドへのワークフロー参照は失敗します。 このしきい値に達した場合、ワークフローでフィールドに対する参照が正常に実行できるように、フィールドのインデックスを作成する必要があります。 |
| 自動起動ワークフローの関連付けの最大リスト サイズ |
リストごとに 1000 万個のアイテム |
サポートされている |
テストでは、リスト サイズが 100 万項目に拡大しても、自動開始ワークフロー関連付けのパフォーマンスが影響を受けないことを確認しました。 Because response time doesn't change as list size scales, the effective limit is the same as the maximum number of items in a non-workflow list. |
管理メタデータ用語ストア (データベース) の制限
以下の表に、管理メタデータ用語ストアの推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| 1 つの用語ストアで入れ子にする用語の最大レベル数 |
7 |
サポートされる |
用語セット内では、用語を階層構造で表すことができます。 1 つの用語セットには、最大 7 レベルの用語 (親用語とその下に 6 レベルまで入れ子にした用語) を含めることができます。 |
| 1 つの用語ストア内の用語セットの最大数 |
1,000 |
サポートされている |
1 つの用語セットに最大 1,000 個までの用語セットを含めることができます。 |
| 1 つの用語セット内の用語の最大数 |
30,000 |
サポートされる |
1 つの用語セット内の用語の最大数は 30,000 個です。 注: シノニムや翻訳など、同じ用語の追加ラベルは個別の用語としてカウントされません。 |
| 1 つの用語ストア内のアイテムの合計数 |
1,000,000 |
サポートされる |
アイテムとは、用語または用語セットです。 用語と用語セットの数の合計は、1,000,000 を超えることはできません。 シノニムや翻訳など、同じ用語の追加ラベルは個別の用語としてカウントされません。 注: 用語ストアでは、用語セットの最大数と用語の最大数の両方を同時に使用することはできません。 |
| バリエーション ラベルの数 |
用語ストアごとに 209 個 |
サポートされている |
用語ストアごとのバリエーション ラベルの最大数は 209 個です。 |
| 管理ナビゲーション用語セット内の用語数 |
2,000 |
サポートされている |
管理ナビゲーション用語セット内でサポートされている用語の最大数は 2,000 個です。 |
| 管理ナビゲーション用語セット内の直接の子の用語数 |
300 |
サポート |
管理ナビゲーション用語セット内でサポートされている直接の子の用語の最大数は 300 個です。 |
Visio Services の制限
以下の表に、Visio Services in SharePoint Server 2016 のインスタンスの推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| しきい値 |
50 MB |
しきい値 |
Visio Services のメモリの占有領域が増加します。 ファイル サイズが大きくなると、以下の影響が発生します。 1 秒あたりのアプリケーション サーバー要求数が減少します。 CPU 使用率が増加します。 1 秒あたりのアプリケーション サーバー要求数が減少します。 全体的な待機時間が増加します。 SharePoint ファームのネットワーク負荷が増加します。 |
| しきい値 |
120 秒 |
しきい値 |
CPU とメモリの可用性が低下します。 再計算タイムアウトの時間を長くすると、以下の影響があります。 CPU とメモリの可用性が低下します。 1 秒あたりのアプリケーション要求数が減少します。 全ドキュメントの平均待機時間が増加します。 再計算タイムアウトの時間を短くすると、以下の影響があります。 表示できる図面の複雑さが低下します。 1 秒あたりの要求数が増加します。 全ドキュメントの平均待機時間が減少します。 |
| しきい値 |
最小キャッシュ時間: 0 - 24 時間 |
しきい値 |
最小キャッシュ時間は、データに接続された図面に適用されます。 これは、現在の図面がキャッシュから削除されるまでの最短時間を指定します。 [最小キャッシュ期間] を低い値に設定するとスループットが低下し、待機時間が長くなります。これは、キャッシュを無効にすると、Visio が頻繁に再計算され、CPU とメモリの可用性が低下するためです。 |
| しきい値 |
最大キャッシュ時間: 0 - 24 時間 |
しきい値 |
最大キャッシュ時間は、データに接続されていない図面に適用されます。 この値は、現在の図面をメモリに保持する時間を指定します。 最大キャッシュ時間を長くすると、よく要求される図面の待機時間が短くなります。 ただし、Max Cache Age を高い値に設定すると、キャッシュされていない項目の待機時間が長くなり、スループットが低下します。これは、既にキャッシュされている項目が消費され、使用可能なメモリが減るためです。 |
PerformancePoint Services の制限
以下の表に、SharePoint Server 2016 の PerformancePoint Servicesの推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| セル |
Excel Services データ ソースを呼び出す PerformancePoint スコアカードには、クエリごとのセル数 1,000,000 個以内という制限があります。 |
境界 |
15 列、60,000 行 |
| 列と行 |
15 列、60,000 行 |
しきい値 |
Excel ブックをデータ ソースとして使用する PerformancePoint ダッシュボード オブジェクトをレンダリングするときの列と行の最大数。 行数は列数に応じて変動します。 |
| SharePoint リストに対するクエリ |
15 列、5,000 行 |
サポートされている |
SharePoint リストをデータ ソースとして使用する PerformancePoint ダッシュボード オブジェクトをレンダリングする場合の列と行の最大数です。 行数は列数に応じて変動します。 |
| SQL Server データ ソースに対するクエリ |
15 列、20,000 行 |
サポートされる |
The maximum number of columns and row when rendering any PerformancePoint dashboard object that uses a SQL Server table data source. 行数は列数に応じて変動します。 |
Word Automation Services の制限
以下の表に、Word Automation Services の推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| 入力ファイルのサイズ |
512 MB |
境界 |
Word Automation Services で処理できる最大ファイル サイズです。 |
| 変換を開始する間隔 (分) |
1 分 (推奨) しきい値 59 分 (境界) |
しきい値 |
この設定値は、Word Automation Services のタイマー ジョブを実行する時間間隔を指定します。 この数値を小さくするほど、タイマー ジョブが高速に実行されます。 テストでは、このタイマー ジョブを 1 分に 1 回実行することが最も便利であることを示しています。 |
| 変換プロセスごとの開始する変換の数 |
開始する変換の数は、Word Automation Services のスループットに影響します。 |
しきい値 |
開始する変換の数は、Word Automation Services のスループットに影響します。 これらの値が推奨レベルより高く設定されている場合、一部の変換項目が断続的に失敗し始め、ユーザーのアクセス許可が期限切れになる可能性があります。 ユーザー権限は、変換ジョブが開始されてから 24 時間で期限切れになります。 |
| 変換ジョブのサイズ |
100,000 個の変換アイテム |
サポートされている |
1 つの変換ジョブには 1 つ以上の変換アイテムが含まれ、それぞれのアイテムは、SharePoint で 1 つの入力ファイルについて実行される 1 回の変換を表します。 変換ジョブが開始されると (ConversionJob.Start メソッドを使用して)、変換ジョブとすべての変換項目が、Word Automation Services データベースにジョブを格納するアプリケーション サーバーに転送されます。 変換項目の数が多い場合、Start メソッドの実行時間とアプリケーション サーバーに送信されるバイト数の両方が増加します。 |
| アクティブな変換プロセスの合計数 |
N-1 (N は各アプリケーション サーバーにあるコアの数) |
しきい値 |
1 つのアクティブな変換プロセスによって、1 つのプロセシング コアが使用されます。 そのため、お客様は、アプリケーション サーバーに処理コアがあるよりも多くの変換プロセスを実行しないでください。 変換タイマー ジョブおよびその他の SharePoint アクティビティも、時折プロセシング コアを使用することが必要になります。 変換タイマー ジョブおよび SharePoint で使用できるように、常に 1 つのコアを未使用にしておくことをお勧めします。 |
| Word Automation Services データベースのサイズ |
200 万個の変換アイテム |
サポートされる |
Word Automation Services では、変換アイテムの永続的キューをデータベース内に維持します。 変換要求ごとに 1 つ以上のレコードが生成されます。 Word Automation Services ではデータベースからレコードが自動的に削除されないため、メンテナンスなしでデータベースが無期限に拡張される可能性があります。 管理者は、PowerShell コマンドレット Remove-SPWordConversionServiceJobHistory を使用して、変換ジョブの履歴を手動で削除できます。 詳細については、「Remove-SPWordConversionServiceJobHistory」を参照してください。 |
Machine Translation Service の制限
以下の表に、Machine Translation Service の推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| バイナリ ファイルの入力ファイル サイズ |
ファイルごとに 524,288 KB |
しきい値 |
制限より大きなファイルは、転送および処理にかかる時間が長くなり、サービスのスループットが低下します。 |
| テキスト ファイルの入力ファイル サイズ |
ファイルごとに 15,360 KB |
しきい値 |
制限より大きなファイルは、翻訳するテキストが多すぎるため、サービスのスループットが低下します。 |
| Microsoft Word 文書の最大文字数 |
文書ごとに 10,000,000 字 |
しきい値 |
制限より文字数の多い文書は、翻訳するテキストが多すぎるため、サービスのスループットが低下します。 |
| 同時に処理できる翻訳プロセスの合計 |
5 |
しきい値 |
制限を超えるプロセスを使用しても、一度に翻訳できるテキストの量に制限があるため、スループットは向上しません。 多くのプロセスを使用すると、サーバー リソースに対する要求が増えます。 |
| 翻訳と翻訳の間の遅延 |
59 分 |
しきい値 |
制限よりも間隔をあけて翻訳を開始すると、ドキュメントの翻訳にかかる時間が長くなりすぎ、キューに入る翻訳の数が多くなりすぎることがあります。 |
| 翻訳プロセスごとの翻訳の数 |
プロセスごとに 1,000 個 |
しきい値 |
制限よりも多くの翻訳を開始すると、タイムアウト期間の前に処理できないため、タイムアウトが原因で翻訳が失敗します。 |
| 同時に要求できる翻訳要求の最大数 |
300 |
しきい値 |
300 個を超える翻訳要求を同時に要求すると、タイムアウト期間よりも長い間、要求がキューに入るために、翻訳がタイムアウトになる場合があります。 |
| 翻訳ジョブごとのファイル |
100,000 ファイル |
サポートされている |
制限を超えるファイル数のジョブを送信すると、ジョブの送信時間および処理時間が長くなり過ぎます。 |
| Machine Translation Service のデータベース サイズ |
1,000,000 ファイル |
サポートされている |
データベース内のファイル数の上限よりもデータベースが大きくなると、ジョブのキューを保持する操作が遅くなります。 |
Office Online Service の制限
The following table lists the recommended guidelines for Office Online. Office client application limits also apply when an application is running as a web app.
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| キャッシュ サイズ |
100 GB |
しきい値 |
コンテンツ データベースの一部として作成されたドキュメントのレンダリングに使用できる領域です。 既定では、ドキュメントのレンダリングに使用できるキャッシュは 100 GB です。 使用可能なキャッシュを増やすことはお勧めしません。 |
| レンダリング |
アプリケーション サーバーごとの (最大 8 個のコアの) CPU コアごとに、ドキュメントごとに毎秒 1 回 |
境界 |
アプリケーション サーバーにある "一般的な" ドキュメントに対して一定時間内に実行できるレンダリングの測定済み平均回数です。 |
| しきい値 |
ドキュメントごとに 8 個 |
しきい値 |
OneNote merges combine changes from multiple users who are co-authoring a notebook. すでに制限を超える数の結合が同時に処理中である場合には、競合ページが生成され、ユーザーが手動で結合を実行することが必要になります。 |
Project Server の制限
以下の表に、Project Server の推奨ガイドラインを示します。 Project Server の計画方法の詳細については、「Planning and architecture for Project Server 2010」を参照してください。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| プロジェクト時間の最終時刻 |
日付: 2149 年 12 月 31 日 |
境界 |
プロジェクト 計画は、日付 12/31/2149 を超えて延長することはできません。 |
| プロジェクト計画ごとの成果物 |
1,500 個の成果物 |
境界 |
プロジェクト 計画には、1,500 個を超える成果物を含めることはできません。 |
| 1 つのビュー内のフィールドの数 |
256 |
境界 |
ユーザーは、Project Web Appで定義したビューに 256 を超えるフィールドを追加することはできません。 |
| ビューのフィルター内の句の数 |
50 |
境界 |
ユーザーは、50 を超える句が含まれるビューにフィルターを追加できません。 |
SharePoint アプリの制限
以下の表に、SharePoint 用アプリケーションの推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| Access/SharePoint アプリの最大パッケージ サイズ |
100 Mb |
境界 |
SQL Azure 上の Access アプリ データベースの最大サイズ > [!注]> Access では、アプリ パッケージの作成時にデータベースが圧縮されるため、アプリ パッケージには 100 MB を超えるデータが含まれる場合があります。 |
| SQL Azure 上の Access アプリ データベースの最大サイズ |
1 GB |
境界 |
SharePoint で作成された各 Access アプリは、SQL Azureにデータベースを作成します。 1 GB は SQL Azure 上のデータベース ストレージに対する制限です。 オンプレミスのインストールでは、管理者が関連付けられている SQL データベースのサイズを制御します。 |
| [ライセンスの管理] ページに表示されるアプリ |
2,000 |
境界 |
[ライセンスの管理] ページには、最大 2,000 個のアプリ (ストアから購入) を表示できます。 引き続き、アプリがインストールされているサイトの [すべてのサイト コンテンツ] ページに移動し、[ライセンス] をクリックするか、Marketplace Search を使用してアプリを検索することで、任意のアプリのライセンスを管理できます。 |
| テナントごとのアプリ ライセンス数 |
1,000,000 |
サポートされている |
1 つの SharePoint 展開 (Microsoft 365 のオンプレミスまたは SharePoint) でサポートされるライセンスの最大数 (ストアからのアプリの購入)。 この制限を超えると、パフォーマンスが著しく低下する場合があります。 |
| [アプリの追加] ページに表示されるアプリの数 |
240 |
境界 |
この制限に達すると、最初の 240 個のアプリだけが表示され、検索してアプリを見つけるように促すメッセージが表示されます。 |
| アプリ ライセンスごとのマネージャー数 |
30 |
境界 |
ライセンスを管理できるのは 30 人だけです。 ライセンス マネージャーはユーザーの追加や削除、またはライセンスの削除を行うことができます。 |
| ユーザーに割り当てられたアプリ ライセンスのうち、そのユーザーに表示される数 |
2,000 |
境界 |
2,000 を超えるライセンスがユーザーに割り当てられている場合、そのユーザーは既定の [アプリの追加] ビューに アプリを 表示しなくなります。 その代わりに、アプリ カタログまたは SharePoint ストアを検索するように促すメッセージが表示されます。 |
| 1 人のユーザーに表示される社内用のカタログ内のアプリの数 |
500 |
境界 |
企業カタログから 500 を超えるアプリを 1 人のユーザーが使用できる場合、そのユーザーは既定の [ アプリの追加] ビューにアプリを表示しなくなります。 その代わりに、アプリ カタログまたは SharePoint ストアを検索するように促すメッセージが表示されます。 |
Distributed Cache Service の制限
以下の表に、Distributed Cache Service の推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| キャッシュ ホストごとのフォローできるエンティティ (ユーザー、ドキュメント、サイト、およびハッシュタグ) の数 |
400,000 |
サポートされている |
分散キャッシュ サービスに 16 GB の RAM が割り当てられている分散キャッシュ ホスト上の 1 人のユーザーが続くエンティティの合計数は 400,000 です。 |
| クラスター内のキャッシュ ホストの数 |
16 |
境界 |
1 つの分散キャッシュ クラスターがサポートできるキャッシュ ホストの総数は 16 台です。 |
| キャッシュ ホスト専用メモリの最大容量 |
16 GB |
境界 |
クラスター内の任意の 1 つのキャッシュ ホスト上で分散キャッシュ サービス専用とすることができるメモリ容量の合計は 16 GB です。 |
その他の制限
以下の表に、他のセクションに記載されていないサービスおよび機能の制限および推奨ガイドラインを示します。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| デバイス チャネルごとのユーザー エージェントの部分文字列の数 |
150 |
境界 |
モバイル デバイス チャネルごとのユーザー エージェントの部分文字列の最大数は 150 個です。 |
| 電子情報開示ケースごとの SharePoint ソースの数 |
100 |
境界 |
電子情報開示ケースに追加できる SharePoint ソースの最大数は 100 個です。 |
| 電子情報開示ケースごとの Exchange ソース (メールボックス) の数 |
1,500 |
境界 |
電子情報開示ケースごとの Exchange ソース (メールボックス) の最大数は 1,500 個です。 |
| 電子情報開示クエリの最大サイズ |
16 K 文字または 500 キーワード |
境界 |
電子情報開示クエリのサイズは、500 キーワードまたは 16,000 文字のうち、どちらか最初に到達するほうに制限されます。 |
関連記事
SharePoint Server 2016 のハードウェア要件およびソフトウェア要件