介绍
如果你已经确定在你的Domino服务器上有性能问题，你现在应该做些什么呢？
性能问题的一个主要障碍是问题的实质总是难以捉摸的。系统某个区域的问题的解决有可能取决于一个完全不相关的区域。因此，在这种情况下，问题真的被解决了吗？即使问题解决了，问题的实质依然很难确定。所以，可能你仅仅是暂时减轻了症状而已。由于计算机系统的复杂性，性能的改善或者恶化可能会以一种平稳的方式进行，也可能是突变式。一个渐变式性能恶化的例子是：当将一些用户添加至一台服务器时，服务器的总体性能逐渐降低。再举一个突变式性能恶化的例子，修改一个应用程序使得它能够存储和读取更大的notes可能导致NSF缓存超过它的最佳使用率，进而使得磁盘IO访问大量增加，最后导致服务器性能恶化。在渐变式的变化中，运行过程中的小变化只会对性能造成比较小的影响，而对于突变式，运行过程中一个小的变化经常会对性能产生巨大的影响。如果有可能，你应该尽量每次只做一个修改，然后密切地监视系统性能的变化情况。
本文不是为了帮助你如何实现性能最优化，而是关注那些服务器性能受系统不利因素影响的问题，这和前者有很大的不同。我们将一步步地对问题进行分析，包括：问题是什么？记录问题的实质，诊断问题并采取修正操作，最后确定我们采取的修正操作是不是有效的。
定位
首先考虑下面这些问题。
1) 问题的现象是什么？问题看起来是什么样的？问题存在的迹象是什么？重点是定义正常的情况。一个性能问题的存在使得服务器运行不正常。为什么我们需要明确这些呢？ 很多次，客户确信Domino服务器有问题，但又不确定正常的运行情况是什么样的。比如说，解决一个磁盘性能时遇到的网络问题，但是我们怎么知道对于系统来说正常情况是什么样的呢？是10MB/sec正常还是100MB/sec的速度是正常的？
在处理性能问题时，我们一定要明确地知道系统的正常状态。如果我们通过深入调查能够使得性能变好为什么还要做这件事情呢？那是因为必须找出影响系统的一组变量集，一旦我们找到了这些变量，并作出必要的改动，服务器的平衡和正常运行已经恢复。一旦我们超越解决这些导致偏离正常状态的问题时，我们开始进入了一个不同的舞台上。现在，对系统的作出的改变不是为了恢复之前的平衡，而是要改变系统到一个新的和可能更好的状态。在这一点上，改动变得更加实验性，而不是修正。虽然并不完全是一件坏事，这些改动可能会使得事情更加糟糕，这个问题的范围变得永无止境。
2） 另外一个要问的主要问题是：问题在来自“哪里？” 为了回答这个问题，把你的系统分成两个逻辑独立的区域： 资源和资源管理。我们可以对这些区域再进行划分。对于资源而言，按照CPU，IO和内存来划分。IO又可以再细分为磁盘 IO 和网络IO。 而对于资源管理，划分为应用（比如Domino），操作系统和硬件。为了更加直观，我们绘制了下面这张图：
你会惊讶于有多少人未能沿着这些方针来考虑问题。因为那么多的计算区域会重叠，解决的的也并不一定是问题所在，大多数人将依赖直觉和经验。尽管这样可能有效，经验需要长时间的积累，而且不可能教别人如何来根据直觉解决问题。这样做是不可取的，尤其是对于相对 比较新的性能故障排除问题，它有可能会导致误解和错误的诊断。通过对资源和资源管理使用分层方法，我们能够使用每层的逻辑来定位问题来自哪里。
3 ）问题的重现率怎样？这相当重要，因为没有某种程度的重复性，我们就没有办法确定问题是什么，如何做出修改。又怎么记录或测试以确定问题是不是真是我们当初所认为的问题？如果问题仅仅发生一次，我们不能区分是它是一个问题或者仅仅是个随机事件..如果我们不能收集关于问题的数据，那么我们没法做出决定。因为性能问题的解决本身就绝不是一个具体的过程，问题的解决过程是一个相当反复的过程，这一点及其重要。如果你能够对照上面的表格指出问题是什么固然是好，但更经常发生的情况是：你在几种可能性之间来回反复，或者根据你的经验和专家意见猜测一种最可能的解决方案。
文档记录
文档记录是任何类型问题判定的关键因素，性能问题也不例外。文档记录使得性能问题的诊断不再是一个随意的过程，而是一个科学分析的过程。当然我们可以根据对问题的猜测来对系统做出修改，但如果你没有证据证明问题所在，基本上也只是猜测而已。考虑到你可能在与一些不同的对象打交道而且试图向你的管理层提出一个行动的意见，问题是：怎么能够让不同的人都理解你所说的。这确实经常发生，并且有时别人理解的和你所想表达的相去甚远。无论如何，为了支持你的观点，你不仅需要确定问题存在于哪个部分，还需要明确性能问题所带来的变化。这样，即使你自己不能确定问题的根本原因，你也具备了跟别人讨论的基础，当然为了表明系统有所变化，你需要保存问题出现之前系统的统计数字。保存这些数据的代价是很低的，但它却会极大地减少你解决问题的时间。尽管没有问题时这样做好像不重要，但是当问题发生时，文档记录就会变得非常有价值。
下面的表格列出了一些在windows平台上有用的故障诊断工具：
NSD， 信号量调试工具， Domino 系统统计（sh stat）在对性能问题进行故障诊断时特别重要。
信号量是用来对资源访问限制的一个变量。例如，用信号量来保护一个文件免受并发访问。信号量可能是个bit值，其中 1 代表这个文件正在被使用而0 代表这个文件没有被使用。这样如果另外一个过程想使用此文件，在获得这个文件访问权之前，进程先检查信号量，如果没有进程在使用这个文件 (0) ，则将信号量置为1。由于 Domino 系统使用非常多的共享资源，并且多个进程争抢这些共享资源，你可以使用Dimino的debug工具（在notes.ini 中设置debug_capture_timeout = 1），用它可以查看那些占用太长时间处理的信号量请求。这个信息非常有价值，因为当Domino服务器响应很慢时，通常是由于它处在等待中，而利用这个debug工具能够发现什么使得Domino服务器处于等待状态。
NSD工具被认为是分析Domino性能相关问题的利器，NSD 给出服务器状态的所有当前信息（所有线程的调用堆栈、内存信息，配置等等），NSD的两个核心是堆栈信息和内存检查，堆栈信息是平台无关的，不论在什么平台上，NSD都会记录所有Domino进程中每个线程的函数调用路径。通过查看堆栈信息中最上面的函数，我们知道线程的最近的活动信息。 在下面的例子中，nserver进程68个线程中的第53个线程正在休眠，基本上，它没在做什么事情。而nsched进程3个线程中的第1个线程正在试图锁住内存。如果我们想知道它是否成功，可以生成另外一个NSD文件来查看这个线 程是不是成功地运行过去。
NSD工具的内存检查能够记录当前Domino服务器内存使用情况，包括系统内存、句柄、网络使用信息、使用中的数据库结构以及文件使用信息。由于不是本文涉及范围，故不在此赘述。但是，我想说的是，内存检查对各种性能问题依然是非常方便的工具。
Domino统计（show stat）可以从统计的角度对当前状态提供深刻的理解。尽管可以用statrep收集历史的统计信息，在Domino控制台键入“show stat”来获取问题发生时的数据往往更加有效。
诊断
在性能故障诊断的这一阶段，你可以开始把每个领域的专家们加入进来。在这里，你的任务是解释观察到的结果是什么，并从这推断需要做些什么。然而这并不像听起来的那么简单。确定问题的根源不仅需要知识，还需要理解在文档记录阶段获取的数据结果。举例来说，一个人收集的统计信息可能表明，内存利用率不是很好（如：拥挤拒绝）。一位在这方面的专家可能认为，问题无疑是缺乏可用内存。而另一位专家可能会觉得水印无关紧要，不太可能是造成问题的原因。这里的主要缺陷是，我们进行的修改影响的只是我们记录的，而不是问题本身。这进一步坚定了需要明确具体关注的问题，当改动产生预期效果的时候你才可以真正地得出结论，它是基于问题的症状，而不是我们认为我们所看到。
在这一阶段的主要障碍是： 要对各个资源的各种资源管理的架构上的局限和操作有一个深刻的理解。当然，这是一个相当广泛的专题。这也就是为什么要组织各方面专家参与的原因。
对于每一块区域，我们需要问自己， “这个问题主要是吞吐量问题还是带宽问题？ ”换句话说，是我们限制了能够使用的资源或是资源缺乏，是什么原因造成了这个问题。带宽问题往往体现的是硬件问题，而吞吐量的问题往往是操作系统的或者应用程序的问题。例如，在某些情况下，我们已经看到在使用内格尔算法（数据捆绑在一起，以减少数据包发送）会对性能产生负面影响，因为系统由于人为的拖延而等待。在这种情况下，并不是说是缺乏足够的带宽，而是缺乏带宽利用率。有一点需要牢记的是资源使用效率往往会导致人们认为耗尽资源而实际上它是一个吞吐量问题。如果系统没有了可用的CPU，自然的反应是增加CPU，然而再仔细检查，发现该处理器产生异常多的上下文切换。在这种情况下，造成性能问题的原因并不是没有足够的CPU ，而是CPU使用的方式。
测试
最后，在变更之后，需要测试，看看它们是否起到了预期的效果。我们的测试是相对容易的。因为我们只需要根据已知的常态来确定现状是否已恢复正常。我们也要监测统计数据，这些数据帮助我们发现并关注问题及其根源。统计数据应该与我们所做的变更相匹配。否则就证明这个问题是我们意料之外的非正常问题，必须重新启动程序。
为了更好地了解如何应用这里提出的这些原则，在本文后面的篇幅里，我们会探讨您可能会遇到的不同类型的问题。我们将用一些例子来说明我们使用了什么样的工具，为什么选择使用它们。最后，我们将分析为什么我们这样诊断以及解决了什么问题。
注意：不要被理论束缚。性能问题并不总是一个简单的一次方程。甚至是为了初步确定问题所属的领域，都需要至少迭代每一个可能的解。如果它是一个更深入的问题，您可能需要更深入的迭代。这就是为什么集所有功能于一身的工 具，如NSD，是如此宝贵。
Back to top
CPU
问题定位：通常情况下， CPU的问题分为两类： 1）高CPU负载（即CPU的运行达到或接近100％），或2）CPU负载非常低，即使整体Domino的性能缓慢低下。您可以在硬件级，操作系统级或者应用程序级(Domino)管理CPU。
硬件： 硬件级是CPU管理三个级别中最基础的一级。BIOS将支持某一特定数量的CPU，并报告操作系统所安装CPU的数量。如果在700Mhz的单CPU上运行三个分区的Domino服务器，就会遇到性能问题。在这种环境下，该系统无法满足三个服务器对CPU的最低需求。很可能第一次运行时，服务器的性能没有影响。但是随着时间的推移，服务器负载就会改变，从而影响系统性能。
附加层通常由大系统如AIX，i系列（AS/400的）或Z系列（OS/390）构成。这些系统可以让系统管理员配置物理系统的逻辑分区（LPARs）。每个逻辑分区可以被分配到完整的CPU，部份的CPU，或多个CPU。管理员要知道每个逻辑分区的资源分配，这一点很重要。例如，如果一半CPU用于单一逻辑分区上三个分区服务器的运行，那么CPU很容易就达到100％，这将导致性能低于服务器性能标准。
操作系统
操作系统级将确定硬件如何执行以及用在通常开销的CPU总数。除了 操作系统及其相关附加任务所产生的CPU负载，也必须考虑服务器上运行的其他应用程序产生的负载。例如，如果 Domino 系统在一个域的主控制器上运行，此控制器同时也是 DNS 和 DHCP 服务器，那么相对于Domino运行在一个专用系统上来说，会消耗更多内存。
当某一应用程序请求一页内存，操作系统将实际内存交换到虚拟内存来响应此请求。这种情况下，Domino的性能也会受到影响。这一过程，被称为内存分页，是大多数系统的正常过程。随着内存分页增加，磁盘IO也会增加从而减慢了操作系统响应时间。如今物理磁盘的吞吐量和存取速度有了很显著的提高；但磁盘读取仍然慢于内存读取。随着内存分页的增长，操作系统会出现震荡，一旦该系统达到震荡的状态，它将花费更多的时间来交换内存，而不是处理CPU请求。
因此，这一系统已无法在合理的时间内作出反应。在操作系统级别，可以为特定的程序或线程设定优先级。尽管Domino被设计成以最优线程优先级安装，但也有可能某一线程的优先级需要加以调整，以提供更好的用户体验。
Domino服务器的任务、功能、或者用户数的增加会使Domino服务器的系统负荷加重。随着用户使用Domino的增加，他们可能会扩大其使用的范围和负载。有时一个线程可能会占用大量的CPU ，但在其他时间，一个线程可能会在锁定状态，导致其他线程等待待释放锁。Domino服务器能够控制系统的负荷，通过使用一个notes.ini设置，这个设置能够限制在一个给定的分配并发线程的数量。这样当达到最大并发线程数时，线程将进入等待状态。即使是编写一个代理的方式也可以影响Domino服务器的总体性能。如果在一个代理里对一个没有建立索引的数据库执行全文搜索，Domino会创建一个临时的全文索引。使用之后，这个索引即被删除。但是下次再次执行代理时，无论数据库有没有变化，都会再创建一个临时全文索引。这增加了额外的开销并降低了代理执行的效率和服务器的性能。总之，系统管理员可以通过配置Domino服务器来服务预期的负载。系统管理员配置服务器的方式会决定变化对总体用户的影响。
数据收集：
这个部分将描述与 CPU 有关系的 潜在的瓶颈。应该收集的数据将取决于我们怀疑的问题。有些数据来源于系统的环境参数，这需要跟硬件管理员讨论来得到。有些数据则来源于操作系统级别的工具，有些则来自于Domino服务器。记住：一些系统可以限制每 LPAR 被分配的CPU数量。可能物理系统本身有24个CPU，而装Domino的LPAR逻辑分区只有一个CPU。
硬件：
关于硬件的数据收集，可能会因使用的操作系统而不同。例如，在AIX系统上，系统设备信息列在生成的NSD文件中，包括系统配置的CPU清单及其设置。下面的列表来自一个大型AIX系统。该NSD表明：系统总共有4个CPU分配给LPAR逻辑分区。在物理系统中还有额外的CPU没有分配给这个逻辑分区。System Devices:
===============
name status location description
proc0 Available 00-00 Processor
proc2 Available 00-02 Processor
proc4 Available 00-04 Processor
proc6 Available 00-06 Processor
而在一个windows 平台产生的NSD文件中，这些信息是位于输出信息的顶部并列在OSVersion那行（OSVersion : Windows XP 5.1 (Build 2600), PlatID=2, Service Pack 2 (1 Processor) ） 。这一信息是从操作系统传递过来的。我们在Windows系统的系统属性窗口也能看到这部分信息。处理器的速度和数量将决定Domino分区的数量，以及能够跑的用户数和任务。欲了解更多有关筛分Domino服务器的信息，请参阅以下内容：
"Domino for IBM xSeries and BladeCenter Sizing and Performance Tuning" and "Domino for iSeries (AS/400)".
操作系统
有许多工具可以查看系统的CPU使用率。对于Windows系统，可以使用Windows任务管理器。
以上数字表明， CPU的使用率为100 ％ 。一种情况是，管理员中午启动了磁盘清理。 cleanmgr.exe线程使用了93 ％的CPU 。直到该线程释放CPU，响应用户时间才会有所减少。仅仅CPU使用率达到100 ％并不说明什么问题。查看什么线程或进程正在使用的大部分CPU才能发现根本原因。在Domino的启动过程中，CPU使用率会有一个急剧增长，这是正常的。一旦服务器启动完成负荷将减少。
Domino
Domino有自己的一套收集信息的工具。包括Domino统计（show stat）或Domino服务器信息屏幕（show sever），例如：
[01A8:0006-08F8] Lotus Domino (r) Server (Release 6.5.3 for Windows/32) 04/10/2006 04:22:55 PM
[01A8:0006-08F8] Server name: SET_Test1/Support
[01A8:0006-08F8] Server directory: g:/notes/data
[01A8:0006-08F8] Partition: g.notes.data
[01A8:0006-08F8] Elapsed time: 01:10:17
[01A8:0006-08F8] Transactions/minute: Last minute: 6; Last hour: 4; Peak: 23
[01A8:0006-08F8] Peak # of sessions: 2 at 04/10/2006 04:20:55 PM
[01A8:0006-08F8] Transactions: 35 Max. concurrent: 20
[01A8:0006-08F8] ThreadPool Threads: 40
[01A8:0006-08F8] Availability Index: 100 (state: AVAILABLE)
[01A8:0006-08F8] Mail Tracking: Not Enabled
[01A8:0006-08F8] Mail Journaling: Enabled, Local Destination
[01A8:0006-08F8] Shared mail: Not Enabled
[01A8:0006-08F8] Number of Mailboxes: 1
[01A8:0006-08F8] Pending mail: 0 Dead mail: 0
[01A8:0006-08F8] Waiting Tasks: 0
[01A8:0006-08F8] Transactional Logging: Not Enabled
[01A8:0006-08F8] Fault Recovery: Enabled
[01A8:0006-08F8] Activity Logging: Not Enabled
[01A8:0006-08F8] Server Controller: Not Enabled
[01A8:0006-08F8] Diagnostic Directory: g:/notes/data/IBM_TECHNICAL_SUPPORT
[01A8:0006-08F8] Console Logging: Enabled
[01A8:0006-08F8] Console Log File: g:/notes/data/IBM_TECHNICAL_SUPPORT/console.log
上面输出显示： “Availability Index: 100 (state: AVAILABLE),” ，它代表了服务器可用性指数（SAI） 。SAI是一个从0到100的数字，代表了Domino服务器的相对可用性。每个Domino服务器基于最近处理请求的响应时间定期决定自己的工作量。工作量表示为一个从0到100的数字，其中0表示负载过重的服务器和100表明负载较轻的服务器。重要的是要认识到，SAI不是一个百分比。在Domino 6.x和更高版本中，SAI通过查看以下区别计算而得：空载系统中处理事务花费的时间和满载系统中处理事务花费的时间。SAI可以调成取决于系统硬件能力。请记住，SAI是服务器的相对可用性。每个服务器基于负荷和服务能力可能有不同的SAIs。SAI变化则表明性能变化。欲了解更多信息，请参阅文件，题为“Domino 6.x Server Availability Index (SAI) -- Understanding How SAI Is Calculated”(#1164405)。
你也可以通过在Domino notes.ini中设置“ Server_Show_Performance = 1 ”使其提供有关性能信息，输出会显示Domino服务器每分钟处理事务的数量以及当前系统中活动用户的数量。这一信息，每隔60 秒记入到服务器控制台，可帮助跟踪在一段时间内系统的性能。它还会显示用户和事务最高峰使用次数。事务包括服务器上处理的所有事务（例如，路由，代理管理器，复制，病毒扫描器，和使用者的动作）。
[01A8:0021-0254] 04/10/2006 04:30:47 PM 6 Transactions/Minute, 0 Notes Users[01A8:0021-0254] 04/10/2006 04:31:47 PM 0 Transactions/Minute, 0 Notes Users[01A8:0021-0254] 04/10/2006 04:32:47 PM 4 Transactions/Minute, 0 Notes Users
诊断和修正操作
随着时间的推移，Domino服务器上的负载可能增加，这可能会影响Domino的整体性能。附加的Domino任务（例如， POP3或HTTP ）和附加应用程序（如，LEI或anti-virus）可能会改变用户的请求响应时间。为了提高响应时间，也许有必要改变硬件水平。这些变化可能包括增加CPU，提高CPU的配置，或平衡CPU负载。
操作系统： 性能故障诊断是一个反复的过程，因此，通过消除一个瓶颈你可能会发现另一个。比方说，通过增加内存解决页面问题后，可能发现我们的系统现在有CPU的问题。
在 Windows系统中，性能监视器（Perfmon）可用于监视每秒的页面数量。当每秒页面数乘以AvgDiskSec每转再乘以100大于12 ％至16 ％ 时它被认为是过度的。（ 100 * （内存：页/秒*物理磁盘： AvDiskSec /转） ） 。下图所示的平均页/秒是129 。
Domino： 在Domino中，用户能够在邮件数据库以及其他数据库中创建代理并安排代理执行的时间。用户代理可能产生足够的负荷在服务器上引起性能问题。代理管理器的默认设置可能不适合 你的环境。通过调整最大并发代理数和延迟前忙的最大百分比（服务器文件中） ，你可以控制代理对服务器性能的影响。除了控制的最大并发代理数，你也可以限制谁可以在服务器上运行代理。（默认情况下，每个人都可以运行简单公式代理）。你可以通过在非高峰时段执行代理来减轻由代理引入的性能问题。
代理中的函数调用也可以影响Domino服务器性能。用户可能会创建一个简单的代理来执行邮件文件中的搜索功能。如果邮件文件没有全文索引，代理调用全文搜索时会导致服务器生成一个临时的全文索引。这个全文索引将只使用一次，然后销毁。以下是当代理创建临时全文索引时写入控制台的日志：
[13970:00002-00001] 12/11/2003 08:09:01 Warning: Agent is performing full text operations on database 'mail/USER.NSF' which is not full text indexed. This is extremely inefficient.
如果这个代理每十分钟运行一次，那由于创建临时全文索引引入的额外负载将会对服务器性能产生重大影响。管理员可以通过手动在邮件数据库上创建全文索引很容易地避免这个问题。这样，代理可以继续运行，但是对服务器性能产生的影响会更小。
经常，Domino服务器配置为提供某一特定服务（例如，邮件服务器。）随着时间的推移，服务器的功能将扩大到更多的任务如HTTP。通常情况下， HTTP被认为是一个非常轻负载，仅仅提供网页服务。然而，当用户通过HTTP访问他们的邮件文件，并且网页是动态时，负载就会急剧增加。你可以通过将某些任务移到其他服务器来均衡负载。有时候，作为主服务器Domino服务器负载增加时，就有必要增加额外的服务器以处理增加的负载。
当整个服务器的性能很差而CPU的负载还很低时，这可能表明Domino节流问题发生了。另一种较常见的表明节流问题的是在堆栈调用中发现了OSWaitEvent调用，而这个调用与特定信号量锁定或第三方应用程序都无关。在Domino中，通过设置Server_Pool_Tasks 和 Server_Max_Concurrent_Trans两个Notes.ini参数，你可以控制工作线程数和并发处理线程数，可以通过使进程同时对notes.ini参数
Server_Pool_Tasks 和 Server_Max_Concurrent_Trans:
Server_Pool_Tasks - 该设置控制IOCP线程池（每个端口）中物理线程的数量，该线程池可以在服务器上运行。注：由于用于正常开销线程的存在（如维护线程），运行时总线程数将永远高于NSD中的线程数。
Server_Max_Concurrent_Trans -该设置控制并发处理事务的物理线程的数目。这种控制在引进Domino 5.x IOCP线程池之前具有特别重要的意义.在Domino 5.x和更高版本中，此参数可以用于控制并发事务的数目，此数目会影响到特定时间内所需虚拟内存的多少。
Server_Max_Concurrent_Trans默认值为20。默认值为Server_Pool_Tasks默认值是Server_Max_Concurrent_Trans的二倍。Server_Pool_Tasks用于确定Domino服务器线程数目。服务器线程数定义为Server_Pool_Tasks乘以NRPC端口数。
对于有大量实际内存的大规模服务器来说，有两个参数需要提高以获得最佳性能，分别是足够大的虚拟地址空间和CPU处理能力。
增加Server_Max_Concurrent_Trans和线程池应在一个受控的进程中完成。如果池增长得过大，服务器可能会变得不稳定。不建议设置Server_Max_Con current_Trans为”-1”或“1000”，因为这些值允许无限次的并发事务从而导致不稳定。Server_Max_Concurrent_Trans的有效范围为20和100之间，只要有可用的CPU。由于服务器线程消耗系统资源（内存，CPU，网络），服务器线程总数需要被管理，这一点就显得格外重要。一台服务器能支持多少服务器线程取决于服务器配置。通常情况下，80-150是服务器线程可以接受的最大范围。
信号量挂起是导致系统缓慢的另一个原因。Domino使用信号量控制对关键功能和数据的访问。有些时候信号量会被锁定和释放。在此过程中，一个线程可能要等一个它需要的信号量。所谓“等”并不是挂起，而是正常的Domino处理线程。当信号量被长时间锁定，就可能发生性能问题。这些问题可能会表现为客户机与服务器连接，邮件延迟，和/或代理延迟。举一个关于长时间锁的例子，即病毒扫描应用程序锁定mail.box来扫描邮件。在这段时间内，Domino路由可被锁定在mail.box之外，这将导致信息传递耗费比预期更长的时间。与自定义代理或用户代理不同，不能简单地关闭病毒扫描程序以提高其性能。在这种情况下，使用多个mail.box数据库或增加病毒扫描线程有助于减少递送时间。
要确定哪个线程持有锁，必须启用信号量调试。这将在Domino服务器的IBM_TECHNICAL_SUPPORT目录中产生一个SEMDEBUG.TXT文件。除了SEMDEBUG.TXT文件还需要一个从性能下降那一刻开始的NSD。该SEMDEBUG.TXT文件会显示持有锁的线程ID和等待锁的线程ID，以及正在使用哪一个信号量。该NSD也可以让您用一个线程ID来标识一个线程/任务名字。
关于信号量的更多信息，请参考《Semaphores and Semaphore Timeouts》一文(#1094630)。
Back to top
内存
问题定义：
内存是性能问题关键的重点领域，主要是因为进程如此严重地依赖于内存以保持其速度。因此，与内存有关的问题很容易就对Domino性能产生明确而重大的影响。一般来说，内存的问题归结为：1）没有足够的内存，或2）有足够的内存，但没有很好的管理（例如，低配置）内存管理，发生在如下层面：
硬件（BIOS，PROM，固件等）
操作系统（虚拟内存管理器）
应用（Domino的内存管理器）
硬件
硬件级别通常是最基本的。BIOS代表什么内存可提供给操作系统。你应该确认内存报告的正确性，物理内存的可用性，并且BIOS正确地报告了系统的内存。
操作系统在操作系统级别，内存作为磁盘高速缓存和一个工作集。磁盘高速缓存（文件缓存）是RAM的一部分，用来是暂时搁置从磁盘读取的数据。磁盘高速缓存不需要像RAM磁盘一样存储一个完整的文件，它可以容纳运行应用软件的部分或部分数据文件。欲了解更多信息，请参阅以下链接： http://www.microsoft.com/technet/archive/wfw/7_agloss.mspx?mfr=true 。工作集是可执行的页面，功能和指示。实际上在可执行文件的操作阶段中，工作集被装载入内存。更多信息参见如下网址：techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi .
操作系统内存管理器的一个关键功能是通过平衡使用物理内存（RAM）和磁盘操作来达到最佳性能。通过这样一种方式：分出部分磁盘空间（分页空间）与内存结合创建出一个虚拟内存空间，操作系统将最大限度地利用内存。这就使人感觉应用程序使用了更多的内存，即使整个空间都不是物理内存。有必须提到的一点重要区别，所谓“内存问题”往往是指内存如何均衡，而不是内存量本身。
例如，如果应用程序认为它只有500MB的内 存，并且可以利用所有的这些物理资源，那么它就可以正常运行。但是，如果应用程序认为它有1GB内存（500MB物理内存空间和500MB分页空间），它的执行反而会显著的恶化。因为应用程序假定所有的内存都是一样的，从而试图利用更多的内存，而实际上却并非如此。突出的一点是，要诊断内存问题，系统管理员要如何了解这些差异以及内存管理器要如何去做。
最后，让我们谈论Domino和其内存管理器涉及到的一些问题：从本质上讲，Domino依靠自身的内存管理器来实现内存请求。实现时，从不同大小的池中取出内存，每次都有不同原因。有一点很重要，每个池的大小是受限的，而且每个进程都受到被分配到的句柄数量的限制。其中最大的池被称为UBM缓冲区，有时被称为NSF缓冲池。因为它作为一个中央资源，整个内存使用按照每个单一池的大小来排序。
在这一层次上，我们关于内存的主要顾虑是：1 ）我们是否有足够的内存来满足Domino内存管理器的需求？2）池如何被使用？这一点是否有什么问题？
在最基础层面上，真正重要的问题是，内存可以被使用。但是每一层内都可能会出现由于内存管理陷入困境而引起的问题。通常，起因是内存不够或者使用低效。在大多数情况下，只要增加内存就可以解决这类问题。可是对每一层来说也都有其限制条件。举例来说， Windows操作系统每个进程只能使用2GB的用户虚拟地址空间，所有进程总共也只能使用2GB的用户虚拟地址空间。这意味着，没有一个单一的Domino进程可以使用超过2GB的内存（私有内存+映射共享内存）而且用户使用的内存总和也不能超过2GB。此外，Windows的磁盘高速缓存，页表项，页池等都是有限的。另外，Windows默认配置支持4GB内存。
数据收集：
本节介绍一些内存潜在的瓶颈和症状。
硬件： 1 ）是否有足够的可用内存（通过任务管理器或Perfmon来报告）硬件问题主要表现为缺乏资源。硬件问题和操作系统问题的关键区别在于，硬件问题关注于多少内存可用以及实际物理存储的状况；而操作系统问题关注于我们如何让内存可用。Windows内存管理器的一个局限性在于，缺乏合理配置，有时会隐藏起操作系统的问题。判断一个问题是否为硬件问题，最好的办法就是看看增加或者改变RAM是否会产生不同结果。
2 ）存储器是否有问题？有时候是硬件资源本身的问题，通常表现为无规律的错误和性能状况。这通常会导致崩溃；损坏的存储芯片也会对性能产生不良影响。例如，一个服务器可能性能较慢运行一分钟，然后在下一分钟重启。运行Memtest86（ http://www.memtest86.com ）是检测存储器芯片的好方法，它通过在一定的情景下穷举检测每个内存地址的办法来查看芯片问题。
操作系统
在处理操作系统内存问题时，您可以使用下表来确定有哪些类型的问题要问。
在Windows平台上，可以通过perfmon来得到这些统计数据。 • 内存计数器 - 可用内存。 • 可用字节 - 可用内存字节<50MB。或者您可以使用Domino 的Platform.Memory.RAM.AvailMBytes参数。
- 内存对象-页/秒 sec计数器。页/秒是指每秒钟读写磁盘的页数，以解决引用的页不在内存中的情况。这在一个进程必须从磁盘获取数据时可能发生。本质上讲，这个统计数据并不一定意味着在高度分页时期内，从磁盘读取数据时，就缺少内存。但高的页/秒确实表明了系统正多么艰难的努力满足内存请求。内存对象的统计资料应当与可用字节数的统计同时使用，以确定是否发生了内存状况。
- 内存对象 – 非分页池字节计数器。 非分页池是系统内存的一个区域，它不能被写出到磁盘（换句话说不能被分页置换出来）。由于此池的这一局限性，操作系统必须限制其规模。如果此计数器大小超过115 MB或如果分页池总计超过256 MB，就可能出现问题。需要参照使用的IO缓冲，设备驱动程序，和TCP会话。
- 内存对象 – 分页池字节计数器。相对于非分页池，分页池代表内存中可分页到磁盘的区域。如果这个值超过156MB ，或加上非分页池超过256MB，就可能出现问题。需要参照内存映射文件，共享DLL，注册表大小和Windows用户会话。
- 进程对象 - 虚拟字节计数器/任务管理器 - VM的大小/任务管理器 - 可用内存。使用perfmon或任务管理器你可以快速查看到每个进程使用了多少虚拟地址空间。对于Windows ，每个进程虚拟地址空间限额2GB。虽然这并不一定是根本的瓶颈，因为Windows操作系统在默认情况下只能使用2GB的用户空间与4GB的最大物理内存。由于Domino系统将运行多个进程，一个进程不太可能在达到系统上限之前先达到了虚拟空间上限。但是，通过统计数据，可以了解每个进程正在使用多少内存。
下面的截图所示每个进程的虚拟内存大小（ VM的大小）。要显示任务管理器中VM的大小一栏，请选择查看- “ >选择专栏- ”虚拟内存大小。
Domino
Domino统计（查看统计）
• Database.BufferPool.PerCentReadsInBuffer 。该缓冲池代表Domino正使用的最大单一内存区域。 Domino使用该缓冲池作为高速缓存，这是高速缓存作为一个实现索引功能的缓冲区。如果此值低于85 ％并且Database.BufferPool.Peak等于Database.BufferPool.Maximum，就应采取措施，以增加缓冲池。
缓冲池的大小可以间接地的通过改变Domino所见内存(ConstrainedSHMSizeMB/PercentAvailSysResources/MEM_AddressableMemSizeMB)的大小来增减，也可以直接通过NSF_BUFFER_POOL_SIZE参数来增减。使用这些设置时必须小心。Domino可用的内存量设置过高会影响系统的稳定性；而设置太低，会影响系统性能。参阅文件 “How Much RAM will Doimnio Use?” (#1093891) 。对AIX，参阅 “"Lotus Domino on AIX memory usage explained” http://www-128.ibm.com/developerworks/lotus/library/domino-aix-memory/
有些时候读入缓冲区的大小可能设置过大（大于95 ％ ） 。如果池过大，则可能实际上是在浪费内存。850MB的NSF缓冲池如果读入缓冲区占到96 ％，就是在浪费内存，这些内存可用于其它事情。调低缓冲池到400MB，读入缓冲区的内容仍然是运行在92 ％，就可以获 得良好的性能。其余的内存则还给系统分配作其他用途。
· Database.DbCache.OvercrowdingRejections - 一个计数器，用来计算由于数据库缓存过于拥塞而导致的拒绝数量。如果此数据是有效的（即大于50/小时），你应该监测它，看它是否在增长，是否和不当使用有关。如果此数据无效，并且Database.DbCache.CurrentEntries大约等于或大于Database.DbCache.MaxEntries ，你将需要增加dbcache的规模。这可以间接通过增加缓冲池大小或直接通过修改NSF_DbCache_Maxentries参数来做到。
· Mem.Allocated - 服务器的内存总数。
· Mem.Allocated.Process - 单个进程的非共享内存总数。
· Mem.Allocated.Shared - 服务器的共享内存总数。
· Mem.Availability -服务器内存可用性。
<@@
Notes Memory Analyzer (memcheck) -> Shared Memory Stats
TYPE : Count SIZE ALLOC FREE FRAG OVERHEAD %used %free
Static-DPOOL: 111 801112064 662701728 137917400 0 941546 82% 17%
Overall : 111 801112064 662701728 137917400 0 941546 82% 17%
<@@
Notes Memory Analyzer (memcheck) -> Process Heap Memory Stats
TYPE : Count SIZE ALLOC FREE FRAG OVERHEAD %used %free
Static-DPOOL: 32 16777216 10731632 6016300 0 49156 63% 35%
VPOOL : 2 129916 39812 82432 0 7688 30% 63%
POOL : 209 3572332 2414200 1087900 0 77656 67% 30%
Overall : 32 16777216 9561300 7186632 0 134500 56% 42%
这些段展示了从操作系统到Domino的内存分配。从这些数字可以看出有多少内存被从操作系统分配到特定进程堆或共享内存。 “整体”可以看出有多少内存是在实际使用中，以及使用情况如何。看一个共享内存的例子，Domino约有
3MB（ 3097152/1024/1024 ）内存。实际使用的数额约为550KB 。此NSD是服务器刚刚启动后获取的，因此没有太多的活动和高级别的可用内存，这是可以接受的。但是，如果我们发现了在同级别的空闲空间分配了大量的内存（比方说，大于1.5GB ），这就是一个问题，因为Domino没有很好的使用内存。
应该澄清，该进程堆节存在于每个Domino进程。通过使用这些段中的值，我们可以从Domino的角度估算出，在进程级和共享级内存如何分配。我们可以用这些数字来看看总体情况，具体的使用状况，和相关的整体系统，以了解资源用在了什么地方。
For shared memory usage:
<@@
Notes Memory Analyzer (memcheck) -> Memory Usage Summary -> Top 10 Shared Memory Block Usage (Time xx:xx:xx)
@@ >
For process memory:
<@@
Notes Memory Analyzer (memcheck) -> Memory Usage Summary -> Top 10 [ PROCESS_NAME: PID] Memory Block Usage (Time xx:xx:xx)
@@>
BY SIZE
Type TotalSize Handles Typename
0x0f04 420240 51 BLK_FT_SEARCHTABLE
0x29c5 369334 1 ???
0x29c4 196608 1 BLK_SRV_PERFNAV_PERFDATA
0x0130 82998 228 BLK_TLA
0x0149 76076 14 BLK_PHTCHUNK
0x29c3 65406 1 BLK_SRV_PLPOOL
0x29c2 65406 1 BLK_SRV_PS_COUNTERS
0x29c1 49152 1 BLK_SRV_PS_NAMETABLE
0x0380 29358 63 BLK_RM_PTHREAD_TRANENTRY
0x03fe 24576 1 BLK_COMPILER_STRING_STORE_MEM
BY HANDLE COUNT
Type Handles TotalSize Typename
0x0130 228 82998 BLK_TLA
0x0f02 160 17600 BLK_FT_STATIC
0x0275 70 8126 BLK_NSFT
0x0380 63 29358 BLK_RM_PTHREAD_TRANENTRY
0x0f04 51 420240 BLK_FT_SEARCHTABLE
0x030a 47 15794 BLK_LOOKUP_THREAD
0x0149 14 76076 BLK_PHTCHUNK
0x0910 11 5066 BLK_SRV_NAMES_LIST
0x0f5d 2 220 BLK_ISERV_SHARED_DATA
0x0128 1 10480 BLK_PCB & nbsp;
这几段包含了共享内存和私人进程内存的使用情况，并且列出了句柄数十大和总大小十大。很难说某个句柄是否使用过度，因为不同的句柄有不同用途和限制。但是，当结合内存转储，我们就可以得到一些意思的看法：
内存输出共享内存段和进程段如下：
* Dump of Shared Handle Table
HDL 1 0150 S locked, refcnt 6, size 65412 D
HDL 2 0150 S locked, refcnt 6, size 65412 D
HDL 3 0150 S locked, refcnt 6, size 65412 D
HDL 4 0150 S locked, refcnt 6, size 65412 D
HDL 5 0141 S locked, refcnt 6, size 65412 D
MEM 1 0127 S locked, refcnt 6, size 12536 D
MEM 2 0416 S locked, refcnt 6, size 1080 D
MEM 3 0465 S locked, refcnt 6, size 10 D
MEM 4 0462 S refcnt 0, size 1484 D
MEM 5 0438 S locked, refcnt 1, size 538 D
* Dump of Handle Table for ProcessID 00000A84 (nserver)
HDL 1 0166 locked, refcnt 1, size 336 D
HDL 3 0146 G locked, refcnt 1, size 9222 D
HDL 4 0F5D locked, refcnt 1, size 116 D
HDL 5 0F5D locked, refcnt 1, size 116 D
HDL 6 0938 refcnt 0, size 34 D
MEM 1 0130 locked, refcnt 1, size 370 D
MEM 2 0128 locked, refcnt 1, size 10486 D
MEM 3 0171 locked, refcnt 1, size 316 D
MEM 4 044A locked, refcnt 1, size 18 D
MEM 5 0129 G locked, refcnt 1, size 524294 M
为了总结内存输出列表，我们必须处理这些数据。 内存输出列表(memory dump)，主要展示两部分数据，共享内存数据和运行时进程数据。在每个章节都有使用中的句柄的输出列表。我们能做的是得到每个进程和共享内存的MEMS （ 内存句柄 ）以及HDLs （句柄）总和。我们还可以从第9列的数据来了解到正在分配什么。如果在这样做之后，我们发现所得值超过如下所示的标准，服务器就可能正在经历总体的句柄问题。
1 ）总进程HDLs超过9000或内存超过125,000
2 ）总进程HDLs超过240,000或内存超过450,0000 3 ）共享和进程内存总计超过1.5GB
对于上面的例子中，我们有5 HDLs的共享内存和5个MEMs共334K内存在使用中。显然，内存使用是相当低的。由于我们的nserver数据仅仅是一个范例片段，也可能导致这些值很低。但是，如果怀疑存在某些内存泄漏，我们可以回到NSD十大部分，看看哪些句柄处理可能是罪魁祸首。
诊断和纠正措施：
硬件：
硬件问题相对简单。如果您的memtest返回错 误结果，最可能就是内存芯片有问题。
操作系统： 以下是你可能要问的各类型问题，以及需要采取的行动：
326
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
