Domino服务器性能问题诊断与排除手册(共11页).doc
《Domino服务器性能问题诊断与排除手册(共11页).doc》由会员分享,可在线阅读,更多相关《Domino服务器性能问题诊断与排除手册(共11页).doc(11页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、精选优质文档-倾情为你奉上Domino服务器性能问题诊断与排除手册 介绍如果你已经确定在你的Domino服务器上有性能问题,你现在应该做些什么呢?性能问题的一个主要障碍是问题的实质总是难以捉摸的。系统某个区域的问题的解决有可能取决于一个完全不相关的区域。因此,在这种情况下,问题真的被解决了 吗?即使问题解决了,问题的实质依然很难确定。所以,可能你仅仅是暂时减轻了症状而已。由于计算机系统的复杂性,性能的改善或者恶化可能会以一种平稳的方 式进行,也可能是突变式。一个渐变式性能恶化的例子是:当将一些用户添加至一台服务器时,服务器的总体性能逐渐降低。再举一个突变式性能恶化的例子,修改 一个应用程序使得
2、它能够存储和读取更大的notes可能导致NSF缓存超过它的最佳使用率,进而使得磁盘IO访问大量增加,最后导致服务器性能恶化。在渐 变式的变化中,运行过程中的小变化只会对性能造成比较小的影响,而对于突变式,运行过程中一个小的变化经常会对性能产生巨大的影响。如果有可能,你应该尽 量每次只做一个修改,然后密切地监视系统性能的变化情况。本文不是为了帮助你如何实现性能最优化,而是关注那些服务器性能受系统不利因素影响的问题,这和前者有很大的不同。我们将一步步地对问题进行分析,包括:问题是什么?记录问题的实质,诊断问题并采取修正操作,最后确定我们采取的修正操作是不是有效的。定位首先考虑下面这些问题。1) 问
3、题的现象是什么?问题看起来是什么样的?问题存在的迹象是什么?重点是定义正常的情况。一个性能问题的存在使得服务器运行不正常。为什么我们需要明确这 些呢?很多次,客户确信Domino服务器有问题,但又不确定正常的运行情况是什么样的。比如说,解决一个磁盘性能时遇到的网络问题,但是我们怎么知道对 于系统来说正常情况是什么样的呢?是10MB/sec正常还是100MB/sec的速度是正常的?在处理性能问题时,我们一定要明确地知 道系统的正常状态。如果我们通过深入调查能够使得性能变好为什么还要做这件事情呢?那是因为必须找出影响系统的一组变量集,一旦我们找到了这些变量,并作 出必要的改动,服务器的平衡和正常运
4、行已经恢复。一旦我们超越解决这些导致偏离正常状态的问题时,我们开始进入了一个不同的舞台上。现在,对系统的作出的 改变不是为了恢复之前的平衡,而是要改变系统到一个新的和可能更好的状态。在这一点上,改动变得更加实验性,而不是修正。虽然并不完全是一件坏事,这些改 动可能会使得事情更加糟糕,这个问题的范围变得永无止境。2) 另外一个要问的主要问题是:问题在来自“哪里?”为了回答这个问题,把你的系统分成两个逻辑独立的区域:资源和资源管理。我们可以对这些区域再进行划分。 对于资源而言,按照CPU,IO和内存来划分。IO又可以再细分为磁盘 IO 和网络IO。而对于资源管理,划分为应用(比如Domino),操
5、作系统和硬件。为了更加直观,我们绘制了下面这张图:你 会惊讶于有多少人未能沿着这些方针来考虑问题。因为那么多的计算区域会重叠,解决的的也并不一定是问题所在,大多数人将依赖直觉和经验。尽管这样可能有 效,经验需要长时间的积累,而且不可能教别人如何来根据直觉解决问题。这样做是不 可取的,尤其是对于相对比较新的性能故障排除问题,它有可能会导致误解和错误的诊断。通过对资源和资源管理使用分层方法,我们能够使用每层的逻辑来定位问 题来自哪里。3)问题的重现率怎样?这相当重要,因为没有某种程度的重复性,我们就没有办法确定问题是什么,如何做出修改。又怎么记录或 测试以确定问题是不是真是我们当初所认为的问题?如
6、果问题仅仅发生一次,我们不能区分是它是一个问题或者仅仅是个随机事件.如果我们不能收集关于问题的 数据,那么我们没法做出决定。因为性能问题的解决本身就绝不是一个具体的过程,问题的解决过程是一个相当反复的过程,这一点及其重要。如果你能够对照上面 的表格指出问题是什么固然是好,但更经常发生的情况是:你在几种可能性之间来回反复,或者根据你的经验和专家意见猜测一种最可能的解决方案。文档记录文 档记录是任何类型问题判定的关键因素,性能问题也不例外。文档记录使得性能问题的诊断不再是一个随意的过程,而是一个科学分析的过程。当然我们可以根据对 问题的猜测来对系统做出修改,但如果你没有证据证明问题所在,基本上也只
7、是猜测而已。考虑到你可能在与一些不同的对象打交道而且试图向你的管理层提出一个 行动的意见,问题是:怎么能够让不同的人都理解你所说的。这确实经常发生,并且有时别人理解的和你所想表达的相去甚远。无论如何,为了支持你的观点,你不 仅需要确定问题存在于哪个部分,还需要明确性能问题所带来的变化。这样,即使你自己不能确定问题的根本原因,你也具备了跟别人讨论的基础,当然为了表明系 统有所变化,你需要保存问题出现之前系统的统计数字。保存这些数据的代价是很低的,但它却会极大地减少你解决问题的时间。尽管没有问题时这样做好像不重 要,但是当问题发生时,文档记录就会变得非常有价值。下面的表格列出了一些在windows
8、平台上有用的故障诊断工具:NSD, 信号量调试工具, Domino 系统统计(sh stat)在对性能问题进行故障诊断时特别重要。信 号量是用来对资源访问限制的一个变量。例如,用信号量来保护一个文件免受并发访问。信号量可能是个bit值,其中 1 代表这个文件正在被使用而0代表这个文件没有被使用。这样如果另外一个过程想使用此文件,在获得这个文件访问权之前,进程先检查信号量,如果没有进程在使 用这个文件 (0),则将信号量置为1。由于 Domino系统使用非常多的共享资源,并且多个进程争抢这些共享资源,你可以使用Dimino的debug工具(在notes.ini中设置 debug_capture_
9、timeout =1),用它可以查看那些占用太长时间处理的信号量请求。这个信息非常有价值,因为当Domino服务器响应很慢时,通常是由于它处在等待中,而利用这个 debug工具能够发现什么使得Domino服务器处于等待状态。NSD工具被认为是分析Domino性能相关问题的利器,NSD 给出服务器状态的所有当前信息(所有线程的调用堆栈、内存信息,配置等等),NSD的两个核心是堆栈信息和内存检查,堆栈信息是平台无关的,不论在什么平 台上,NSD都会记录所有Domino进程中每个线程的函数调用路径。 通过查看堆栈信息中最上面的函数,我们知道线程的最近的活动信息。在下面的例子中,nserver进程68
10、个线程中的第53个线程正在休眠,基本上,它没 在做什么事情。而nsched进程3个线程中的第1个线程正在试图锁住内存。如果我们想知道它 是否成功,可以生成另外一个NSD文件来查看这个线 程是不是成功地运行过去。NSD工具的内存检查能够记录当前Domino服务器内存使用情况,包括系统内存、句柄、网络使用信息、使用中的数据库结构以及文件使用信息。由于不是本文涉及范围,故不在此赘述。但是,我想说的是,内存检查对各种性能问题依然是非常方便的工具。Domino统计(show stat)可以从统计的角度对当前状态提供深刻的理解。尽管可以用statrep收集历史的统计信息,在Domino控制台键入“show
11、 stat”来获取问题发生时的数据往往更加有效。诊断在 性能故障诊断的这一阶段,你可以开始把每个领域的专家们加入进来。在这里,你的任务是解释观察到的结果是什么,并从这推断需要做些什么。然而这并不像听起 来的那么简单。确定问题的根源不仅需要知识,还需要理解在文档记录阶段获取的数据结果。举例来说,一个人收集的统计信息可能表明,内存利用率不是很好 (如:拥挤拒绝)。一位在这方面的专家可能认为,问题无疑是缺乏可用内存。而另一位专家可能会觉得水印无关紧要,不太可能是造成问题的原因。这里的主要缺 陷是,我们进行的修改影响的只是我们记录的,而不是问题本身。这进一步坚定了需要明确具体关注的问题,当改动产生预期
12、效果的时候你才可以真正地得出结论, 它是基于问题的症状,而不是我们认为我们所看到。在这一阶段的主要障碍是: 要对各个资源的各种资源管理的架构上的局限和操作有一个深刻的理解。当然,这是一个相当广泛的专题。这也就是为什么要组织各方面专家参与的原因。对 于每一块区域,我们需要问自己, “这个问题主要是吞吐量问题还是带宽问题?”换句话说,是我们限制了能够使用的资源或是资源缺乏,是什么原因造成了这个问题。带宽问题往往体现的是硬件问 题,而吞吐量的问题往往是操作系统的或者应用程序的问题。例如,在某些情况下,我们已经看到在使用内格尔算法(数据捆绑在一起,以减少数据包发送)会对性 能产生负面影响,因为系统由于
13、人为的拖延而等待。在这种情况下,并不是说是缺乏足够的带宽,而是缺乏带宽利用率。有一点需要牢记的是资源使用效率往往会导 致人们认为耗尽资源而实际上它是一个吞吐量问题。如果系统没有了可用的CPU,自然的反应是增加CPU,然而再仔细检查,发现该处理器产生异常多的上下文 切换。在这种情况下,造成性能问题的原因并不是没有足够的CPU ,而是CPU使用的方式。测试最后,在变更之后,需要 测试,看看它们是否起到了预期的效果。我们的测试是相对容易的。因为我们只需要根据已知的常态来确定现状是否已恢复正常。我们也要监测统计数据,这些数据 帮助我们发现并关注问题及其根源。统计数据应该与我们所做的变更相匹配。否则就证
14、明这个问题是我们意料之外的非正常问题,必须重新启动程序。为了更好地了解如何应用这里提出的这些原则,在本文后面的篇幅里,我们会探讨您可能会遇到的不同类型的问题。我们将用一些例子来说明我们使用了什么样的工具,为什么选择使用它们。最后,我们将分析为什么我们这样诊断以及解决了什么问题。注意:不要被理论束缚。性能问题并不总是一个简单的一次方程。甚至是为了初步确定问题所属的领域,都需要至少迭代每一个可 能的解。如果它是一个更深入的问题,您可能需要更深入的迭代。这就是为什么集所有功能于一身的工 具,如NSD,是如此宝贵。Back to topCPU问题定位:通常情况下, CPU的问题分为两类: 1)高CPU
15、负载(即CPU的运行达到或接近100),或2)CPU负载非常低,即使整体Domino的性能缓慢低下。您可以在硬件级,操作系统级或者应用程序级(Domino)管理CPU。硬 件:硬件级是CPU管理三个级别中最基础的一级。BIOS将支持某一特定数量的CPU,并报告操作系统所安装CPU的数量。如果在700Mhz的单CPU 上运行三个分区的Domino服务器,就会遇到性能问题。在这种环境下,该系统无法满足三个服务器对CPU的最低需求。很可能第一次运行时,服务器的性能 没有影响。但是随着时间的推移,服务器负载就会改变,从而影响系统性能。附加层通常由大系统如AIX,i系列(AS/400的)或Z系列 (OS
16、/390)构成。这些系统可以让系统管理员配置物理系统的逻辑分区(LPARs)。每个逻辑分区可以被分配到完整的CPU,部份的CPU,或多个 CPU。管理员要知道每个逻辑分区的资源分配,这一点很重要。例如,如果一半CPU用于单一逻辑分区上三个分区服务器的运行,那么CPU很容易就达到 100,这将导致性能低于服务器性能标准。操作系统操 作系统级将确定硬件如何执行以及用在通常开销的CPU总数。除了操作系统及其相关附加任务所产生的CPU负载,也必须考虑服务器上运行的其他应用程序产生 的负载。例如,如果 Domino系统在一个域的主控制器上运行,此控制器同时也是 DNS 和 DHCP 服务器,那么相对于D
17、omino运行在一个专用系统上来说,会消耗更多内存。当某一应用程序请求一页内存,操作系统将实际内存交换到虚拟 内存来响应此请求。这种情况下,Domino的性能也会受到影响。这一过程,被称为内存分页,是大多数系统的正常过程。随着内存分页增加,磁盘IO也会增 加从而减慢了操作系统响应时间。如今物理磁盘的吞吐量和存取速度有了很显著的提高;但磁盘读取仍然慢于内存读取。随着内存分页的增长,操作系统会出现震 荡,一旦该系统达到震荡的状态,它将花费更多的时间来交换内存,而不是处理CPU请求。因此,这一系统已无法在合理的时间内作出反应。在操作系统级别,可以为特定的程序或线程设定优先级。尽管Domino被设计成
18、以最优线程优先级安装,但也有可能某一线程的优先级需要加以调整,以提供更好的用户体验。Domino 服务器的任务、功能、或者用户数的增加会使Domino服务器的系统负荷加重。随着用户使用Domino的增加,他们可能会扩大其使用的范围和负载。有时 一个线程可能会占用大量的CPU,但在其他时间,一个线程可能会在锁定状态,导致其他线程等待待释放锁。Domino服务器能够控制系统的负荷,通过使用 一个notes.ini设置,这个设置能够限制在一个给定的分配并发线程的数量。这样当达到最大并发线程数时,线程将进入等待状态。即使是编写一个代理的 方式也可以影响Domino服务器的总体性能。如果在一个代理里对一
19、个没有建立索引的数据库执行全文搜索,Domino会创建一个临时的全文索引。使用之 后,这个索引即被删除。但是下次再次执行代理时,无论数据库有没有变化,都会再创建一个临时全文索引。这增加了额外的开销并降低了代理执行的效率和服务器 的性能。总之,系统管理员可以通过配置Domino服务器来服 务预期的负载。系统管理员配置服务器的方式会决定变化对总体用户的影响。数据收集:这 个部分将描述与 CPU 有关系的潜在的瓶颈。应该收集的数据将取决于我们怀疑的问题。有些数据来源于系统的环境参数,这需要跟硬件管理员讨论来得到。有些数据则来源于操作系统级 别的工具,有些则来自于Domino服务器。记住:一些系统可以
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Domino 服务器 性能 问题 诊断 排除 手册 11
限制150内