Domino 应用程序性能故障检修: 第 2 部分：Lotus Notes/Domino 7 中的新工具

应用程序性能故障检修：新数据收集工具

通过多年来听取客户讨论他们关于代理的经验，我们已经知道识别容易出故障的代理是非常困难的。在 HTTP 环境中尤其如此，在该环境中许多代理并行运行，这使确定其中哪个代理在过度消耗 CPU 或内存资源变得非常困难。另外，识别出有问题的代理后，还需要通过大量工作来确定哪部分代理代码最适合优化。Lotus Notes/Domino 7 中将出现的新诊断工具可以帮助我们解决这些问题。

回页首

Domino Domain Monitoring 中的应用程序探针

Domino Domain Monitoring（DDM）是 Lotus Notes/Domino 7 的新功能。它是一种已经添加到所有服务器任务中的框架，用于根据管理员配置的不同简单条件来进行自我监视。DDM 仅能监视 Domino 7 服务器；它不能监视 Lotus Domino 的以前版本，因为这些版本没有自我监视的代码。在本文中，我们着重讲述与性能问题相关的应用程序探针。

应用程序探针覆盖了代理和 Web 服务，特别是在 Agent Manager 任务中运行的计划的、基于事件的代理和在 HTTP 任务中运行的 Web 代理和 Web 服务。可以使用下列类型的应用程序探针：

• 按 CPU 使用率分级的代理和 Web 服务。
• 按内存使用率分级的代理和 Web 服务。
• 运行时间比预期要长的代理和 Web 服务。
• 开始时间晚于计划的代理（仅适用于 Agent Manager）。
• 代理和 Web 服务错误探针：
  • Agent Security
  • 非全文索引的数据库上的全文操作
  • 代理超时
  • 在更新设计时 Design Update 功能被禁用的代理

在本文中，我们将讨论 CPU、内存和全文探针以及它们如何帮助解决性能问题。

Events4.nsf（Monitoring Configuration 数据库），包含了许多服务器配置信息，新版本中已经进行了许多改进，包含了多个新的视图，这些视图用来存储所有的 DDM 探针配置。

图 1. Monitoring Configuration 数据库

Events4.nsf 随 Lotus Notes/Domino 7 一起提供，包括默认探针，这些探针可以直接使用，也可以进行配置以满足组织的需要。

应用程序 CPU Usage 探针

让我们仔细地看一下 CPU Usage 探针。CPU Usage 探针测量每个代理的 CPU 使用量。测量在每个代理中进行。CPU 的测量从特定代理的开始直至结束，而不管该代理运行了多长时间。CPU Usage 探针仅测量一个代理的 CPU 使用量，即使该代理在给定进程的多个活动线程中的一个线程上运行也是如此。对于 Java 代理，其中每个代理在多个不同的线程上运行，那么探针会在属于该代理的所有线程中进行测量，测量结果是属于该代理的所有线程中所用 CPU 使用量的总和。除了通过 DDM 探针工具，其他方式无法获得这种测量特征。

配置应用程序探针非常简单。图 2 显示了 CPU Usage 探针的配置。其他所有应用程序探针都与此相类似。

图 2. CPU Usage 探针配置

选择探针类型后（应用程序探针/按 CPU 使用率分级），接着选择要监视的服务器，以及是要监视在 Agent Manager 中运行的计划代理还是 Web 代理/Web 服务。然后选择探针的细节。

您可以最多选择四个警告级别（从 Warning Low 到 Fatal），这些警告将基于代理的 CPU 使用量来生成。如果代理在其执行期间的 CPU 使用量超出您所配置的，那么将会生成具有适当级别的警告事件。事件任务将会处理该事件，并在 Domino Domain Monitoring 数据库（ddm.nsf）中输出显示。

图 2 中显示的是用于运行本文中用作示例代理的配置。我们将最低级别（Warning Low）设成了一秒，这使我们可以为示例中的所有代理（甚至包括那些使用非常少量 CPU 的代理）生成事件。在生产系统中，您通常不希望使用如此低的配置阈值，因为它可能会生成太多的信息。

为了进行说明，我们使用本系列文章的第 1 部分中讲述的技术创建了四个代理。代理名称中包含了用于实现每个代理的技术名称，例如，Slow Mail Agents (dbSearch) 使用了方法 db.Search。下面是它显示在 ddm.nsf 中的输出。

