Configuration Manager サイトのサイズ設定とパフォーマンスに関する FAQ

少なくとも 2 つの異なるボリューム上のConfiguration Manager受信トレイとSQL Server ファイルを分離します。 この分離により、実行するさまざまな種類の I/O に対してクラスター割り当てサイズを最適化できます。

サイト サーバーの受信トレイをホストしているボリュームには、4K または 8K の割り当てユニットで NTFS を使用します。 ReFS は、小さなファイルでも 64k を書き込みます。 Configuration Managerには多数の小さなファイルがあるため、ReFS では不要なディスク オーバーヘッドが発生する可能性があります。

SQL Serverデータベース ファイルを含むディスクの場合は、NTFS 形式または ReFS 形式の 64K 割り当てユニットを使用します。

ソリッド ステート ドライブ (SSD) と Azure Premium Storageの最新のアレイでは、ディスク数が少ない 1 つのボリュームで高い IOPS を実現できます。 通常、追加のスループットではなく、追加のストレージ用にドライブをアレイに追加します。 物理スピンドル ベースのディスクを使用している場合は、1 つのボリュームで生成できるよりも多くの IOPS が必要になる場合があります。 推奨される合計 IOPS とディスク領域の 60% を .mdf ファイルに割り当て、 .ldf ファイルに 20%、ログとデータの一時ファイルに 20% を割り当てる必要があります。 .ldf ファイルと一時ファイルはすべて、割り当てられた IOPS の 40% (20% + 20%) の単一ボリューム上に存在できます。

SQL Server 2016 SQL Serverより前のバージョンでは、既定で作成される一時データ ファイルは 1 つだけです。 ロックをSQL Serverし、1 つのファイルへのアクセスを待機しないように、さらに作成する必要があります。 コミュニティの意見は、作成する一時データ ファイルの数が 4 から 8 の間で異なります。 テストでは、4 から 8 の差がほとんどないため、 同じサイズ の 4 つの一時データ ファイルを作成できます。 tempdb データ ファイルは、データベース全体のサイズの最大 20 ~ 25% である必要があります。

構成可能な場合は、書き込み操作の場合は RAID コントローラー メモリを 70% 割り当て、読み取り操作では 30% に設定します。 一般に、サイト データベースには RAID 10 アレイ構成を使用します。 RAID 1 は、I/O 要件が低い小規模サイトや高速 SSD を使用する場合にも使用できます。 ディスク アレイが大きい場合は、障害が発生したディスクを自動的に置き換えるスペア ディスクを構成します。

例: 物理ディスクを持つ物理マシン

併置されたサイト サーバーと 100,000 クライアントを含むSQL Serverのサイズ設定ガイドラインは、サイト サーバーの受信トレイの場合は 1200 IOPS、SQL Server ファイルの場合は 5000 IOPS です。

結果として得られるディスク構成は次のようになります。

1. 推奨されるスペア ディスクは含まれません。
2. この値は、 ディスク構成の例からの値です。

ハードウェア リソース (CPU コアとパススルー ストレージ) が仮想マシン (VM) 専用の 100% である場合、Hyper-V は物理サーバーに同様のパフォーマンスを提供します。 固定サイズの .vhd または .vhdx ディスク ファイルを使用すると、I/O パフォーマンスへの影響が最小限の 1 ~ 5% になります。 動的に拡張する .vhd または .vhdx ディスク ファイルを使用すると、Configuration Manager ワークロードの I/O パフォーマンスへの影響が最大 25% 発生します。 ディスクを動的に拡張する必要がある場合は、アレイにさらに 25% の IOPS パフォーマンスを追加して補正します。

Configuration Manager サイト サーバーまたは VM 内のSQL Serverを実行する場合は、VM OS とデータ ドライブから Hyper-V ホスト OS ドライブを分離します。

VM の最適化の詳細については、「 パフォーマンスチューニング Hyper-V サーバー」を参照してください。

例: Hyper-V VM ベースのサイト サーバー

150,000 クライアントを持つ併置されたサイト サーバーとSQL Serverのサイズ設定ガイドラインは、サイト サーバーの受信トレイの場合は 1800 IOPS、SQL Server ファイルの場合は 7400 IOPS です。

結果として得られるディスク構成は次のようになります。

1. 推奨されるスペア ディスクは含まれません。
2. 基になるボリューム専用の VM ドライブの固定サイズのパススルー .vhdx 。
3. この値は、 ディスク構成の例からの値です。

まず、Azure でよく寄せられる質問に関するConfiguration Managerを読み取ります。

