内容


优化 Lotus Domino 服务器性能

信号量,第 1 部分

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 优化 Lotus Domino 服务器性能

敬请期待该系列的后续内容。

此内容是该系列的一部分:优化 Lotus Domino 服务器性能

敬请期待该系列的后续内容。

如果在繁忙的十字路口没有信号灯,会怎么样?您能想像这种混乱场面吗?信号灯是非常必要的,它们可以保持道路上交通顺畅。与十字路口的信号灯一样,信号量的作用是保持服务器上的 “交通”(也就是任务的运行)顺畅。信号量是 Domino 服务器体系结构的组成部分,管理员需要了解它们,才能维护高效且可靠的系统。

本文是两篇系列文章的第 1 部分,讨论信号量以及它们为什么会产生超时消息,介绍如何阅读这些消息并解决问题。第二篇文章 根据实际场景提供解决信号量超时消息的建议。还讨论如何尽可能减少信号量问题。

什么是信号量?

信号量是一种软件标志,它们确保服务器先完成某些任务,然后再开始另一个任务。在多任务系统中,信号量是保持系统顺畅且可靠地运行的关键因素。

Notes/Domino 在一个任务期间锁住一个信号量,在任务完成时释放信号量。例如,在 Indexer 重新构建索引时,它锁住一个信号量,从而防止其他任务使用这个视图,直到它完成重新构建为止。如果在此之后另一个任务尝试打开这个视图,它就必须等待 Indexer 完成重新构建并释放信号量。

如果一个任务长时间等待释放一个信号量,那么会怎么样?如果在十字路口红灯很久才变成绿灯,等待的司机会很烦躁;同样,对于这种情况,用户任务会通过 Domino 服务器内部机制记录它等待的时间,如果等待的时间超过 30 秒(如果设置了 NOTES.INI 设置 DEBUG_SHOW_TIMEOUT 的话),就会触发一个信号量超时通知。然后,信号量处理逻辑向服务器控制台发送一条消息。用户任务继续等待释放信号量,每 30 秒超时一次,直到 “信号量持有者” 任务结束为止。在复杂的过程中,任务可能会经历多次超时。当出现信号量超时消息时,最终用户可能会注意到系统性能很差或者服务器没有响应了,但是最终用户看不到信号量消息。

为什么会出现信号量超时?

许多情况都可能导致出现信号量超时。例如,一个任务锁住一个信号量,但是一直没有释放它(后面会列出可能的原因),这导致队列中的任务一直等待释放信号量。并非所有信号量超时消息都意味着严重的问题,它们很可能意味着系统正在满负载或超载运行。了解这些场景有助于区分真正的问题和暂时的状况。

出现信号量超时的原因包括:

  • 服务器上的负载沉重,这会导致进程推迟释放信号量。
  • 信号量死锁 —— 两个任务等待对方正在使用的资源,它们都无法打破这个循环。例如,任务 A 已经锁住了信号量 1,然后尝试锁住信号量 2。与此同时,任务 B 已经锁住了信号量 2,现在尝试锁住信号量 1。任务 A 会一直等待信号量 2,而任务 B 一直等待信号量 1。
  • 一个正在执行的进程还没有释放信号量,这会阻塞等待此信号量的另一个进程。
  • 编写得很糟糕的脚本或程序同时访问同一数据库。例如,在最终用户环境中,如果在小规模测试配置中测试过一个程序,但是在大规模生产环境中却遇到了问题,那么可能是出现了这种情况。

可以通过两种方式之一检查系统是否遇到了信号量超时。

  • 在 Domino 服务器控制台上输入 Show Stat Sem.Timeouts。如果出现了超时,就会看到下面这样的消息:

    Sem.Timeouts= 430D:58 0A12:42 030B:28 0116:26 0A12:21

  • 在 Domino 服务器控制台中检查读取的消息:

    Session semaphore held for [n] seconds

    为了显示这些消息,一定要在 NOTES.INI 中启用 DEBUG_SHOW_TIMEOUT 设置。这些消息/错误并不输出到服务器日志文件中。

阅读信号量超时消息

Domino/Notes 在 Show Stat Sem.Timeouts 控制台命令的输出中显示信号量超时的类型和数量。还可以在控制台或 SEMDEBUG.TXT 文件中查看实际的信号量超时消息。下面的 “故障排除 —— 收集信息” 一节详细介绍如何通过启用适当的 NOTES.INI 参数显示消息。

