Domino服务器上 HTTP 挂起或性能问题的数据收集

问题

Domino服务器上 HTTP 挂起或性能问题的数据收集

诊断问题

为了分析 Lotus® Domino® 服务器的 HTTP 宕机或挂起的问题，必须收集一些数据。收集和提交这些数据对找到根源和解决方案是非常关键的。在联系 IBM® 技术支持之前收集数据将有助于理解问题并节省时间分析问题。

解决问题

当无法访问 HTTP 服务器时就发生了 HTTP 挂起。然而，Domino 不会生成 NSD 日志，因为 Domino 服务器仍旧在运行。有两种类型的 HTTP 挂起：

• 性能 - HTTP 响应非常慢或者看起来无响应。然而实际上 HTTP 正在处理请求但是非常慢。
• Semaphore 死锁 - 当两个进程互相等待信号灯时发生死锁。由于死锁，HTTP 不会响应任何请求或控制台命令。

启用调试

为了调查 HTTP 挂起或性能问题，IBM 技术支持需要完整的调试数据；否则不能及时找出根源和解决方案。调查 HTTP 挂起是非常困难的。需要做更多的工作，并且需要多次收集数据来定位问题。    

使用以下步骤生成该数据：

1.在 notes.ini 里启用合适的"调试参数"，然后重启Domino服务器。

2.等待下次发生 HTTP 挂起，在 Domino 服务器端输入命令：
show stat Domino
tell http show thread state

3.在问题出现时，手工多次运行 NSD。为了完成这步，请参阅说明"如何在Windows上手动为Notes/Domino运行NSD"（#1204263）。

4.对于性能问题或者挂起的时候，运行 NSD附带的 dump 命令，来获取线程堆栈。当问题发生时至少运行三次来找出问题发生的规律。

5.建立并管理 HTTP 线程日志。

调试参数

Notes.ini	描述
Console_Log_Enabled=1	启用控制台日志
Debug_threadid=1	在控制台日志中打印进程 ID (PID)
HTTPEnableThreadDebug=1	记录外来的 HTTP 请求和响应头
Debug_capture_timeout=1	信号量调试
Debug_show_timeout=1	信号量调试
AgentThreadDebug=1	记录 Java 或 LotusScript 代理的开始及结束

HTTP 线程日志

当启用了 HTTP 线程日志，那么 Domino 会为每个被激活的线程创建文件，文件名如下：htthr_processid_threadid_YYYYMMDD@HHMMSS.log。    

关于每个 HTTP 请求的信息被添加到该文件，每个请求大约 10 到 15 行。这些文件默认被创建到 IBM_TECHNICAL_SUPPORT 这个文件夹下，它们可以被重定向通过在 notes.ini 中使用 LOGFILE_DIR=<path>。通常创建40个文件。   

对于 HTTP 挂起，您要提供所有生成的 HTTHR*.LOG 文件。这些文件被用来定位是哪个 URL 引起挂起的。   

重要提示： 在大多情况下，在启用了 HTTP 线程日志之后，挂起不会立即发生。因此，这些 HTTHR*.LOG 文件可能扩展。为了避免加入大量与性能无关的数据，您需要至少一天清理线程日志一次，直到挂起发生。当服务器运行时 HTTHR*.LOG 文件可以被删除，并且会自动生成新的日志。对于管理这些文件，请参阅以下文档获取更多信息   

