内容


优化 Lotus Domino 服务器性能

信号量,第 2 部分

Comments

系列内容:

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

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

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

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

信号量对于系统的作用就像是十字路口的信号灯:一种保持系统运行顺畅的机制。具体地说,信号量确保服务器完成某些任务,然后再开始其他任务。

本文是两篇系列文章的第 2 部分,讨论如何识别、解决和防止信号量问题。本系列的 第 1 部分 讨论了为什么会出现信号量超时以及如何判断信号量超时的原因。本文延续第一篇文章,根据实践经验提供更多故障排除技术。本文还介绍在设计应用程序和使用 LotusScript 时应该记住的考虑因素,以及专门针对 R5 的故障排除技术。

排除信号量问题:高级实践经验

在阅读 Sem.Timeout 命令的输出之后(参见本文的边栏 把信号量号与特定进程关联起来 和第一篇文章的边栏 分析 Sem.Timeouts 行),或者阅读和分析 Domino 服务器控制台消息之后,您应该能够判断出系统的哪些领域出现了信号量超时。根据这一信息,可以尝试使用以下技术继续收窄与信号量超时相关的领域范围。

除非专门说明,这些技术都来自 R4 经验。应该与第 1 部分提供的故障排除建议结合使用这些技术。为了便于参考,我们按照发生信号量超时的系统领域(数据库、服务器和 Indexer)组织这些技术。其中一些技术不仅适用于信号量超时问题,也适用于一般的 Domino 服务器管理和故障排除。

检查磁盘配置和数据库位置(数据库)

检查磁盘 I/O 响应速率和配置以提高最终用户响应时间。使用平台工具检查磁盘活动速率。磁盘配置分析需要检查物理磁盘分配、逻辑磁盘分配、与磁盘控制器的关系等等。了解了磁盘配置之后,要分析各个 Domino 组件的关系以及 Domino 可执行程序、Domino 数据文件、分页文件和事务日志的位置。更多信息请参见 Iris Today 文章 “Optimizing server performance: I/O subsystems” 和 Lotusphere99 presentation ID603 Maximizing DB performance, reliability, availability & scalability

如果希望减少数据库争用,但是不愿意修改磁盘配置,那么应该尝试减少数据库访问争用或改进文件访问时间的措施。实现这种改进的方法包括把数据库转移到另一个磁盘、控制器或不太忙的磁盘。关于识别数据库问题的更多信息,请参见本文后面讨论 Show DBS 命令的小节。

尝试使用集群(数据库)

如果出现数据库信号量 0244 和 0245 并发现了以下情况,就可以考虑使用集群战略:

  • 系统上有许多活跃用户(检查 Show Stat Server 命令显示的 Server.Users 值)。
  • 相当多的活动要打开数据库(检查 Show DBS 输出,详细信息见后面的小节)。
  • 相当多的活动要打开视图(检查 LOG_UPDATE)。

通过使用集群服务器,可以把工作负载分散开。更多信息请参见 Iris Today 文章 “Optimizing server performance: Domino clusters Part 1” 和 “Part 2”。

重新分布用户(数据库)

如果发现系统上有过多活跃用户,那么可以考虑把一部分用户转移出系统。这个策略只适用于应用程序和邮件服务器。请参考 NotesBench 网站上发布的基准测试报告。这些报告指出了给定的系统配置在执行指定工作负载时能够支持的最大用户数量。

把用户转移到其他 Domino 系统之后,分析是否需要转移与他们相关联的数据库。另外,在把用户转移出系统之后,要检查系统性能的变化,包括数据库性能和不同 Domino 服务器任务(内部开发和外部开发)的活动率。

检查新服务器控制台命令 Show DBS 的输出 —— 只适用于 R5(数据库)

R5 中新增的 Show DBS 命令显示当前使用的数据库的相关信息,比如打开数据库的次数、数据库是否修改过以及用户等待数据库锁的次数。关于如何检查这个命令的输出以及如何使用输出帮助检测性能瓶颈,请参见边栏 如何使用 Show DBS 的输出。关于这个命令的更多信息,请参见 Domino 5 Administration Help 中的主题 “Improving database and Domino Directory performance”。

