问题
Domino服务器上 HTTP 挂起或性能问题的数据收集
诊断问题
为了分析 Lotus® Domino® 服务器的 HTTP 宕机或挂起的问题,必须收集一些数据。收集和提交这些数据对找到根源和解决方案是非常关键的。在联系 IBM® 技术支持之前收集数据将有助于理解问题并节省时间分析问题。
解决问题
当无法访问 HTTP 服务器时就发生了 HTTP 挂起。然而,Domino 不会生成 NSD 日志,因为 Domino 服务器仍旧在运行。有两种类型的 HTTP 挂起:
- 性能 - HTTP 响应非常慢或者看起来无响应。然而实际上 HTTP 正在处理请求但是非常慢。
- Semaphore 死锁 - 当两个进程互相等待信号灯时发生死锁。由于死锁,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,参见以下技术文档:
按照安装说明并使用技术文档(见"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]