次の方法で共有

System Center - Service Manager のパフォーマンス

  • [アーティクル]

System Center - Service Manager サーバーの役割と機能のパフォーマンスは、さまざまな要因の影響を受けます。 一般に、Service Manager では、肯定的および否定的なパフォーマンスが最も顕著な 3 つの領域があります。

  • Service Manager コンソールの応答性。 これは、コンソールで操作を行ったときに、その処理が完了するまでにかかる時間です。

  • コネクタのデータ挿入時間。 これは、コネクタが同期されたときに Service Manager がデータをインポートするのにかかる時間です。

  • ワークフローの所要時間。 これは、ワークフローが自動的にアクションを適用するのにかかる時間です。

コネクタのパフォーマンス

コネクタの初期同期にはかなりの時間がかかる場合があります。たとえば、Configuration Manager との大規模な初期同期の場合は 8 ~ 12 時間です。 コネクタが最初に同期すると、この期間中にすべての Service Manager サーバーの役割とプロセスのパフォーマンスが低下することが予想されます。 これは、Microsoft SQL Server データベースである Service Manager データベースにデータが順番に挿入されるために発生します。 コネクタの初期同期プロセスを急がすことはできませんが、初期同期を計画し、Service Manager が運用環境に移行される前に同期プロセスが確実に完了するようにすることができます。

初期同期が完了すると、Service Manager は引き続き相違点を同期しますが、パフォーマンスに測定可能な影響はありません。

ワークフローのパフォーマンス

ワークフローは自動的に発生するプロセスで、 電子メールによる通知、変更要求をアクティブ化した後の処理、テンプレートの自動適用などがあります。

次に、ワークフローのパフォーマンスに関する注意事項を示します。

  • 通常、ワークフローの開始から終了までにかかる時間は 1 分ですが、 Service Manager サーバーの役割が負荷の高いワークロードの下にある場合、ワークフローは通常ほど迅速に完了しません。

  • また、新しい通知サブスクリプションなどの新しいワークフローを作成する場合は、さらにシステムに負荷がかかります。 新しく作成するワークフローの数が増えるほど、各ワークフローの実行にかかる時間も長くなります。

大量の新規インシデントを作成し、各インシデントで多数のワークフローを作成するなど、システムに大きな負荷がかかる場合は、パフォーマンスが低下することがあります。

グループ、キュー、およびユーザー ロールがパフォーマンスに与える影響

グループとユーザー ロールの計画は早い段階に行ってください。 グループは少なめに作成し、なるべく小さい単位で作成します。 次に、グループを作成する前に、最初にデータベースに Active Directory ドメイン Services (AD DS)、Configuration Manager、System Center Operations Manager のデータを設定する必要があります。

多くの場合、管理者は、ユーザーが指定されたグループにのみアクセスできるようにグループを作成します。 たとえば、人事担当者によって使用されるコンピューターに影響するインシデントなど、インシデントのサブセットを作成する場合を考えます。 ここでは、極秘情報を取り扱う人事部サーバーのグループを表示または変更できるユーザーを特定の担当者だけに制限します。 このためには、まず、すべてのユーザー用のグループ ("すべてのユーザー") と、人事部のコンピューター用のグループ ("人事部サーバー") を作成してから、セキュリティ ロールが両方のグループにアクセスできるように設定する必要があります。 必然的に、すべてのユーザーを含むグループを作成すると、Service Manager がグループに変更があるかどうかを頻繁に確認するため、パフォーマンスに影響します。 既定では、このチェックは 30 秒おきに実行されます。 大規模なグループの場合、変更を確認するとシステムに大きな負荷がかかり、応答時間が大幅に遅くなる可能性があります。

解決策 1: レジストリ キーを変更することで、Service Manager がグループの変更を確認する頻度を手動で指定できます。 たとえば、グループの変更チェック間隔を 30 秒から 10 分に変更すると、パフォーマンスが大幅に向上します。 ただし、キューとサービス レベル目標は特別な種類のグループであり、同じグループ計算ポーリング間隔を使用します。 そのため、ポーリング間隔の値を大きくすると、キューとサービス レベルの目標計算の時間が長くなります。