"How to Manage Size of HTTP Request Log Files (REQ Files)" (#1098527)   

"    Overview of HTTP Request Logs for Domino Web server" (#7003598)   

收集并发送诊断数据

对于 Lotus Notes/Domino 的 IBM Support Assistant (ISA) Lite 会自动收集并提交解决 HTTP 服务器问题所需的数据。为了自动化的收集并发送诊断数据，对 Lotus Notes/Domino 使用 ISA Lite，参见以下技术文档：

• Download IBM Support Assistant (ISA) Lite for Lotus Notes/Domino

按照安装说明并使用技术文档（见"Quick Start Guide (PDF format)"）中提供的工具，或者在下载的工具包中（在 readme.txt）。    

可能需要额外的文件：

• NOTES.INI 和服务器文档
• Domlog.nsf
• Windows 任务管理器的截屏
• 其他操作系统级别的诊断，如 perfmon 日志，磁盘转换，内存使用率，等等。

其他信息

大多 HTTP 挂起是由于 Web 触发的代理的挂起引起的。在调查 HTTP 挂起的过程分成三个阶段。   

阶段 1：确定挂起是否由于一个代理引发的   
阶段 2：找到原始的线程或 URL 挂起   
阶段 3：确定代理挂起的原因   

第三个阶段需要对代理进行多次调查。大多数情况下，技术支持要求代理添加调试语句来定位代理挂起的点。一旦代理代码中的挂起点被确定，Lotus 技术支持可以提出解决方案。   

其他可能引发 HTTP 性能或挂起的问题：   

• CPU 高(由于过多的重建视图，损坏的视图或者文档）
• 过多的代理执行或代理挂起
• 在服务器文档中启用 DNSLookup
• Semaphore 超时问题
• 网络或端口绑定问题（注意：可能需要重新安装补丁）
• 在服务器上出现过多阻塞（从 Domino 统计数据中可以看出）

其他信息：   

技术支持需要确定是否服务器真的在挂起状态，或者是否遇到了性能问题，使得其在某段时间内无响应。为了确定这个，客户移除了在“挂起”状态下存在的 HTTHR*.LOG 文件。如果在几分钟内创建了新的 HTTHR*.LOG 文件，那么说明服务器响应了新的浏览器请求。因此，HTTP 任务不能挂起，但是可以使性能降低。如果这样的话，技术支持会将这个问题作为性能问题，而不是挂起。如果在1或2分钟内没有生成新的 HTTHR*.LOG 文件，那么就是没有处理新的 Web 浏览器请求，说明服务器真的在挂起状态。   

semaphore 死锁的例子   
来自 Semdebug   
THREAD [18898:00002-00001] WAITING FOR FRWSEM 0x0392 Database/user Global Unread List semaphore (@50E4A88C)    
(R=0,W=1,WRITER=12896:01800,1STREADER=00000:00000) FOR 120000 ms   

THREAD [12896:00002-01800] WAITING FOR FRWSEM 0x0244 database semaphore (@6446447C) (/data/local/notesdata/support/retain.nsf)    
(R=1,W=0,WRITER=00000:00000,1STREADER=18898:00001) FOR 120000 ms   

HTTP 性能的例子– 由于 Semaphore 而降低性能   
来自 Semdebug   
02/01/2006 11:41:25 AM EST sq="000C1146" THREAD [153C:0FAB-18BC] WAITING FOR FRWSEM 0x030B Collection semaphore (@01C14108) (R=9,W=0,WRITER=0000:0000,1STREADER=153C:0E2C) FOR 30000 ms   
02/01/2006 11:41:25 AM EST sq="000C1147" THREAD [153C:0034-168C] WAITING FOR FRWSEM 0x030B Collection semaphore (@01C14108) (R=9,W=0,WRITER=0000:0000,1STREADER=153C:0E2C) FOR 30000 ms   
02/01/2006 11:41:25 AM EST sq="000C1148" THREAD [153C:0030-16A8] WAITING FOR FRWSEM 0x030B Collection semaphore (@01C14108) (R=9,W=0,WRITER=0000:0000,1STREADER=153C:0E2C) FOR 30000 ms   
02/01/2006 11:41:25 AM EST sq="000C114A" THREAD [153C:001D-1488] WAITING FOR FRWSEM 0x030B Collection semaphore (@01C14108) (R=9,W=0,WRITER=0000:0000,1STREADER=153C:0E2C) FOR 30000 ms   
02/01/2006 11:41:25 AM EST sq="000C114B" THREAD [153C:001C-1480] WAITING FOR FRWSEM 0x030B Collection semaphore (@01C14108) (R=9,W=0,WRITER=0000:0000,1STREADER=153C:0E2C) FOR 30000 ms   

来自 NSD (NIF Collection)   
[ 14: 16388] 2430 a27dc59d 2650 35 0x0201 00000000 NO NO NO NO 0 (UserIDFull)|vUserIDFull   
CIDB = [ 17: 44036]   
CollSem (FRWSEM:0x030b) state=9, waiters=24, refcnt=0, nlrdrs=9 Writer=[]   
Waiter# 1: mode=W, SemNum = 602 RefCnt= 0 [ nHTTP:153c:0eb8]   
Waiter# 2: mode=W, SemNum = 688 RefCnt= 0 [ nHTTP:153c:1670]   
Waiter# 3: mode=W, SemNum = 484 RefCnt= 0 [ nHTTP:153c:1fa4]   
Waiter# 4: mode=R, SemNum = 635 RefCnt= 0 [ nHTTP:153c:14e4]   
Waiter# 5: mode=R, SemNum = 479 RefCnt= 0 [ nHTTP:153c:1500]   
Waiter# 6: mode=R, SemNum = 612 RefCnt= 0 [ nHTTP:153c:15e0]