了解如何解释信号量超时消息,通常要收窄关注的领域范围。下面提供一个示例信号量超时消息,然后详细解释如何分析它。这个消息是一个示例,消息的文本可能各不相同。

THREAD [009F:00BE -0012 ] WAITING FOR RWSEM 0x4245 				
open database queue semaphore (@01070246) 				
(R=0,W=1,WRITER=009F:00AF	-0025,1STREADER=009F:00AF	-0025) FOR 5000 ms

上面消息中的粗体字符是 Domino R5 在 Domino R4 的基础上增加的新信息。

注意:本文中的术语适用于那些采用进程和线程体系结构的平台。这些平台包括 Windows NT、UNIX 和 OS/2。进程 ID 对应于 Domino Add-in 任务或 Domino (Main) Server 任务。许多任务是多线程的,一个或多个线程可能与给定的进程相关联。对于不支持线程(但支持进程)的平台,比如 Netware 及 Windows 95 和 98,处理方式稍有差异。

在这个示例中,0x4245 是涉及的信号量。0x4245 后面的文本简要描述请求的信号量的类型(在这里,是打开数据库队列信号量)。本文的 第 2 部分 介绍与特定的信号量相关联的活动。

下面的表分析示例信号量消息中的标识符。下面的 “故障排除 —— 阅读信息” 一节帮助了解线程 ID 与特定任务的对应关系。

标识符含义
[ 009F :00BE-0012] 009F 是请求信号量的进程。更具体地说,提取 009F 并作为进程 ID 记录它。这个 ID 代表希望锁住这个信号量的进程(尽管另一个进程可能持有这个信号量)。
[009F: 00BE -0012] 00BE 是虚拟线程 ID。更具体地说,提取 00BE 并作为虚拟线程 ID 记录它。这是用于在 Domino 内部识别正在执行的线程的值。
[009F:00BE- 0012 ] 0012 是平台操作系统知道的线程 ID。这一信息对于以后的调试工作很重要,应该把它传递给 Lotus Customer Support 以帮助排除故障。物理线程信息报告是 Domino R5 对线程池体系结构的一项改进。
009F :00AF 009F 也是最后锁住信号量的进程;AF 是它的虚拟线程 ID。

在上面的示例中,同一个进程 (009F) 尝试访问信号量,但是在逻辑中的不同位置执行不同的线程。一个线程持有信号量,它阻塞了另一个线程。并非所有信号量超时都涉及这么复杂的问题,但是这个示例表明可能出现比较棘手的情况。

关于阅读信号量超时消息的更多信息,请参见边栏 Sem.Timeouts 分析 和 Lotus Customer Support Technote #112710 Semaphores and Semaphore Timeouts

故障排除 —— 收集信息

为了分析出现信号量超时消息的原因和判断问题的严重程度,需要收集信息。在一般情况下,您应该了解系统在不同活动水平上的工作方式。本节针对收集和分析相关信息的方法提供一些建议。

本文的 第 2 部分 根据实际信号量超时场景提供更多故障排除建议。

信号量消息并不写入服务器日志文件,所以采取措施收集信息对于故障排除更加重要。下面的信息收集战略有助于排除信号量超时故障。

了解系统在稳定状态和活跃状态下的行为

在稳定状态下,用户没有对系统施加压力(比如在早上用户在不同的时间启动)。在活跃状态下,用户同时登录,而且大多数用户是活跃的(比如在上午和下午)。

了解了系统在稳定状态下的情况之后,可以转而了解 Domino 服务器在更活跃的状态下的行为。这样,当发生缓慢或剧烈的变化时,您可以知道对稳定或活跃状态性能的影响如何变化。了解变化的差异、有效范围和对 Domino 服务器的潜在影响(根据预计的数据库使用量、新应用程序等等)。

尤其是,要使用以下命令和它们的输出从 Domino 服务器控制台收集信息:

  • Show Stat Sem.Timeouts —— 显示自从 Domino 服务器启动以来发生的 Sem.Timeouts 消息的总数和类型。
  • Show Stat Server.Users —— 显示当前的活跃用户数量。
  • Show Stat Database.DbCache.AverageDbOpenTime —— 显示在为内部和用户请求服务时打开 Domino 数据库所花费的平均时间(秒数)。
  • Show Tasks —— 显示活跃任务的状态、活动和它们的服务器。
  • Show Perf —— 每分钟一次连续显示日期、时间、执行的事务数量和当前的活跃用户数量。
  • Show Dbs —— 显示关于数据库的性能信息,比如打开数据库的次数、数据库是否修改过以及用户等待数据库锁的次数。这是 R5 新增的命令。

