监视 Lync Server 2013 性能

 

上次修改的主题: 2014-05-15

Lync Server 2013 性能受到各种因素的影响,例如用户配置文件、系统体系结构、软件、硬件组件、网关和电话设备等第三方集成点、网络连接和性能、Windows Active Directory 服务配置和性能,以及 Windows 操作系统功能。

Lync Server 2013 部署性能的核心是它所实现的服务器软件和硬件。 例如,前端服务器必须有足够的硬件资源来应对预期的 (短期) 用户负载。 如果需要相应的前端服务器向 10,000 名用户提供服务,则配置充分的服务器必须满足预期的负载要求,最终帮助确保尽可能最佳的最终用户体验。

因此,监视服务器性能对于衡量实现的服务器基础结构是否具有适合日常高峰加载要求的硬件资源非常重要。 监视服务器性能有助于识别系统瓶颈,使管理员能够在最终用户体验受到影响之前应用纠正措施。 性能数据应用于长期容量规划。

虽然有关要观察到的所有性能对象和计数器的详细信息已链接到 System Center Operations Manager 的 Monitoring Lync Server 2013 中,但应遵循的一些性能计数器可为管理员提供系统性能的快速视图:

  • 若要跟踪前端服务器的整体系统运行状况,一个好的起点是检查 Processor\% Processor 时间。 该值应始终低于 80%。

  • 若要跟踪前端池使用的后端SQL Server数据库软件实例的性能,请监视以下性能计数器:

    LC:USrv – 00 – DBStore\Usrv - 002 – 队列延迟 (msec)

    LC:USrv - 00 – DBStore\Usrv - 0 04 – Sproc 延迟 (msec)

    处于稳定状态的健康服务器应显示 <100 毫秒的延迟值。 当延迟达到 12 秒时,限制机制会起作用,这意味着前端服务器开始限制对后端的请求。 这会导致客户端开始收到 503 服务器太忙的错误消息。

  • 若要跟踪前端服务器的处理时间,请监视以下计数器:

    LC:SIP - 07 - 负载管理\SIP - 000 - 传入消息的平均保存时间

    这是前端服务器上的另一种限制机制,这一次是在前端的处理时间较高时开始的。 如果平均处理时间超过 6 秒,服务器将进入限制模式,并且每个客户端连接只允许一个未完成的事务。

  • 若要跟踪 SQL 后端服务器的内存问题,请监视以下计数器:

    SQL Server缓冲区管理器\Page 预期寿命

    低值,低于 3600 秒 (以及高延迟写入/秒和检查点页/秒) 表示内存压力。

要查看的其他计数器

有几个关键计数器是前端服务器总体运行状况的良好指标。 这不是一个全面的列表,并不是要确定根本原因。 通过这些计数器,可以快速检查服务器运行状况。 建议在池中的每个服务器上验证这些计数器。 当服务器正常运行时,请务必了解这些计数器值是什么。 需要一个基线来了解在用户体验降级时更改的内容。

前端服务器可以指示可能由系统其他位置的瓶颈导致的问题。 这意味着它是查看整体系统运行状况时的最佳起点。

要首先查看的另外两个计数器如下所示:

LC:USrv-00-DBStore\Usrv-002-Queue Latency (msec)

LC:USrv-00-DBStore\Usrv-004-Sproc 延迟 (msec)

队列延迟计数器表示请求在队列中花费到后端的时间,Sproc 延迟表示后端处理请求所用的时间。 如果后端上的磁盘、内存、网络和处理器因任何原因而出现问题,则队列延迟计数器会很高。

如果前端和后端之间的网络延迟较高,则也可能很高。 那么,什么是可接受的队列延迟?

12 秒后,前端服务器开始限制对后端服务器的请求。 这意味着服务器开始返回服务器太忙 - 503 错误给客户端。 正常运行的服务器的状态应小于 100 msec DBStore 队列延迟,但在服务器刚刚联机且用户都同时登录时,该计数器可能非常高,甚至可能会看到它达到多个秒。

你可能有一个负载均衡配置,其中部署了一个池,其中部署了多个前端服务器和一个为“最少连接数”配置的负载均衡器。在这种情况下,如果重新启动一个前端服务器,则尝试重新连接的所有用户都将指向重启的服务器,因为与其他池成员相比,该服务器的连接更少。 在此期间,可能会重载相应的前端服务器,而其他池成员则不会重载。

建议在非工作时间执行维护,以减少性能影响,因为用户不会都争相同时连接到服务器。

如果前两个性能计数器较高,最可能的瓶颈是 SQL 后端服务器。 要确认的下一个组件如下所示:

  • SQL Server CPU 是否过高? 例如,是否大于 80%?

  • 磁盘延迟是否高?

在理想世界中,你有足够的 RAM 在内存中同时包含 RTC 和 RTCDYN 数据库。 然后,服务器访问磁盘的唯一原因是写入日志文件并刷新到数据库。 测试表明,12 GB RAM 足以用于 10 万用户部署。 这假定 RTC 和 RTCDYN 数据库的大小总计小于 12 GB。 如果数据库大于该值,则可能需要额外的内存。

可以通过查看SQL Server缓冲区管理器页面生存期性能计数器来确定SQL Server是否需要额外的 RAM。 小于 3,600 的值表示内存压力。 如果有足够的内存,还应在数据库驱动器上看到很少或根本没有读取内容,因为SQL Server应该只写入数据库。

Lync Server 2013 前端服务器中有一个额外的限制机制,如果服务器处理时间较高,则会启动该机制。 仅当SQL Server延迟较高时,才启用 DBStore 延迟限制。 启用此类限制的一个示例是前端服务器是否受 CPU 绑定。

如果服务器上传 入消息的平均处理时间 (LC:SIP-07-Load Management\SIP-000-Average 持有时间) 超过 6 秒,则服务器将进入限制模式,每个客户端连接仅为用户提供一个未完成的事务。 处理时间降至 3 秒后,服务器将退出限制模式,并为用户提供每个客户端连接最多 20 个未完成的事务。 每当特定连接上的事务数超过上述阈值时,连接将标记为控制流。 结果是服务器不会在服务器上发布任何接收, LC:SIP-01-Peers\Flow 受控连接 计数器会递增。 如果连接保持在流控制状态超过一分钟,则服务器会关闭它。 它这样做懒惰。 当它有机会检查连接时,它会确定它是否受到过长的限制,如果有超过一分钟的限制,则关闭它。

这是两种限制机制,有一个性能计数器汇总了对服务器执行的限制(如果有的话)。

LC:SIP-04-Responses\SIP-053-Local 503 响应/秒

  • 上一个计数器中的术语“Local”是指本地生成的响应。

  • 503 代码对应于服务器不可用-在正常服务器上不应看到任何 503 个代码。 在服务器刚刚联机后的期间内,可能会看到大约 503 个代码。 当所有用户重新登录并且服务器恢复到稳定状态时,不应有其他 503 个代码。

LC:SIP-04-Responses\SIP-074-Local 504 响应/秒

此性能计数器指示与其他服务器的连接问题,并且可能指示连接失败或连接延迟。 如果看到 504 错误,则应检查以下性能计数器。

LC:SIP-01-Peers\SIP-017-Sends Outstanding

此计数器指示传出排队的请求和响应数。 如果此计数器较高,则问题很可能不在本地服务器上。 请注意,如果存在网络延迟问题,此计数器可能会很高。 它还可能指示本地网络适配器出现问题,但更有可能是由远程服务器上的问题引起的。 当尝试与之通信的池重载时,此计数器很可能在 Director 服务器上很高。 此计数器的键是查看实例,而不仅仅是总数。