1. 启用与 Sametime Java 有关的调试（参见 5.1.2 小节），进一步研究问题

如果 CPU 利用率始终为 0 或一直保持较高的值，那么说明此任务出现异常

EMS STServer 健康监视和服务请求事件应用程序

• 如果在超时期限内接收到消息，那么 MR 服务器被标记为健康
• 如果在超出已配置的超时期限后接收到消息，或者根本没有接收到任何消息那么服务器將被标记为不健康。该服务器上的任何运行中的会议将在另一台运行中的 MR 服务器上自动重启并且不会在这台服务器上安排任何会议，除非它是环境中惟一的一台服务器

如果状态在超出已配置的超时期限后不可用，那么 EMS STServer 健康监视应用程序将停止检查这台 Sametime MR 服务器的健康状态并且这台 MR 服务器的状态在 EMS 中将被标记为停机。

当 EMS 管理页面中的 MR 服务器处于不健康或停机状态那么可能表示健康检查结果失败，或者 Sametime MR 服務器服务失败

延长健康检查超时时间。在某些生产环境中由于加载和网络延迟，针对健康监视和服务检查设置的默认的 90 秒超时可能过於短暂无法反映实际的环境。

另一种可能性是 Sametime MR 服务器在运行和非运行状态之间交替比如，您可以通过将 healthTimeout 延长到 360000（6 分钟）来调整超时為此，执行以下操作：

图 8. WinRAR 的示例存储（无压缩）方法

检查 Sametime MR 服务器 应当对 Sametime MR 服务器进行检查，以确定它的实际状态如果它出于某种原因被標记为“非运行状态”，那么该服务器应当执行重启以恢复服务

尽管可以重新启动所选的 Sametime 服务器服务，但是并不建议对 EMS 环境中的 Sametime 服务器這样做；也就是说重新启动整个 Sametime 服务器。

要进一步研究检查 MR 服务器跟踪日志。在开始检查其他相关跟踪文件之前首先看一下 summary.diag。应当對 EMS STServer 的 SystemOut.log 和 SystemErr.out 文件进行检查查看任何错误或异常。如果需要的话启用一个相应的模块跟踪日志。

当凭证被匹配后配置 servlet 将以 XML 格式返回 MR 服务器嘚配置信息，这些信息将被保存到 DB2 数据库中的 STCONFIG 模式下

因此，一定要调整以下两个与 DB2 锁有关的参数避免出现长时间的锁等待：

因此，对於 LOCKLIST=10000（建议值）将需要 40MB 的内存。您应当计算并调整实际的值收集相应的 DB2 统计数据。

成功完成以上命令后将得到如下所示的 DB2 服务器响应：

1. 检查以下配置项的配置输出：

EMS"，了解其他场景

由于 EMS 和 Sametime Meeting Room (MR) 服务器之间彼此连接，因此有时很难确定问题是出在 EMS 上还是出在 Sametime MR Server 上。在这种情況下可以暂时从 EMS 集群中移除 Sametime MR 服务器，然后重复相同的测试场景以进一步分离和排除故障。

可以通过 STDebugTool.exe 工具动态启用/或禁用这些调试参数Φ的某些参数该工具位于 Sametime 程序目录中。运行该工具后将显示一个包含 ">" 提示符的窗口：

• f 标志，列出可以动态启用的所有参数

• r 刷新；这将關闭所有已存在的跟踪文件并开始写入一个新的文件

该工具对大小写敏感因此必须确保所有命令使用小写输入。由于这个工具没有应用於所有调试参数因此那些应用了该工具的参数使用一个 * 号标记（"f" 将返回一个完整的列表）。

一般而言生成的跟踪文件将使用相关进程嘚名称作为前缀；例如，如果启用了与 LDAP 有关的跟踪那么就可以在 STLDAP_*.txt 中找到跟踪。

结合使用多个参数通常很有用例如，在跟踪身份验证问題时启用普通的身份验证参数和特定于目录的参数。

Sametime 身份验证/登录（与服务器的目錄配置无关）

Sametime Chat Logging：对于以下聊天登录调试，添加用户登录调试来跟踪参与聊天的用户将非常有用添加通道调试也很有鼡，因为将针对参与到聊天中的每个用户创建一个通道：

可以在 [Debug] 部分中设置但与调试无关的参数：

• 了解更多有关 的信息
• 了解更多有关 的信息。
• 了解更多有关 的信息