使用各种工具

下面的工具可以提供关于活跃的进程以及它们的活动水平和物理线程 ID 值的信息。可以使用前一节中介绍的信号量消息中的进程信息作为索引,在工具输出中寻找感兴趣的进程。

  • Perfmon —— 在 Windows NT 平台上,Domino 管理员可以使用 Perfmon 收集关于特定系统和 Domino 组件的性能信息。尤其是,可以通过 Process 统计数据查看 Add-in 任务所处的活动水平。
  • Windows NT Task Manager —— 这个工具有助于识别每个任务的进程 ID。查看 ID 的方法是,单击 Processes 选项卡,通过 Image Name 列中的进程找到 PID 列中相应的进程 ID。在信号量超时消息中看到一个进程 ID 时,就可以把它与一个任务联系起来。更多信息请参见 Lotus Customer Support Technote #175384 How To Utilize SEMDEBUG.TXT and Task Manager
  • Qslice —— 在 Windows NT 平台上,这个工具可以显示任何时刻的活跃任务。它在相关联的进程 ID 下显示物理线程 ID。
  • NSD —— 这个工具是由 Domino 工程师开发的,当前可以作为 Domino 服务器包的组成部分在 UNIX 平台上使用。它显示感兴趣的线程的堆栈。更多信息请参见边栏 UNIX 故障排除建议

要想进一步了解其他平台工具以及如何改进服务器性能,可以从 Lotus IT Central Performance Zone Technical Library 下载 Lotusphere 演示 “How to Deploy Domino R5 for Performance and Scalability”。

启用 NOTES.INI 设置

通过启用一些 NOTES.INI 设置,可以提供关于问题的更多信息。尤其是,应该启用以下设置:

NOTES.INI 设置说明
DEBUG_SHOW_
TIMEOUT=1
在服务器控制台上显示超时消息。
DEBUG_CAPTURE_
TIMEOUT=1
把超时消息写到 SEMDEBUG.TXT 文件中。这些消息并不写到服务器日志文件中。
DEBUG_SEM_
TIMEOUT= n
Domino 服务器控制台报告信号量超时消息的速率(毫秒数)。默认设置是 30000 毫秒,即 30 秒。在没有与 Lotus Customer Support 联系的情况下,不要修改默认设置。
DEBUG_THREADID=1用于把来自 DEBUG_OUTFILE 的消息与特定的进程和线程 ID 关联起来。
LOG_UPDATE =2 LOG_VIEW_EVENTS=1用于深入研究与数据库和 Indexer 相关的问题。
NSF_BUFFER_POOL_
SIZE= value
只在系统使用分区配置的情况下使用。如果不是这样,就应该接受默认设置(底层代码会根据固定的开销和可用的总内存量进行计算)。关于为分区系统计算设置的信息,请参见 “Optimizing server performance: Port encryption and Buffer Pool settings” 或 Lotusphere 演示 Deploying Domino R5 for performance and scalability
SERVER_MAX_
CONCURRENT_ TRANS= n
用于帮助 Domino 实现更高的处理量,以及在许多用户同时访问服务器时保持一定的活动水平。默认设置是 20。这还可以增加可用的信号量,让服务器能够更高效地处理活动高峰。这只应用于不支持最新的线程池体系结构改进(R5 中新增的特性)的 Domino 配置。
SERVER_SHOW_
PERFORMANCE=1
在服务器控制台输出中提供更多信息,包括前一分钟执行的事务数量和当前的服务器用户数量。
DEBUG_OUTFILE= path file name创建一个捕捉服务器控制台输出的文件,可以使用它把消息与特定的进程和线程 ID 关联起来。这个文件应该与 DEBUG_THREADID 结合使用。这个文件会消耗磁盘空间和 CPU 处理时间,所以使用之后应该禁用它。更多信息请参见 Lotus Customer Support Technote #162400 How Should the DEBUG_OUTFILE Parameter Be Implemented?

关于 Domino 服务器命令和 NOTES.INI 设置的更多信息,请参见 Domino 5 Administration Help

故障排除 —— 阅读信息