注意事項

レジストリを正しく編集しないと、システムが正常に動作しなくなる場合があります。 レジストリを変更する前に、コンピューター上の重要なデータのバックアップを作成する必要があります。

グループ変更チェック間隔を手動で指定する

  1. Regedit を実行し、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\ に移動します。

  2. 「 GroupCalcPollingIntervalMilliseconds」という名前の DWORD 値を作成します。

  3. この値として、チェック間隔をミリ秒単位で指定します。 入力した値が 6 倍されます。 たとえば、間隔を 10 分に設定するには、「 600000」と入力します。

  4. System Center Management Service を再開します。

解決策 2: Windows PowerShell スクリプトを使用して、"Users" などの種類のオブジェクトをユーザー ロールに追加できます。 基本的に、このロールにログオンしているアナリストは、"User" と等しい型を持つすべてのオブジェクトにアクセスできます。 この方法を使用すると、大規模なグループ ("すべてのユーザー") が不要になり、Service Manager がこのグループ メンバーシップを決定するために実行するコストの高いチェックが不要になります。 Service Manager 管理サーバーで、次の Windows PowerShell スクリプトを実行して、ロール "RoleName" に "user" 型を追加できます。 環境に合わせてこのサンプル スクリプトを変更する必要があります。

Windows PowerShell スクリプトを実行してユーザー ロールにオブジェクトを追加する

  • 次のスクリプトを適宜変更してから、実行します。
#  
# Insert a "type" scope in a role  
# Syntax:  
#   AddTypeToRoleScope -server "put_server_name_here" -RoleName "put display name of the role here" -TypeToAdd "put display name of the type to add to scope here"  
#  
# Note:  This is a simple demonstration script without error checking.   
#   

# set script parameter defaults  
param ([String]$Server = "localhost", [String]$RoleName="My Analyst Role", [String]$TypeToAdd="User")  

$a = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Core")  

$m = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup $Server   

# Get Type object  
#   Note:  If you need to get a list of all available classes related to (for example) "User",   use this command:  
#               $m.EntityTypes.GetClasses() | ?{ $_.Name -like '*user*'} | %{ $_.Name}  
#  
$type = $m.EntityTypes.GetClasses() | ?{ $_.DisplayName -eq $TypeToAdd}  

# Get role object, and insert the type GUID into scope  
$role = $m.Security.GetUserRoles()  | ?{ $_.DisplayName -eq $RoleName}  
$role.Scope.Objects.Add($type.Id)     
$role.Update()  

#   
# Get the value from the database again and validate it is there  
if ( $role.scope.objects.Contains($type.Id) ) {  
    write-host *** Successfully set the scope for role `" $role.DisplayName`" and it now contains all instances of $type.DisplayName `( $type.Name `)  
} else {  
    write-host "There was an error trying to insert the scope into the role."  
}

パフォーマンスを表示する

ビューを作成するときは、可能な限りシステムで "一般的な" クラスの使用を計画してください。 ほとんどのオブジェクト クラス (インシデント管理など) には、"標準" と "高度" の 2 種類があります。 標準型のオブジェクトには、アイテムに関連するデータの小さなサブセットへの単純な参照が含まれています。 詳細型のオブジェクトには、アイテムに関連するデータへの複雑な参照が含まれています。 標準型は単純なプロジェクションであり、詳細型は複雑なプロジェクションです。 ほとんどの高度なオブジェクトの種類は、通常はビューに表示したくないフォームのさまざまなフィールドを設定するために使用されます。 高度なオブジェクトの種類に基づいてビューを作成し、ビューを開くと、Service Manager はデータベースに対してクエリを実行し、大量のデータが読み取られます。 ただし、取得されたデータはほとんど表示または使用されません。

ビューで高度なオブジェクト型を使用するときに定義したビューでパフォーマンスの問題が発生した場合は、一般的な型の使用に切り替えます。 または、ビューの基にする必要があるデータのみを含む独自のプロジェクション型を作成することもできます。