Premium Storage ベースのディスクを活用するサービスとしての Azure インフラストラクチャ (IaaS) VM は、高い IOPS を持つことができます。 これらの VM では、追加の IOPS ではなく、予想されるディスク領域のニーズに合わせて追加のディスクを構成します。

Azure ストレージは本質的に冗長であり、可用性のために複数のディスクを必要としません。 ディスク マネージャーまたは記憶域スペースでディスクをストライプして、追加の領域とパフォーマンスを提供できます。

Premium Storageパフォーマンスを最大化し、Azure IaaS VM で SQL Server を実行する方法の詳細と推奨事項については、次を参照してください。

• アプリケーションのパフォーマンスを最適化する

• ディスクのガイダンス

例: Azure ベースのサイト サーバー

50,000 クライアントを持つ併置されたサイト サーバーとSQL Serverのサイズ設定ガイドラインは、サイト サーバーの受信トレイの場合は 8 コア、32 GB、1200 IOPS、SQL Server ファイルの場合は 2800 IOPS です。

結果として得られる Azure マシンは、次のディスク構成を持つ DS13v2 (8 コア、56 GB) である可能性があります。

1. この値は、 ディスク構成の例からの値です。
2. Azure ガイダンス では、使用可能な領域を超えず、ディスク I/O の配布を追加できるため、TempDB をローカルの SSD ベースの D: ドライブに配置できます。

例: Azure ベースのサイト サーバー (すぐにパフォーマンスを向上させる)

Azure ディスクスループットは、VM のサイズによって制限されます。 前の Azure の例の構成では、将来の拡張または追加のパフォーマンスが制限される可能性があります。 Azure VM の初期デプロイ中にディスクを追加する場合は、将来の処理能力を向上するために Azure VM をアップサイズし、初期投資を最小限に抑えることができます。 後でより複雑な移行を行う必要なく、要件の変化に応じてサイトのパフォーマンスを向上させる計画を立てる方がはるかに簡単です。

前の Azure 例のディスクを変更して、IOPS がどのように変化するかを確認します。

DS13v2

1. ディスクは、記憶域スペースを使用してストライプ化されます。
2. この値は、 ディスク構成の例からの値です。 VM サイズによってパフォーマンスが制限されます。
3. Azure ガイダンス では、使用可能な領域を超えず、ディスク I/O の配布を追加できるため、TempDB をローカルの SSD ベースの D: ドライブに配置できます。

今後さらにパフォーマンスが必要な場合は、VM を DS14v2 にアップサイズできます。これにより、CPU とメモリが 2 倍になります。 その VM サイズで許可される追加のディスク帯域幅も、以前に構成したディスクで使用可能なディスク IOPS を即座に向上します。

DS14v2

1. ディスクは、記憶域スペースを使用してストライプ化されます。
2. この値は、 ディスク構成の例からの値です。 VM サイズによってパフォーマンスが制限されます。
3. Azure ガイダンス では、使用可能な領域を超えず、ディスク I/O の配布を追加できるため、TempDB をローカルの SSD ベースの D: ドライブに配置できます。

1 つのサーバーのサイズが適切であるか、2 つのサーバー間のネットワーク接続で十分であると仮定すると、どちらも適切に実行できます。

リモート SQL Serverでは、追加サーバーの前払いコストと運用コストが必要ですが、一般的に大規模な顧客の大半です。 この構成の利点は次のとおりです。

• SQL Server Always Onなど、サイトの可用性オプションの増加
• サイト処理に対する聞き取りが少ない大量のレポートを実行する機能
• 状況によっては、より簡単なディザスター リカバリー
• セキュリティ管理の容易
• 別の DBA チームなど、SQL Server管理のためのロールの分離

併置SQL Serverには 1 台のサーバーが必要であり、ほとんどの小規模のお客様にとって一般的です。 この構成の利点は次のとおりです。

• マシン、ライセンス、メンテナンスのコストを削減
• サイト内の障害点の数を減らします
• ダウンタイムを計画するためのより良い制御

既定では、SQL Serverはサーバー上で使用可能なすべてのメモリを使用し、コンピューター上の OS やその他のプロセスが不足している可能性があります。 潜在的なパフォーマンスの問題を回避するには、メモリを明示的にSQL Serverに割り当てることが重要です。 SQL Serverと併置されたサイト サーバーで、OS にファイル キャッシュやその他の操作に十分な RAM があることを確認します。 SMSExec やその他のConfiguration Manager プロセスに十分な RAM が残っていることを確認します。 リモート サーバーでSQL Serverを実行する場合、大部分のメモリを SQL に割り当てることができますが、すべてではありません。 初期ガイダンスについては 、サイズ設定ガイドライン を確認してください。