检查 Show Database 命令的输出(数据库)

在分析特定数据库时,使用 Show Database 命令的输出。这个命令的输出报告各种信息,包括数据库中各个视图的大小(字节数)和在数据库中可以找到的对象(例如,文档、表单和视图)。下面是 Show Database 命令的输出摘要:

> Show Database demo.nsf
Sample Database
Document TypeLiveDeleted
Documents234966
Info00
Form870
View800
View sizesBytes
People231,208
Server\Connections131,880
($ServerAccess)1,531,440
($Users)1,721,480
Marks view0

例如,根据我们的 R4 经验,$Users 视图很大而且常常重新构建。根据这些观察,我们通过修改代码改进了低层索引结构(通常称为 B-树)。具体地说,我们修改了 B-树存储机制,只在更新区域重新构建 B-树,而不必总是重新构建整个 B-树。因此,视图重新构建问题会大大减少。我们相信,随着 Domino R5 的伸缩性增长,用户数量也会增长,最终会达到新的上限,就需要进一步改进。

检查 Show Directory 控制台命令的输出(数据库)

Show Directory 命令的输出表示当前在 Domino 数据库缓存中找到的条目。这些信息包括数据库的完整路径、名称、版本号、修改时间和事务日志记录状态。下面是 Show Directory 命令的输出示例(这个示例中省略了 Modified Time 列):

>Show Directory
[017E:0003-01CF] DbNameVersionLogged
[017E:0003-01CF] f:\notefile\schema50.nsfV5:41Yes
[017E:0003-01CF]f:\notefile\Stats.boxV5:27No
[017E:0003-01CF]f:\notefile\mail.boxV5:40No
[017E:0003-01CF]f:\notefile\mail2.boxV5:41Yes
[017E:0003-01CF]f:\notefile\mail1.boxV5:41Yes
[017E:0003-01CF]f:\notefile\wsj.nsfV5:41Yes
[017E:0003-01CF]f:\notefile\wrkinst.nsfV3:17No
[017E:0003-01CF]f:\notefile\wpissues.nsfV5:41Yes
[017E:0003-01CF]f:\notefile\webuser.nsfV3:17No
[017E:0003-01CF]f:\notefile\webadmin.ntfV4:20No
[017E:0003-01CF]f:\notefile\webadmin.nsfV5:41Yes
[017E:0003-01CF]f:\notefile\web.nsfV5:41Yes
[017E:0003-01CF]f:\notefile\VinodTes.nsfV5:41Yes
[017E:0003-01CF]f:\notefile\userreg.ntfV4:20No
[017E:0003-01CF]f:\notefile\usenet.nsfV5:41Yes
[017E:0003-01CF]f:\notefile\usegate.nsfV5:41Yes
[017E:0003-01CF]f:\notefile\unixdisc.nsfV5:41Yes
[017E:0003-01CF]f:\notefile\unames4.ntfV4:20No
[017E:0003-01CF]f:\notefile\uiv5info.nsfV5:41Yes
[017E:0003-01CF]f:\notefile\uiteam.nsfV5:41Yes

如果发现某一数据库上出现了大量争用(通过检查 Show DBS 命令的输出),而且发现数据库版本来自以前的 Domino 版本,那么应该考虑升级数据库,看看问题是否会消失。

检查复制战略(数据库)

应该检查为拓扑指定的复制战略,因为 Replicator 任务会在 Domino 服务器上施加负载。如果看到数据库的视图收集信号量 (030B) 和数据库的视图收集队列信号量 (0309),就应该寻找涉及的数据库和视图。可以在 LOG_UPDATE 和 LOG_VIEW_EVENTS 输出中找到数据库和视图名。视图上的活动可能源于用户活动或服务器任务请求 —— 尤其是,由于视图重新构建或复制日志记录花费的时间太长,Domino Directory 查询会降低复制活动的速度。如果希望推迟 Domino Directory 上的重新构建,应该设置 NOTES.INI 设置 SERVER_NAME_LOOKUP_NOUPDATE=1。这个变量允许在视图索引过程中访问 Domino Directory 中的名称查询视图。它还允许在索引过程中访问用于身份验证和邮件路由的其他视图。关于这个变量的使用方法和益处的更多信息,请参见 Lotus Customer Support Technote #150232 What Does the SERVER_NAME_LOOKUP_NOUPDATE=1 Server NOTES.INI Parameter Do?