在许多情况下,必须通过排除某些原因来推断问题的真正原因。下面的战略有助于阅读信息,从而判断信号量超时的原因。

阅读服务器日志文件

分析信号量行为的好起点是服务器日志文件,其中包含控制台命令的输出。尤其是,Show Stat Server.UsersShow Stat Sem.Timeouts 命令的输出能够提供给定时间段内活动的变化情况。

为了判断变化趋势模式,应该每天和每周分析服务器日志文件。在分析需要更密切监视的情况时,可能应该捕捉一到四小时范围内的 Domino 服务器控制台信息。通过使用这些信息,可以更好地把 Server.Users 和 Sem.Timeouts 控制台命令的输出与日志文件的内容关联起来。另外,还要注意随着 Domino 服务器上使用量的增加,值如何变化。注意,尽管信号量超时消息不出现在服务器日志文件中,但是控制台中显示的每个信号量消息会增加 Sem.Timeouts 的总数。

查看 LOG_UPDATE 和 LOG_VIEW_EVENTS 的输出

如果认为问题与数据库或 Indexer 相关,那么应该在服务器日志文件中查看 LOG_UPDATE 和 LOG_VIEW_EVENTS 命令的输出。

LOG_UPDATE 命令输出 Domino Update 任务执行的索引活动的相关信息,提供数据库名称、更新的视图的名称和状态信息。如果设置了 LOG_UPDATE 命令,与正在更新的视图相关的消息会快速显示在 Domino 服务器控制台中,视图是当前的(也就是说,在检查每个视图最近的活动时,显示消息)。

LOG_VIEW_EVENTS 命令的输出表明活动的原因,比如重新构建视图(这也是 Update (Indexer) 任务执行的)。例如,可以看到在比较常用的数据库(比如 Domino Directory 或 Mail.Box)上重新构建哪些视图和重新构建的时间。另外,还可以开始把这些线索联系起来。例如,如果发现某个视图常常重新构建,可以考虑检查可用磁盘空间是否有限制问题。如果没有足够的磁盘空间,视图重新构建过程就无法成功完成,Domino 管理员会发现系统一直尝试重新构建视图。

查看 DEBUG_THREADID 的输出

在服务器日志文件中,通过查看 DEBUG_THREADID 的输出,把 DEBUG_OUTFILE 文件消息与进程 ID 或线程 ID 关联起来。需要交叉引用 DEBUG_THREADID 输出与操作系统的进程和相关 ID 的列表。前面的 “故障排除 —— 收集信息” 提供了关于进程 ID 的更多信息。我们建议在使用 DEBUG_THREADID 时联系 Lotus Customer Support,他们可以指导您进行分析。

阅读 Database.DbCache.AverageDbOpenTime 信息

这个统计信息记录在为内部和最终用户请求服务时打开 Domino 数据库所花费的平均时间(秒数)。应该定期检查这个值,了解它随时间变化的趋势(如果系统通常应该保持一致的行为)。这个值可以作为系统问题(包括系统超载)的迹象。请记住,一个统计数据并不能全面地反映服务器的健康状态。还应该检查其他统计数据,从而更全面地了解系统。

查看 Domino Add-in 任务的活动

在通过服务器日志输出分析信号量超时变化时,还可以看到其他 Domino Add-in 任务执行的活动。这些任务也可能对信号量超时有影响(单独或与其他 Domino 组件结合)。

Show Tasks 命令的输出中,查看各个 Add-in 任务旁边显示的注释字段,了解任务正在执行的活动。还可以监视一个任务是否阻塞了,在这种情况下,状态消息在合理的时间段内一直没有变化。但是,这有一些例外,比如正在重新构建非常大的视图。同样,熟悉系统及其行为有助于判断问题的真正原因。

查看 Domino 服务器用户数量

在查看 Domino 服务器控制台或服务器日志中的消息时,可以查看 Domino 服务器用户数量和报告的其他事务。为了启用用户数量的显示,首先要设置 NOTES.INI 设置 SERVER_SHOW_PERFORMANCE 或者执行 Domino 服务器控制台命令 Show Perf。在此之后,Domino 服务器用户数量会自动地出现在服务器控制台和日志中。这一信息每分钟显示一次。它包含日期、时间、前一分钟执行的事务数量和当前的活跃用户数量。

分析 Sem.Timeouts 信息

