System Center - Service Manager 性能

项目
11/06/2024

System Center - Service Manager 服务器角色和功能的性能受到不同因素的影响。通常，在 Service Manager 中，有三个方面是正面和负性能最明显的：

Service Manager 控制台响应能力。这是在控制台中采取某种操作的那一刻到该操作完成的时间长度。
连接器的数据插入时间。这是在连接器同步时 Service Manager 导入数据所需的时间。
工作流完成时间。这是工作流自动应用某种操作所花费的时间。

连接器性能

连接器初始同步可能需要大量时间;例如，对于与 Configuration Manager 进行大型初始同步，为 8 到 12 小时。由于连接器最初同步，因此在此期间，所有 Service Manager 服务器角色和进程的性能都可能会受到影响。之所以发生这种情况，是因为数据按顺序插入 Service Manager 数据库，这是一个Microsoft SQL Server 数据库。虽然无法加快连接器的初始同步过程，但可以规划初始同步，并确保同步过程在 Service Manager 投入生产之前完成。

初始同步完成后，Service Manager 会继续同步差异，这不会对性能产生可衡量的影响。

工作流性能

工作流是自动发生的过程。它们包括发送电子邮件通知、激活更改请求的下一步以及自动应用模板。

工作流性能注意事项包括以下各项：

通常，工作流会在一分钟内启动和完成。当 Service Manager 服务器角色处于繁重的工作负荷下时，工作流不会像正常一样快速完成。
此外，在创建诸如新通知订阅之类的新工作流时，会给系统额外增加负荷。随着所创建的新工作流数目的增加，每个工作流运行所花费的时间也将增加。

当系统负荷很重时，例如，如果正在创建大量新事件并且每个事件都会生成许多工作流，则性能会受到负面影响。

对性能的影响组、队列和用户角色

您应该及早规划组和用户角色。你应谨慎地创建组，并在创建时要针对尽可能最小的作用域。然后，在创建组之前，应首先使用来自 Active Directory 域服务（AD DS）、Configuration Manager 和 System Center Operations Manager 的数据填充数据库。

通常，管理员创建组以确保用户仅有权访问指定的组。例如，在一种方案中，你可能希望创建事件（例如，影响人力资源部门人员所使用的计算机的事件）的子集。在此方案中，你可能只希望让特定人员能够查看或修改敏感服务器组。那么，为了实现此访问类型，你需要针对所有用户创建组以及针对敏感计算机创建组，然后确保安全角色能够访问“所有用户”和“敏感服务器”组。不可避免地，创建包含所有用户的组会导致性能影响，因为 Service Manager 经常检查以确定组是否有更改。默认情况下，此检查每 30 秒钟发生一次。对于大型组，检查更改会在系统上产生沉重的负载，并且可能会大大降低响应时间。

解决方案 1：可以通过修改注册表项手动指定 Service Manager 检查组更改的频率。例如，如果将组检查频率从 30 秒钟更改为 10 分钟，则将显著提高性能。但是，队列和服务级别目标是特殊类型的组，它们使用相同的组计算轮询间隔。因此，增加轮询间隔的值会导致队列和服务级别目标计算的较长时间。

注意

不正确地编辑注册表可能会对系统造成严重损坏。在更改注册表之前，应备份计算机上任何有价值的数据。

手动指定组更改检查间隔

运行 Regedit，并导航到 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\。
创建名为 GroupCalcPollingIntervalMilliseconds的新 DWORD 值。
对于此值，请指定以毫秒为单位的间隔。将结果与 6 相乘。例如，若要将间隔设置为 10 分钟，请输入 600000。
重新启动 System Center Management 服务。

解决方案 2：可以使用 Windows PowerShell 脚本将类型的对象（如“用户”）添加到用户角色。从本质上讲，登录到此角色的分析师可以访问类型等于“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."  
}

查看性能

创建视图时，请尽可能规划在系统中使用“典型”类。大多数对象类（例如，事件管理）有两种类型：“典型”和“高级”。典型对象类型包含对项目相关数据的小子集的简单引用。高级类型包含对项目相关数据的多项复杂引用。典型类型是简单投影；高级类型是复杂投影。大多数高级对象类型用于填充通常不希望在视图中显示的表单中的不同字段。每当基于高级对象类型以及打开视图时创建视图时，Service Manager 会查询数据库并读取大量数据。但是，很少显示或使用检索到的数据。

如果在视图中使用高级对象类型时定义的视图遇到性能问题，请切换到使用典型类型。或者，可以创建自己的投影类型，这些投影类型仅包含基于视图的数据。

Service Manager 数据库性能

Service Manager 数据库的性能直接影响到各种因素，包括读取或写入数据的并发 Service Manager 控制台数、组更改检查间隔以及连接器插入的数据。本文档中提供了详细信息。以下是一些重点：

对于托管 Service Manager 数据库的管理服务器，至少应有 8 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。每个管理服务器应至少有 4 个 CPU 核心，假设每个 CPU 核心有 10 到 12 个活动控制台。

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 设置。

通过将日志文件和数据文件隔开到单独的物理磁盘，可以获得较佳的性能。但是，应避免每个磁盘放置多个日志文件。同样，通过将 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无法针对不应超过的服务级别目标数量提供具体建议。如果部署配置由于服务级别目标数量而性能不佳，我们建议使用下一个更大的部署方案进行横向扩展，如本指南的“部署方案配置”一文中所述。

后续步骤

若要了解 Service Manager 部署方案的硬件和软件配置，请查看建议的部署拓扑方案。

通过