还可以在 Domino 统计数据中检查复制条目(通过 Show Stat Replica 命令),了解添加、删除和更新文档的速率。同时检查这些信息和 Show DBS 命令,可以更全面地了解数据库。这时,可能会注意到等待者的数量正在增加。这里可能有联系,因为为了成功地执行 Replicator 发出的添加、删除和更新请求,需要持有数据库信号量。也就是说,为了成功地执行复制,需要访问目标数据库。如果有大量用户/服务器任务要访问数据库,复制过程就无法完成。

创建多个 Mail.Box 文件(数据库)

如果发现 Domino 统计数据 Mail.Waiting 正在增长或处于比较高的值,而且出现了数据库信号量消息(0244 或 0245),那么使用 Show Stat Mail 检查 Mail Router 统计数据。对于 R5,一定要使用创建多个邮箱的特性。关于配置多个邮箱的信息,请参见 Lotusphere99 presentation ID603 Maximizing DB performance, reliability, availability & scalabilityDomino 5 Administration Help

使用多个邮箱可以减少在等待更新方面浪费的时间,与多个邮箱交互可以提高 Router 的效率。但是,使用这种方法也要适度,如果支持的邮箱数量过多,可能不会进一步改进响应时间和使用系统资源的效率。

可以先把一个邮箱改为两个。然后,如果必要的话,可以把一个 Domino 服务器上的邮箱数量增加到三个或四个。关于邮件交付线程的信息,请参见 Tell Router Show 命令和 Lotusphere99 presentation ID601 Deploying Domino R5 for performance and scalability

调整 NSF_BUFFER_POOL_SIZE (数据库)

在有效范围内调整 NOTES.INI 设置 NSF_BUFFER_POOL_SIZE 之后,当前的用户和应用程序可能会体验到性能改进。请记住,调整这个值常常只是短期解决方案,尤其是在请求更多缓冲区池空间时。这需要更多内存,因此剩余内存更少,难以支持用户或应用程序的增长。另外,调整这个值会限制操作系统缓存可用的内存量。

在 Domino R5 中,我们修改了使用的 NSF 缓存区池分配算法,Domino 服务器需要的缓存区池大小以默认或指定的数量作为上限。R4 战略预先分配并保留默认或指定的数量。例如,在 R5 中,如果指定缓冲区池大小为 10,000,但是只需要 5,000,就只分配 5,000。在 Domino R4 中,如果指定缓冲区池大小为 10,000,那么即使只需要 5,000,也会分配 10,000。

打开事务日志记录 —— 只适用于 R5(数据库)

通过使用 R5 中新增的事务日志记录,可以在发生系统故障时恢复数据库。一般情况下,按照推荐的方法使用事务日志记录可以提高性能。为什么呢?如果系统出现信号量争用问题,事务日志记录提供的额外性能吞吐量可能会消除或减少争用。概括而言,事务日志按次序地写数据能够更加高效地保存和更新 Domino 存储的数据。更多信息请参见 Iris Today 文章 “Optimizing server performance: Transaction logging” 或 Domino 5 Administration Help

分析服务器事务(服务器)

Show Trans 命令的输出提供一个信息表,包括服务器执行的事务功能类型、执行频率(数量)和相关的执行时间(最小时间、最大时间、总时间和平均时间)。这些信息是连续收集的,所以如果没有清除事务信息(通过 Show Trans Reset 命令),它们应该代表自从 Domino 服务器启动以来(或自从上一次重置以来)它执行的事务的汇总历史。关于这个命令的更多信息请参见 Domino 5 Administration Help

通过 Show Trans 的输出,可以看出 Domino 服务器的系统执行概况。可以看出事务类型的模式、执行事务的频率以及哪些事务的执行时间比较长。每个事务对于 CPU、内存、磁盘空间和其他 Domino 资源的需求各不相同。例如,如果一个服务器要处理大量邮件,那么这个领域的事务量会比较大,其他领域的事务量比较小。

