Domino服务器性能问题诊断与排除手册(1).doc

Domino服务器性能问题诊断与排除手册 介绍如果你已经确定在你的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 topCPU问题定位：通常情况下， 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 statuslocationdescriptionproc0Available 00-00 Processorproc2Available 00-02 Processorproc4Available 00-04 Processorproc6Available 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 IBMxSeries 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使用率会有一个急剧增长，这是正常的。一旦服务器启动完成负荷将减少。DominoDomino有自己的一套收集信息的工具。包括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 PM01A8:0006-08F8 Server name:SET_Test1/Support01A8:0006-08F8 Server directory:g:notesdata01A8:0006-08F8 Partition:g.notes.data01A8:0006-08F8 Elapsed time: 01:10:1701A8:0006-08F8 Transactions/minute:Last min ute: 6; Last hour: 4; Peak: 2301A8:0006-08F8 Peak # of sessions:2 at 04/10/2006 04:20:55 PM01A8:0006-08F8 Transactions: 35 Max. concurrent: 2001A8:0006-08F8 ThreadPool Threads:4001A8:0006-08F8 Availability Index:100 (state: AVAILABLE)01A8:0006-08F8 Mail Tracking:Not Enabled01A8:0006-08F8 Mail Journaling: Enabled, Local Destination01A8:0006-08F8 Shared mail:Not Enabled01A8:0006-08F8 Number of Mailboxes:101A8:0006-08F8 Pending mail: 0Dead mail: 0 01A8:0006-08F8 Waiting Tasks:001A8:0006-08F8 Transactional Logging:Not Enabled01A8:0006-08F8 Fault Recovery:Enabled01A8:0006-08F8 Activity Logging:Not Enabled01A8:0006-08F8 Server Controller: Not Enabled01A8:0006-08F8 Diagnostic Directory: g:notesdataIBM_TECHNICAL_SUPPORT01A8:0006-08F8 Console Logging: Enabled01A8:0006-08F8 Console Log File:g:notesdataIBM_TECHNICAL_SUPPORTconsole.log上 面输出显示： “Availability Index: 100 (state: AVAILABLE),” ，它代表了服务器可用性指数（SAI）。SAI是一个从0到100的数字，代表了Domino服务器的相对可用性。每个Domino服务器基于最近处理请 求的响应时间定期决定自己的工作量。工作量表示为一个从0到100的数字，其中0表示负载过重的服务器和100表明负载较轻的服务器。重要的是要认识 到，SAI不是一个百分比。在Domino6.x和更高版本中，SAI通过查看以下区别计算而得：空载系统中处理事务花费的时间和满载系统中处理事务花费 的时间。SAI可以调成取决于系统硬件能力。请记住，SAI是服务器的相对可用性。每个服务器基于负荷和服务能力可能有不同的SAIs。SAI变化则表明 性能变化。欲了解更多信息，请参阅文件，题为“Domino 6.x Server Availability Index (SAI) - Understanding How SAIIs Calculated”(#1164405)。你也可以通过在Domino notes.ini中设置“Server_Show_Performance = 1”使其提供有关性能信息，输出会显示Domino服务器每分钟处理事务的数量以及当前系统中活动用户的数量。这一信息，每隔60秒记入到服务器控制台， 可帮助跟踪在一段时间内系统的性能。它还会显示用户和事务最高峰使用次数。事务包括服务器上处理的所有事务（例如，路由，代理管理器，复制，病毒扫描器， 和使用者的动作）。01A8:0021-0254 04/10/2006 04:30:47 PM6Transactions/Minute, 0 Notes Users01A8:0021-0254 04/10/2006 04:31:47PM0 Transactions/Minute, 0 Notes Users01A8:0021-0254 04/10/200604:32:47 PM4 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-0000112/11/2003 08:09:01 Warning: Agent is performingfull textoperations 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- 该