SQL Serverメモリ割り当ては、GB 全体に丸める必要があります。 また、RAM が大量に増えるにつれて、SQL Serverの割合を高めることができます。 たとえば、256 GB 以上の RAM が使用可能な場合は、OS のメモリが十分に保持されるため、最大 95% のSQL Serverを構成できます。 ページ ファイルの監視は、OS とConfiguration Manager プロセスに十分なメモリがあることを確認する良い方法です。

16 個を超える物理コアがあり、SQL Serverに十分な RAM がない場合、メモリ競合の問題が発生する可能性があります。 コアあたり少なくとも 3 GB から 4 GB の RAM を SQL で使用できる場合、Configuration Managerワークロードのパフォーマンスが向上します。 SQL Serverにコアを追加する場合は、必ず比例量で RAM を増やしてください。

一般に、可用性グループは、レプリカ サーバー間で十分なネットワークが使用可能な場合、システムのパフォーマンスにわずかな影響を与えます。 ビジー状態の可用性グループ環境では、データベース ログ .ldf ファイルが急速に増加する可能性があります。 ただし、データベースのバックアップが正常に完了すると、ログ ファイル領域が自動的に解放されます。 Configuration Manager データベースのSQL Server ジョブを追加して、たとえば 24 時間ごと、.ldf バックアップを 6 時間ごとに実行します。 SQL Serverバックアップ戦略の詳細など、可用性グループとConfiguration Managerの詳細については、「SQL Server Always On可用性グループを使用するための準備」を参照してください。

Configuration Manager データベースでは、SQL Server圧縮は推奨されません。 Configuration Manager データベースで圧縮を有効にしても機能上の問題はありませんが、テスト結果では、システムに大きなパフォーマンスへの影響が生じる可能性がある場合と比較して、サイズが大幅に削減されることはありません。

Configuration Manager データベース内のすべてのシークレットは既に安全に保存されていますが、SQL Server暗号化を追加すると、さらに別のセキュリティレイヤーが追加される可能性があります。 データベースで暗号化を有効にしても機能上の問題はありませんが、最大で 25% のパフォーマンス低下が発生する可能性があります。 そのため、特に大規模な環境では、慎重に暗号化してください。 また、暗号化されたデータを正常に復旧できるように、バックアップと回復の計画を更新してください。

サポートされているバージョンの SQL については、「SQL Server バージョンのサポート」を参照してください。 パフォーマンスの観点から、サポートされているすべてのバージョンのSQL Serverは、必要なパフォーマンス基準を満たしています。 ただし、SQL Server 2016 以降は、Configuration Manager ワークロードのいくつかの面で 2014 SQL Serverを上回る傾向があります。 また、SQL Server 2012 互換性レベル (110) で SQL Server 2014 を実行すると、一般的にパフォーマンスが向上します。 インストール時に、SQL Server 2014 で実行されているConfiguration Manager データベースは互換性レベル 110 に設定されます。 SQL Server 2016 以降は、SQL Server バージョンの既定の互換性レベル (SQL Server 2016 の場合は 130 など) に設定されています。 SQL Serverを所定の場所にアップグレードしても、次のメジャー Configuration Manager現在のブランチ バージョンをインストールするまで互換性レベルは更新されません。

管理 コンソールで RBAC を使用する場合など、SQL Server 2016 以降の特定の SQL クエリで異常なタイムアウトまたは低速が発生する場合は、Configuration Manager データベースのSQL Server互換性レベルを 110 に変更してみてください。 SQL Server 2014 以降のバージョンの SQL Server でSQL Server互換性レベル 110 で実行することは完全にサポートされています。 詳細については、「SQL クエリのタイムアウト」または「特定のConfiguration Manager データベース クエリでコンソールの速度が低下する」を参照してください。

2018 年 1 月の時点で、さまざまな既知のパフォーマンス関連またはその他の潜在的な問題のため、次のSQL Server バージョンは避ける必要があります。

• SQL Server 2012 SP3 CU1 から CU5
• SQL Server 2014 SP1 CU6 から SP2 CU2
• SQL Server 2016 RTM to CU3、SP1 CU3 から CU5

はい。インデックスは週に 1 回、統計は 1 日 1 回の頻度で更新し、SQL Serverパフォーマンスを向上させます。 Configuration ManagerコミュニティとSQL Serverコミュニティから入手できるサードパーティのスクリプトと追加情報は、これらのタスクを最適化するのに役立ちます。