注意,每个服务器执行不同类型的事务,所以不一定可以比较不同服务器的事务信息,尤其是那些 “专用的” 服务器,比如主要处理邮件路由或运行数据库应用程序的服务器。一些事务的执行时间确实应该比较长,所以需要分别检查和分析每个事务。

如果您熟悉 Show Trans 输出,就可以判断出某一特性领域花费的时间是否过长,或者某一事务的执行时间是否明显长于平均时间。注意,因为 “Min” 列和 “Max” 列可能形成一个比较宽的范围,所以要综合考虑数据,还要考虑到平均值。要经常捕捉这些数据并注意数据范围的变化(也就是,发生变动的时间),这有助于更好地了解 Domino 服务器在特定时间的状态。

下面是 Show Trans 命令的输出示例:

FunctionCountMinMaxTotalAverage
OPEN_DB2610250221085
OPEN_NOTE6206026043
UPDATE_NOTE2610640160061
DB_INFO_GET10000
SEARCH3307701020340
DB_REPLINFO_GET23010703
REMOTE_CONSOLE7040608
CLOSE_DB2601402409
CLOSE_COLLECTION5010102
OPEN_COLLECTION53013503100620
READ_ENTRIES5031035070
NIF_OPEN_NOTE120202020
SET_COLLATION2010105
READ REPLICATION HISTORY13024095073
WRITE REPLICATION HISTORY5010204
GET_MULT_NOTE_INFO_BY_UNI270190260130

在上面的输出示例中,查看与某一服务器事务相关联的各个列。可以通过这些值得出不同的结论。例如,如果最大值接近平均值,就说明响应时间相当稳定。但是,如果最大值和平均值的差距很大,就说明响应时间变化很大,或者出现了某种内部阻塞。注意最小值是接近还是远离最大值或平均值也是有意义的,接近意味着响应速度稳定(也意味着系统的负载可能不重)。相反,响应范围宽意味着服务器负载变化很大,服务器可能超载。

注意 Server Transaction 表并不包含基于 Web 的交互(包括 HTTP、IMAP、LDAP、POP3 等等)。

检查特定的服务器事务(服务器)

要想快速地了解某些服务器事务(通过 Show Trans 的输出),可以集中关注 OPEN_COLLECTION、OPEN_DB 和 OPEN_NOTE 事务。它们都有相关联的 “CLOSE_” 类型的事务(CLOSE_COLLECTION、CLOSE_DB 和 CLOSE_NOTE)。可以通过这些事务数据了解视图、数据库和 note 级的活动。START_SERVER 事务包含身份验证过程。因此,如果要判断是否出现了服务器身份验证问题,或者用户连接服务器花费的时间是否过长,那么应该监视 START_SERVER 事务。

可以通过 Show Trans Reset 命令清除事务信息。如果认为问题是反复出现的,建议执行这个命令。这个命令清除整个事务表。在此之后,随着事务的执行,会逐渐添加信息。这样,与事务相关的数据能够更清楚地反映短时间内的活动和执行时间。

检查服务器任务(服务器)

如果在一般不会出现争用的数据库(也就是非 “知名” 数据库)上出现了争用,就需要深入研究其他 Domino 服务器任务对数据库的影响。许多任务有相关联的控制台命令,有助于提供更多信息。下面列出一些可以用来进一步了解服务器任务及其活动的控制台命令。

  • Agent Manager —— 使用 Tell Amgr Status 输出 Agent Manager 运行的总数和时间。还可以在 Show Stat Amgr 下面查看 Agent Manager 统计数据。
  • Router —— 使用 Tell Router Show 了解传输线程和交付线程的配置和执行情况。这个命令的输出包括线程的最大数量以及使用和未使用的线程总数。对于传输线程配置,还可以看到可以同时执行的最大数量。可以从 Tell Router Show 命令得到与 Tell Router Status 命令相同的输出。
  • Mail —— 使用 Show Stat Mail 了解当前的邮件状态。这个命令的输出包含与邮件交付速度和邮件数据吞吐量相关的许多数据。

