通过

System Center - Service Manager性能

  • 项目

重要

此版本的Service Manager已终止支持。 建议升级到 Service Manager 2022。

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 分钟，则将显著提高性能。 但是，队列和服务级别目标是特殊类型的组，它们使用相同的组计算轮询间隔。 因此，增加轮询间隔的值会导致队列和服务级别目标计算的时间更长。

注意

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

手动指定组更改检查间隔

  1. 运行 Regedit 并导航到 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\?

  2. 创建名为 GroupCalcPollingIntervalMilliseconds的新 DWORD 值。

  3. 对于此值，请指定以毫秒为单位的间隔。 将结果与 6 相乘。 例如，若要将间隔设置为 10 分钟，请输入 600000。

  4. 重新启动 System Center Management 服务。

解决方案 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."  
}

查看性能

创建视图时，请尽可能在系统中规划使用“典型”类。 大多数对象类（例如，事件管理）都有两种类型：“典型”和“高级”。 典型对象类型包含对项目相关数据的小子集的简单引用。 高级类型包含对项目相关数据的多项复杂引用。 典型类型是简单投影；高级类型是复杂投影。 大多数高级对象类型用于填充窗体中通常不希望显示在视图中的不同字段。 每当基于高级对象类型创建视图并打开视图时，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 设置。

通过将日志文件和数据文件隔开到单独的物理磁盘，可以获得较佳的性能。 但是，应避免每个磁盘放置多个日志文件。 同样，通过将 tempdb 放在非其他数据库所在的物理磁盘上，可以获得更佳的吞吐量。 最后，通过将这些不同数据库放在其各自的物理磁盘上，也可以从中受益。 如有可能，请使用 RAID 1+0 磁盘系统承载数据仓库。 通常至少应为安装有数据仓库数据库的计算机提供 8 GB RAM。 如果有来自 Operations Manager 或 Configuration Manager 的其他数据仓库数据源，则应增加数据库的 RAM 量。 在运行承载数据仓库的 SQL Server 的计算机上，你将从更多内存中受益，如果数据市场和存储库数据库位于同一服务器上，则尤为如此。 但是，如果你的部署拓扑中有 4,000 台或更少的计算机，则 4 GB 就足够了。 在安装了数据仓库数据库的计算机上至少应该具有 8 个 CPU 内核。 更多的内核将有助于提高 ETL 和报表性能。

如果创建的所有系统数据库的大小都较小并且专门将这些数据库设置为按小幅增量自动增长，则可能会对性能有负面影响。 请参阅Service Manager作业帮助文档集中包含的Service Manager调整大小帮助程序工具 (SM_job_aids.zip) 评估数据库的大小，并创建大小接近最终大小的数据库，这将通过减少数据库自动增长的次数来帮助提高性能。

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 个服务级别目标。 你可能会创建更多服务级别目标。 但是，由于情况因组织而异，因此 Microsoft 无法针对不应超出的服务级别目标数量提供具体建议。 如果部署配置因服务级别目标数量而性能不佳，我们建议使用下一个更大的部署方案进行横向扩展，如本指南 的部署方案配置 一文中所述。

后续步骤