Service Manager データベースのパフォーマンス

Service Manager データベースのパフォーマンスは、データの読み取りまたは書き込みを行う同時 Service Manager コンソールの数、グループ変更チェック間隔、コネクタによって挿入されるデータなど、さまざまな要因によって直接影響を受けます。 詳細はこのドキュメントで説明しています。 次に、その要点を示します。

  • 一般的なシナリオで許容可能な応答時間を得ることができるように、Service Manager データベースをホストする管理サーバーには、8 GB (GB) 以上の RAM が必要です。

  • Service Manager データベースをホストしているコンピューターには、少なくとも 8 つの CPU コアが必要です。

  • ログ ファイルとデータ ファイルを別の物理ディスクに隔離すると、パフォーマンスが向上します。 tempdb を Service Manager データベースとは異なる物理 RAID ドライブに移動することで、さらにメリットを得ることができます。 可能であれば、RAID 1+0 ディスク システムを使用して Service Manager データベースをホストします。

  • Service Manager データベースが小さいサイズで作成され、自動拡張に設定されている場合、特に小さな増分によってパフォーマンスが低下する可能性があります。

データベースのサイズを評価し、最終的なサイズに近いサイズのデータベースを作成するには、 Service Manager ジョブ エイズ ドキュメント セット (SM_job_aids.zip) に含まれている Service Manager サイズ設定ヘルパー ツールを参照してください。 これにより、データベースの自動拡張が必要な回数を減らすことで、パフォーマンスが向上します。

同様に、パフォーマンスの高いデータベースに関するその他のベスト プラクティスもすべて適用できます。 たとえば、優れたディスク サブシステムを利用できる場合は、それぞれのファイル グループのテーブル グループを分割し、別の物理ドライブに移動することでメリットを得ることができます。

Service Manager 管理サーバーのパフォーマンス

Service Manager 管理サーバーのパフォーマンスは、主にアクティブな同時 Service Manager コンソールの数の影響を受けます。 すべての Service Manager ロールが管理サーバーとやり取りするため、多数のコンソールを同時に使用する場合は、追加の管理サーバーを追加することを検討してください。 管理サーバーには 8 GB の RAM が必要です。 CPU コアあたり 10 ~ 12 個のアクティブなコンソールがある場合は、管理サーバーごとに少なくとも 4 つの CPU コアが必要です。

Service Manager コンソールのパフォーマンス

Service Manager コンソールのパフォーマンスは、主にアナリストが通常開いているフォームの数と、ビューによって取得されるデータの量によって影響を受けます。 Service Manager コンソールがインストールされているコンピューターには、4 GB の RAM が必要です。 大量のデータを取得するビューがある場合は、追加の RAM が必要です。 Service Manager コンソールがインストールされているコンピューターには、少なくとも 4 コア CPU が必要です。 Service Manager コンソールはエンド ユーザー アプリケーションであるため、過剰なリソース消費が発生した場合は再起動することをお勧めします。 Service Manager コンソールでは、メモリ内の情報が積極的にキャッシュされるため、全体的なメモリ使用量に影響を与える可能性があります。

Service Manager データ ウェアハウスデータベースのパフォーマンス

データ ウェアハウスのパフォーマンスは、データを送信する同時 Service Manager 管理サーバーの数、格納されているデータの量またはデータ保持期間、データ変更率、抽出、変換、読み込み (ETL) 頻度など、さまざまな要因によって直接影響を受けます。 データ ウェアハウスに保存されるデータの量は、時間の経過と共に増大します。 そのため、不必要になったデータは必ずアーカイブしてください。 また、ETL プロセスの BatchSize 設定もデータ ウェアハウスのパフォーマンスに影響します。