您可能认为这些命令的输出太繁杂,在其中寻找有用的信息就像是大海捞针。但是,只要您了解了系统的正常状态,这些命令的非正常输出有助于引导您采取下一步行动,从而减少信号量争用问题或内部瓶颈。

调整 SERVER_MAX_CONCURRENT_TRANS 值(服务器)

NOTES.INI 设置 SERVER_MAX_CONCURRENT_TRANS 的默认值是 20。只能对单分区和 Domino Release 4.x(其中没有线程池体系结构改进)修改这个设置。在修改之前,应该熟悉(NT Perfmon 中的)System Counter Context Switches/sec。在修改事务速率值时,应该观察这个值的变化。作为经验规则,可以以 20 为增量提高 SERVER_MAX_CONCURRENT_TRANS 值。如果 Context Switching 数值开始增加了,就说明已经达到或超过了适当设置。我们建议在每次调整之后等待一周,以确保 Domino 服务器保持稳定状态。

从最终用户的角度来看,当出现 Notes 客户机超时,无法成功地连接 Domino 服务器时,就说明这个值设置得太高了。在 Domino 服务器控制台中发出 Show Users 命令之后,如果发现会话旁边并不总是列出名称,就说明这个值设置得太高了。没有列出名称是因为身份验证过程没有成功地完成,无法提供更多背景信息。在邮件交付过程中,需要通过访问 $Users 视图授予访问 Domino 服务器的权限,这时也可能发生相似的问题。成功地访问之后,会给会话分配一个名称。如果 Domino 服务器被迫承担超出合理范围的压力,就可能产生严重的后果,上面描述的未经身份验证的会话问题就是这种问题的示例。

在 R4 生产环境中,我们发现在重新构建 $ServerAccess 视图(这是进行身份验证所需的)时,用户也无法成功地完成身份验证。在大型 Domino Directory 中,重新构建这个视图花费的时间会比较长。如果有 20 个活跃用户,其他用户等待一个事件(比如请求通过服务器进行身份验证),这种情况会导致持续的循环,进而导致 Notes 客户机超时。超时的 Notes 客户机会尝试再次连接服务器,这意味着它们需要身份验证。但是,在 $ServerAccess 视图的重新构建完成之前,身份验证过程无法完成。Indexer 进程之外的其他进程都无法访问这个视图,所以 Notes 客户机会再次超时。因此,线程数量持续增加,但是没有更多用户获得对服务器的访问权。

检查 Domino Directory 和相关联的视图重新构建时间 (Indexer)

如果 Domino 服务器花费很长时间更新一个视图,就可能出现几种信号量问题。通常,会开始出现数据库 (0244)、视图收集 (030B) 和/或会话表信号量 (0A0B)。本文前面详细描述过的另一种症状是在 Show Users 控制台命令的输出中出现未经身份验证的用户(命令输出显示会话号,而不显示用户名)。同样,如果更新花费的时间很长,用户无法成功地完成身份验证,因此无法与 Domino 服务器建立会话,就会出现这类问题。

Domino Directory 通常执行许多更改,包括更新、添加和删除。更改的数量也会影响服务器的复制活动。Domino Directory 通常要保持信息是最新的,因为身份验证过程要使用这些信息,用户和服务器发起的许多任务也要访问这个中心文件。因此,需要找到适合系统的平衡点 —— Domino Directory 既不要太频繁地为视图重新构建和文档内容进行更新,也不要长时间不更新,应该成批执行合理数量的更改,从而避免不必要的频繁更新。

如果希望推迟 Domino Directory 的重新构建,应该设置 NOTES.INI 设置 SERVER_NAME_LOOKUP_NOUPDATE=1。这个变量允许在视图索引过程中访问 Domino Directory 中的名称查询视图。它还允许在索引过程中访问用于身份验证和邮件路由的其他视图。关于这个变量的使用方法和益处的更多信息,请参见 Lotus Customer Support Technote #150232 What Does the SERVER_NAME_LOOKUP_NOUPDATE=1 Server NOTES.INI Parameter Do?

分析长时间视图更新 (Indexer)