Sem.Timeouts 的输出提供关于信号量超时的类型和数量的报告。输出行可以列出多个信号量超时类型。如果在监视期间超时数量急剧增加,就有必要进一步研究。作为一条经验规则,如果在一小时内某个信号量的超时数量增加了 5 到 10 个,就说明有必要进一步研究这个领域。

通过分析 SEMDEBUG.TXT、STATREP.NSF(这里捕捉统计数据)和服务器日志文件中的内容,可以确定某一信号量的超时数量快速增加的大致时间。另外,还可以尝试判断在产品的哪个部分中发生了信号量超时(比如 Domino 服务器中的一个任务尝试沿着某一路径执行,但是被阻塞了)。请参见边栏 Sem.Timeouts 分析 和 Lotus Customer Support Technote #112710 Semaphores and Semaphore Timeouts,进一步了解 Sem.Timeouts 信息,尤其是它如何记录发生的超时及其频率。

注意,无法重新初始化 Sem.Timeouts 统计数据,所以任何变化或分析都以捕捉的第一个值为基础。

分析信号量超时消息

如果启用了 NOTES.INI 设置 DEBUG_CAPTURE_TIMEOUT,实际的信号量超时消息会被写到 SEMDEBUG.TXT 文件中。可以使用平台工具之一(例如 Windows NT Task Manager)帮助理解这些消息中报告的信息,从而进一步了解发生争用的信号量,包括涉及的任务。前面的 “阅读信号量超时消息” 一节有助于解释消息。

消除多余的 Add-in 任务

应该尽可能消除所有多余的 Domino 服务器 Add-in 任务,包括 Domino 内部和外部的任务(比如最终用户开发的应用程序或程序)。这有助于降低服务器负载,减少发生信号量争用的可能性,尤其是在信号量消息表明系统超载的情况下。

对于外部开发的和内部开发的 Add-in 任务,可以考虑使用不同的删除方式。有时候,外部开发的任务会干扰 Domino Add-in 任务的总体处理。可以临时删除这些任务,看看系统是否有变化。如果信号量超时消息消失了、出现的速率改变了或者出现了不同的消息,就能够进一步了解问题的原因和影响。

检查 NSF_BUFFER_POOL_SIZE

我们建议接受 NOTES.INI 设置 NSF_BUFFER_POOL_SIZE 的默认值。如果没有指定设置,那么在把系统升级到 Domino 的新版本之后或在修改系统配置时应该检查这个设置。接受默认值这条建议适用于单分区配置。

检查 SERVER_MAX_CONCURRENT_TRANS

检查这个 NOTES.INI 设置是否太高。这个设置的默认值是 20,我们建议以 20 为增量提高它。如果 Notes 客户机超时了,就说明这个值太高了。本文的 第 2 部分 提供关于这个设置的更多信息。

考虑修改 DEBUG_SEM_TIMEOUT 的默认值

在修改这个 NOTES.INI 设置之前,应该向 Lotus Support 寻求帮助。DEBUG_SEM_TIMEOUT 控制报告信号量阻塞的速率(毫秒数),能够按照给定的时间阀值向管理员报告信号量请求阻塞了多长时间。对于您的环境,可能有必要修改默认设置 30000(30 秒)。

我们建议下一个合理值是 60000(60 秒),但是您应该根据对服务器行为的了解和希望实现的效果决定最终的调整。例如,在运行超载的服务器时,可能希望调整 DEBUG_SEM_TIMEOUT 的默认值,因为超载的服务器往往会产生更多的信号量超时消息。根据工作负载,已经可以预见到会出现信号量超时消息(因为这些消息是系统超载的迹象),所以提高时间间隔可以减少超时数量。

结束语

再次重申,出现信号量超时并不一定意味着系统出现了严重的问题。实际上,健康的系统也很可能会遇到信号量超时。了解信号量超时以及它们发生的方式有助于维护可靠且高效的系统。

在本文中,学习了信号量是什么、它们为什么会产生超时以及如何检查系统是否遇到了信号量超时。还学习了如何阅读超时消息以及如何判断超时消息的原因。本文的 第 2 部分 根据实际场景提供关于排除故障的更多建议。本文的第 2 部分还讨论如何尽可能减少系统中的信号量问题。

特别感谢

特别感谢 Nirmala Venkatraman 和 Andy Nolet 为本文提供的帮助。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Lotus
ArticleID=398647
ArticleTitle=优化 Lotus Domino 服务器性能: 信号量,第 1 部分
publish-date=11011999