Domino服务器性能问题诊断与排除手册

Abstract  Abstract No abstract provided.

Show Table of Contents Hide Table of Contents   0.0.1   介绍 如果你已经确定在你的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使用的方式。 测试 最后，在变更之后，需要测试，看看它们是否起到了预期的效果。我们的测试是相对容易的。因为我们只需要根据已知的常态来确定现状是否已恢复正常。我们也要监测统计数据，这些数据帮助我们发现并关注问题及其根源。统计数据应该与我们所做的变更相匹配。否则就证明这个问题是我们意料之外的非正常问题，必须重新启动程序。