我们常常花时间分析视图重新构建时间。这有助于预先发现问题。为了进行初步故障排除,请考虑以下问题:

  • 它是否是大视图?
  • 是否有大量视图?
  • 是否发生大量更新?了解是否有 “大量” 更新的好方法是,观察视图是否频繁更新或者用户是否抱怨等待视图出现的时间太长?

例如,如果更新来自 Replicator 并启用了 Replicator 日志记录选项(输出发送到 Domino 服务器控制台和日志,更多信息请参见 Domino 5 Administration Help),那么 Replicator 显示在每个数据库中添加/删除/更新的 note 数量。这一信息有助于反映活动水平,但是并不能说明是什么触发了视图更新。也就是说,它没有指出哪些 note 与某一视图相关联。

在内部,有一种保护每个视图的信号量,它称为 Collection 信号量。对于大视图,如果对 note 执行的活动大多数是读类型的(比如很少添加新的 note 或修改现有的 note)并禁用了未读标志(这会在幕后导致视图更新),那么大视图的视图更新和显示的性能应该不错。如果不是这样,就应该考虑对于您的应用程序把这个视图分割为两个或更多视图是否是可行的。

在解决 Domino 服务器上的视图更新问题时,通常要考虑的要点如下:

分析超时是否是真正的问题

最后,正如第一篇文章中提到的,并非所有信号量超时消息都意味着严重的问题。通过使用本文和第一篇文章提供的信息,您应该能够了解发生超时的原因,从而判断超时是临时状况还是真正的问题。

下面给出一个临时状况造成超时的示例:在撰写本文时,我们通过在一个繁忙的服务器上频繁地执行 Show Stat 命令人为地制造了一种信号量超时状况。这种做法导致了信号量超时 0116。长的 Show Stat 输出(尤其是使用代码的调试版本)可能会阻塞它执行的其他进程。这种状况并不严重,应该只会在执行每个 Show Stat 控制台命令期间出现。在本文的开头,我们建议您熟悉这个命令的输出,还通过指定参数查看 Show Stat 输出的某些子集。另外,如果您的平台支持的话,可以通过查看 Stats & Events 数据库获取与 Show Stat 命令相同的 Domino 服务器统计数据。这个数据库按指定的时间间隔自动地捕捉相同的数据(由 Collector 任务执行),这有助于进行历史趋势分析。

Domino 应用程序开发人员应该考虑的因素

为了减少信号量争用问题,Domino 应用程序开发人员在设计应用程序时应该牢记以下原则。这里描述的原则也适用于外部开发的应用程序,所以可以根据它们检查单独开发的应用程序和 Domino 服务器任务。

不要长时间锁住信号量

在锁住信号量到释放信号量之间,要仔细考虑执行的代码量、执行的操作类型、发出的函数调用和循环次数。要从操作可伸缩性的角度分析所有这些方面。

避免使用单一信号量保护大量数据

在一个信号量保护大量数据时,如果一个或多个任务使用它进行写操作,这个信号量就会成为系统瓶颈。写进程排队等待访问这个数据结构,在这个信号量可用之前会一直阻塞。我们推荐一种更好的战略:从程序设计的视角分析数据需求,让一个信号量保护的数据量更少。

避免导致死亡拥抱状况的设计

在需要多个锁时,使用分层方式。分层方式要求以一致有序的方式启动锁。例如,如果信号量编号为 1 到 10,那么每个任务先锁住编号最低的信号量,然后依次锁住信号量,直到编号最高的信号量。

以有组织的方式登记信号量代码

这种方法适用于规模比较大的编程项目,在这种项目中多位开发人员必须合作开发锁/解锁处理。以有组织的方式记录和报告信号量为长期的可维护系统提供了基础。

使用不同类型的信号量类

有不同的信号量类:区分优先级,随着程序大小的增长根据活动进行特殊处理(例如,FIFO 次序,使用多个读进程)。为了避免严重复合状况,引入了与信号量相关联的权重系统,它根据特定的信号量,确保执行给定序列中的路径或优先级更高的路径。当有多个任务等待访问数据结构时,可以使用多种技术。一种技术是让读进程优先于写进程。另一个策略是利用特定操作系统必须提供的东西。这种策略要求您了解基本操作系统内核提供的机制,并在程序逻辑中利用这些机制设计信号量使用方法。

