次の方法で共有

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

  • [アーティクル]

重要

このバージョンのService Managerはサポート終了に達しました。 Service Manager 2022 にアップグレードすることをお勧めします。

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 Domain 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 スクリプトを実行して、"user" 型をロール "RoleName" に追加できます。 環境のこのサンプル スクリプトを変更する必要があります。

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) の RAM が必要です。

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

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

  • 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 コアが必要です。

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

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

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

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

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

次の手順