图 3. Domino Domain Monitoring

正如您所看到的，CPU Usage 探针证实了这些方法的相对效率：

• Slow Mail Agent (AllDocs) CPU 使用率是 1034 秒。
• Slow Mail Agent (dbSearch) CPU 使用率是 624 秒。
• Slow Mail Agent (GetMail_ftSearch) CPU 使用率是 281 秒。
• Slow Mail Agent (GetMail_ByView) CPU 使用率是 56 秒。
• Slow Mail Agent (ByViewEntryCollection) CPU 使用率是 50 秒。

应用程序内存探针

接下来，我们将注意力转向 Memory Usage 探针。DDM 的目标是识别问题，而不是提供每个代理的状态报告。Memory Usage 探针测量并评估每个代理使用的内存。为了提供有用的信息，而不降低服务器的性能，此探针仅测量后端内存池，而不是此代理使用的每个字节。Domino 内存管理相当复杂，并且对许多不同的内存池进行操作，这些内存池根据需要完成的任务而分配使用。后端内存池用于为 Domino 对象（如 NotesDocument 和 NotesSession）分配内存。后端内存池的使用率与整体内存使用率有很强的关联性，这就足以帮助我们识别内存的过度消耗，而无需测量代理使用的内存的每个字节，我们只须报告内存使用率的等级，而不必报告更详细的数字。

任何被评估为在运行时内存具有 Very High使用率的代理，都有威胁服务器稳定性的潜在可能，应该重点关注。

代理运行结束时，将释放该代理使用的内存，因此等级是基于代理运行过程中的最高内存使用率而生成的。与 CPU Usage 探针相似，Memory Usage 探针仅测量属于同一个代理的线程上的内存，即使该代理在一个进程中的一个线程上或者在其他多个活动线程上运行也是如此。

代理的等级取决于两个因素。首先，此代理使用的可用后端内存的百分比，其次，该代理是否必须与在同一进程中运行的其他代理共享内存。在 HTTP 中配置 Web 代理并行运行时，可用内存池必须由同时运行的所有代理共享。为了服务器在高峰负载时可以正常执行，每个代理必须简洁而高效。

注意：在 Internet 协议的 Server 文档中的 Domino Directory 中将 Web 代理配置为串行或并行运行 — Web 服务器引擎选项卡的 Web Agents 部分。默认是串行运行代理。

另一方面，代理在可以使用整个内存池的环境中运行，则能够使用更多的资源。配置为连续运行代理的 HTTP 就是这样，由 Agent Manager 运行的代理也是这样，在 Agent Manager 中，并行代理在单独的进程中运行。代理在 HTTP（在并行代理模式下）或在 Agent Manager 中运行时，Memory Application 探针对该代理的分级不同。对于下面的例子，我们在 HTTP 和 Agent Manager 中运行同一代理，您可以看到 HTTP 中的等级是非常高，Agent Manager 中的等级是高。

图 4. Memory Application 探针

Memory Application 探针测量代理执行过程中的最大占用资源。使用一个包含两个 Java 代理的例子可以很好地说明 Memory Application 探针显示哪些内容以及它如何可以用于优化代码。这两个代理几乎是相同的，惟一的区别是，一个代理使用再循环方法，而另一个不使用。不进行再循环的代理完成时，在执行代理完成逻辑的清除部分的过程中，Lotus Domino 会代表该代理再循环该代理中使用的对象，但是该代理执行期间的占用内存要大得多，因为后端内存将不释放，直到该代理结束为止。

下面是没有再循环方法的代理 jMem_5000 的代码片断：

newDoc.appendItemValue("Form","JournalEntry");
newDoc.appendItemValue("Subject","removeme");
RichTextItem rti = newDoc.createRichTextItem("Body");
rti.appendText("lotsoftextgoeshere");
myArray[i] = newDoc; 
// ... //
depth = myArray.length;

下面是具有再循环方法的代理 jrMem_5000 的代码片断：

newDoc.appendItemValue("Form","JournalEntry");
newDoc.appendItemValue("Subject","removeme");
RichTextItem rti = newDoc.createRichTextItem("Body");
rti.appendText("lotsoftextgoeshere");
myArray[i] = newDoc;
// ... //
myArray[i].recycle();
myArray[i] = null;
depth = myArray.length;

下面是 DDM 输出中每个代理的内存报告：

图 5. 内存报告

全文索引操作