构建死锁检测逻辑

我们在调试代码中构建了一些死锁检测逻辑 —— 例如,检测和报告分层违规的逻辑。(注意,不要为生产代码启用这种开销很大的处理)。这种逻辑是一种高级编码技术,随着开发人员数量和开发的程序的复杂性的增加,可能需要采用这种技术。虽然编写检测逻辑需要很大的工作量,但是它可以更快地发现问题,从长期来看是值得的。

LotusScript:如何应对信号量问题?

LotusScript 被设计为线程安全的,这意味着它使用信号量保护数据结构,从而保护装载的每个 LotusScript 实例。在使用 LotusScript 时,我们推荐以下设计建议以避免信号量问题。

在使用 Lock 和 Unlock 函数时要特别小心

对于 R5,可以通过 LotusScript 开发使用 Lock 和 Unlock 函数的代码。在使用这些函数时,应该特别小心,仔细规划。例如,如果不释放锁(相当于一直持有信号量),就会导致阻塞问题。在退出 LotusScript 程序时,结束逻辑会清除所有未释放的锁,这 “有助于” 避免未释放锁的问题。这里的 “有助于” 这个词加上引号是因为,您应该尽可能在自己的程序中完成清理过程,不要依靠系统机制。当最终用户按 Ctrl-Break 时和发生正常终止过程时,调用结束逻辑。但是,LotusScript 逻辑并不检测无限循环等编程问题,所以您必须采取措施来避免这些情况。

更多信息请参见前面的 “Domino 应用程序开发人员应该考虑的因素” 小节。

计划 HTTP 服务器的代理处理

当设计和开发在大规模生产系统上执行的代理时,要检查在 HTTP 服务器上启动代理时所涉及的处理。需要确保支持的软件和执行情况符合预期和需要。更具体地说,在触发代理时,装载一个 LotusScript 实例。如果发出许多请求,就会导致许多代理执行(也导致单独的 LotusScript 执行),这会争用相同的资源。通过在 Domino Directory 中指定 HTTP 活跃线程数量可以在一定程度上缓解这种争用。当 Server Configuration 文档中的活跃 HTTP 线程数量增加时,也要考虑到负面影响:随着活跃线程数量的增加,支持更多线程的处理支持和资源成本也会增加。在确保实现系统吞吐量增长目标的同时,需要确保不会妨碍执行的其他处理。更多信息请参见 Iris Today 文章 “Optimizing server performance: HTTP Threads settings”。

R5 中的采用的一般战略

根据我们对 R4 环境中信号量问题的了解,我们在 R5 环境中采用以下战略来减少信号量问题:

使用 “散列表” 方式

在内部 Domino 开发中,我们所做的主要工作之一是把内部列表结构转换为一个带索引的表(即 “散列表”)。散列表包含不同类型的信息 “队列”。随着 Domino 规模的增长,处理的列表越来越长,花费的时间也就越来越长(达到一定的规模之后,这种方法就不可行了),而散列表方式可以避免对信息进行全面搜索。

部署最新的预发布代码

我们尽早把 Domino 服务器软件的最新预发布版本部署到 Iris/Lotus/IBM 中的多个配置和用户环境中。我们认为这种调试工作非常重要,这让我们能够研究所有崩溃和严重的系统问题。研究和探索所有系统问题有助于尽可能减少可能导致信号量争用问题的场景。

检查控制台命令的输出

正如本文前面提到的,我们经常检查以下命令的输出:

  • Show DBS
  • Show Database
  • Show Directory

结束语

现在,您已经掌握了关于信号量超时的信息、帮助推断原因的技术以及有助于减少信号量超时的措施。如果系统出现信号量问题,您知道如何分析系统。

在本文中,您学习了根据第一篇文章中收集的信息进行故障排除的一些技术。还学习了在编写应用程序时应该采用哪些规则来尽可能减少信号量超时。还学习了在使用 LotusScript 和 R5 时有助于系统顺畅运行的一些实践建议。

我们希望本文和第一篇文章有助于缓解您系统上的信号量问题,让您能够预防信号量超时问题。


相关主题


评论

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

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