ログ ファイルとデータ ファイルを別の物理ディスクに隔離すると、パフォーマンスを向上できます。 ただし、1 つのディスクに複数のログ ファイルを配置しないでください。 同様に、tempdb を他のデータベースとは別の物理ディスクに配置すると、より高いスループットが得られます。 また、異なるデータベースをそれぞれ別々の物理ディスクに配置すると、パフォーマンスを改善できます。 可能な場合は、データ ウェアハウスのホストに RAID 1+0 ディスク システムを使用してください。 データ ウェアハウス データベースをインストールするコンピューターには、最低 8 GB の RAM が必要です。 Operations Manager または Configuration Manager から追加のデータ ウェアハウス データ ソースがある場合は、データベースの RAM の量を増やす必要があります。 データ ウェアハウスをホストする SQL Server により大きいメモリを搭載し、データマート データベースとリポジトリ データベースを同じコンピューターに配置すれば、さらに高いパフォーマンスが得られます。 ただし、展開トポロジに 4,000 台以下のコンピューターがある場合は、4 GB で十分です。 データ ウェアハウス データベースをインストールするコンピューターには、少なくとも 8 つの CPU コアが必要です。 さらにコアを増やせば、ETL とレポートの両方のパフォーマンスが向上します。

システム内のすべてのデータベースを小さなサイズで作成し、自動拡張の増大幅を特に小さく設定すると、パフォーマンスが低下する場合があります。 Service Manager ジョブ エイズドキュメント セット (SM_job_aids.zip) に含まれている Service Manager サイズ設定ヘルパー ツールを参照して、データベースのサイズを評価し、最終的なサイズに近いサイズのデータベースを作成します。これにより、データベースの自動拡張が必要な回数を減らすことでパフォーマンスが向上します。

Service Manager には、ファイル グループのサポートが組み込まれています。 別々のハード ドライブにファイル グループを配置すると、このサポート機能の効果が大きくなります。 ファイル グループのベスト プラクティスの詳細については、SQL Server のドキュメントを参照してください。

Service Manager データ ウェアハウス サーバーのパフォーマンス

データ ウェアハウス サーバーのパフォーマンスは、データ ウェアハウスに登録されている Service Manager 管理サーバーの数、展開のサイズ、およびデータ ソースの数によって影響を受けます。 データ ウェアハウス サーバーには通常 8 GB 以上の RAM が必要ですが、 ただし、複数の Service Manager 管理サーバーがデータ ウェアハウスにデータを挿入する高度な展開シナリオでは、メモリを追加することでパフォーマンスが向上します。 すべての要件を満たすことが不可能な場合は、SQL Server を実行しているコンピューターのメモリを最優先させてください。 パフォーマンスの問題を未然に防ぐには、少なくとも 8 つの CPU コアが必要です。

セルフサービス ポータルのパフォーマンス

セルフサービス ポータルは、インシデントおよびサービス要求のファイリングに簡単にアクセスできるように設計されています。 何千人ものユーザーを同時に処理するようには設計されていません。

セルフサービス ポータルのパフォーマンス テストは、一般的な "月曜日の朝" のシナリオに焦点を当てていました。具体的には、月曜日の朝に数百人のユーザーが 5 ~ 10 分以内にサインインし、許容可能な (4 秒から 5 秒未満の) 応答時間でインシデントを開くことができるようにしました。 この目標は、このドキュメントで推奨されている最小ハードウェア要件で達成することができました。

サービス レベルの目標パフォーマンス

Service Manager がサポートするサービス レベルの目標は、特定の数はありません。 たとえば、組織内で発生するインシデントの標準的な数が数件の場合は、通常よりも多い数のサービス レベル目標に対応できます。 しかし、大量のインシデントを処理する場合は、サービス レベル目標を減らすか、必要に応じてハードウェアとソフトウェアを追加する必要があります。 一般的な 50,000 コンピューター Service Manager 構成では、5 つ以下のサービス レベル目標を作成することをお勧めします。 これ以上のサービス レベル目標を作成することも可能かもしれませんが、 ただし、条件は組織によって大きく異なるため、Microsoft では、超過してはならないサービス レベルの目標の数に関する具体的な推奨事項を提供できません。 サービス レベルの目標の数が原因でデプロイ構成のパフォーマンスが低下する場合は、このガイドの「 Configurations for Deployment Scenarios 」の記事で説明されているように、次の大規模な展開シナリオを使用してスケールアウトすることをお勧めします。

次のステップ