性能问题的另一个常见来源是，对非全文索引数据库进行的全文操作。这些操作引起问题的原因是，为了执行全文操作，需要创建临时索引。执行该操作后，删除临时索引。如果代理基于关键字匹配将收到的邮件分到文件夹中，则每次代理处理邮件消息时，都会创建和删除临时索引。如果公司的策略是不为邮件文件创建全文索引，则对于具有对邮件分类的代理的任何用户，每次邮件消息到达时都会发生这种操作。

有两种方法在代理中调用全文搜索，如下所示：

• 使用全文搜索方法，例如：Set dc = db.FTSearch( query$, 0, _FT_SCORES, FT_STEMS)。
• 在代理的 Document Selection 区域指定要匹配的关键字。

在选择标准中选择关键字可以用于任何代理中，包括简单操作代理，甚至非编程人员也经常使用它们。我们发现许多人不知道选择标准调用全文搜索，所以我们想在本文中着重讲述这一点。

在 Lotus Notes/Domino 6 中，我们对服务器控制台生成警告，指出此操作严重影响性能：

01/18/2005 05:10:58 PM Agent Manager: Full text operations on database 'c:\notes_server\data\my\LS_Memory.nsf' which is not full text indexed. This is extremely inefficient.

在 Lotus Notes/Domino 7 中，通过 DDM 探针，我们可以通过按数据库分配对非全文索引数据库的全文操作，来提供额外的有用信息，从而您可以看到对哪些数据库的查询最多。此额外信息可以帮助确定创建全文索引对哪些数据库最有益。

图 6. Domino 事件

回页首

代理和 Web 服务的 Profiler

识别了引起问题的代理后，使用 Profiler 可以帮助优化代理代码。Profiler 可以测量执行代理逻辑中的每个方法所花费的时间，从而帮助识别瓶颈。通过此工具，可以将精力集中于花费时间最多的那部分代码，以获得最大的效果。

Profiler 分析 Java 和 LotusScript 后端方法。它分析 Domino 后端方法，即对后端对象（例如，dir.OpenDatabase("db.nsf")）进行操作，而不是对标准语言结构（例如，Open fileName$）进行操作。

要分析代理，必须为该特定代理开启代理分析。此设置位于 Agent Properties 框的第二个选项卡中。

图 7. Agent Properties 框

开启分析开关后，下次代理运行时将分析该代理。分析代理时不管它们的运行方式（例如，作为计划代理、作为 Web 代理或手工从 Action 菜单运行）。分析信息存储在与该代理关联的数据库中的 Profile 文档中。

要查看分析信息，在 Domino Designer 中选择分析的代理，然后选择 Agent - View Profile Results。图 8、9 和 10 显示了本文中例举的多个代理的 Profiler 输出。在每个 Profiler 输出的顶部，可以看到代理的名称和分析的时间戳记。累计时间是代理运行的总时间，然后是总测量时间，该时间通常会有点少，因为时间值进行了四舍五入以便于显示。例如，在下表中，小于一毫秒的值显示为零。分析表包含类、方法、操作、对该方法的总调用数、该方法的所有调用花费的总时间。表中的信息按降序排列，花费时间最多的方法显示在最上面。

图 8. Slow Mail Agent (ByViewEntryCollection) Profile


图 9. Slow Mail Agent (GetMail_ftSearch) Profile


图 10. Slow Mail Agent (AllDocs) Profile

查看这些 Profiler 例子时，请记住以下几点：

• 在每种情况中，分析的代码都用来查看服务器中的邮件文件并计算每个数据库中每个文档大小的总和。这是个非常枯燥的任务，可以通过许多方式完成，非常适合于本文的研究。我们使用多种不同的方法对此任务进行编码，以说明 Profiler 的功能。
• 在每个代理的分析输出中，最上面的一个或两个方法会占用总执行时间的很大部分。知道必须用时间除以调用数以得出每次迭代的时间。在一些情况下，这可能会使您不想优化该代码，但是在另一些情况下，例如本文这些情况，它仅是促使找到最好 方法来获取文档集合。
• 按照本文前面的发现，对比其他获取数据访问的方法，使用 set nvc = view.GetAllEntriesByKey 是非常好的执行程序。

回页首

结束语

性能调优是技术与客户日益增加的需要和期望之间的一场持久战争。我们希望本系列文章中提供的信息、技巧和工具能够对您有益。