大規模なサイトでは、使用パターンによっては、CI_CurrentComplianceStatusDetails、HinvChangeLog などの一部のSQL Server テーブルが大きくなる可能性があります。 メンテナンス アプローチを 1 つずつ減らすか、変更する必要がある場合があります。

SQL Server Expressはセカンダリ サイトでパフォーマンスに大きな影響を与えるわけではなく、ほとんどのお客様に適しています。 デプロイと管理も簡単で、ほぼすべてのお客様が任意のサイズで構成することをお勧めします。

完全なSQL Serverインストールが必要になる場合が 1 つあります。 環境内に多数の配布ポイントとパッケージまたはソースがある場合は、SQL Server Expressの 10 GB のサイズ制限を超える可能性があります。 2,000 個のコンテンツを含む 2,000 個の IP など、配布ポイントの数が 4,000,000 を超えるパッケージ数が 4,000,000 を超える場合は、セカンダリ サイトで完全なSQL Serverを使用することを検討してください。

設定を 0 のままにしておくこと (使用可能なすべてのプロセッサを使用する) は、ほとんどの状況で全体的な処理パフォーマンスに最適です。

多くのConfiguration Manager管理者は、SQL Serverの 「並列処理の最大レベル」構成オプションに関する推奨事項とガイドラインに関するガイダンスに従っています。 最新の大規模なハードウェアでは、このガイダンスにより、推奨される最大設定は 8 になります。 ただし、プロセッサの数に比べて多数の小さなクエリを実行する場合は、より多くの数に設定するのに役立つ場合があります。 より多くのコアが使用可能な場合、必ずしも大きなサイトでは、自分を 8 個に制限することが最適な設定になるとは限りません。

8 コアを超える SQL Server では、0 の設定から開始し、パフォーマンスの問題や過度のロックが発生した場合にのみ変更を加えます。 パフォーマンスの問題が 0 で発生したために MaxDOP を変更する必要がある場合は、そのサイトのSQL Serverサイズ設定に推奨される最小コア数以上の新しい値から開始します。 この値を下回ると、ほぼ常にパフォーマンスに悪影響を及ぼします。 たとえば、100,000 個のクライアント サイトのリモート SQL Serverには、少なくとも 12 コアが必要です。 SQL Serverに 16 コアがある場合は、値 12 で MaxDOP 設定のテストを開始します。

任意のシステムでウイルス対策保護を無効にする場合は注意してください。 大量で安全な環境では、最適なパフォーマンスを得るための アクティブな監視 を無効にすることをお勧めします。

推奨されるウイルス対策の除外の詳細については、「Configuration Manager 2012 の推奨されるウイルス対策の除外」および「Current Branch Site Servers、Site Systems、Client」を参照してください。

WSUSPool キューの長さや WsusPool プライベート メモリの制限など、いくつかの重要な IIS 設定を変更すると、小規模なインストールでも WSUS のパフォーマンスが向上する可能性があります。 詳細については、「 推奨ハードウェア」を参照してください。

また、WSUS を実行しているオペレーティング システムの最新の更新プログラムがインストールされていることを確認します。

• Windows Server 2012: 2017 年 10 月以降にリリースされた "セキュリティのみ" 以外の累積的な更新プログラム。 (KB4041690)
• Windows Server 2012 R2: 2017 年 8 月以降にリリースされた "セキュリティのみ" 以外の累積的な更新プログラム。 (KB4039871)
• Window Server 2016: 2017 年 8 月以降にリリースされた "セキュリティのみ" 以外の累積的な更新プログラム。 (KB4039396)

WSUS と CONFIGURATION MANAGER SUP メンテナンスをMicrosoftするための完全なガイドを参照してください。

従来のサーバー パフォーマンス監視は、一般的なConfiguration Managerに対して効果的に機能します。 また、Configuration Manager、SQL Server、および Windows Server 用のさまざまな System Center Operations Manager 管理パックを利用して、サーバーの基本的な正常性を監視することもできます。 Windows パフォーマンス モニター (PerfMon) カウンター Configuration Manager直接監視することもできます。 さまざまな受信トレイのバックログを監視して、サイトのパフォーマンスの問題やバックログの可能性に関する早期警告の兆候を確認します。

関連項目

• サイトのサイズ設定とパフォーマンスのガイドライン
• Azure でのConfiguration Managerに関するよく寄せられる質問