Domino服务器性能问题诊断与排除手册.docx
《Domino服务器性能问题诊断与排除手册.docx》由会员分享，可在线阅读，更多相关《Domino服务器性能问题诊断与排除手册.docx（18页珍藏版）》请在冰豆网上搜索。
Domino服务器性能问题诊断与排除手册
Domino服务器性能问题诊断与排除手册
如果你已经确定在你的Domino服务器上有性能问题，你现在应该做些什么呢？
性能问题的一个主要障碍是问题的实质总是难以捉摸的。
系统某个区域的问题的解决有可能取决于一个完全不相关的区域。
因此，在这种情况下，问题真的被解决了吗？
即使问题解决了，问题的实质依然很难确定。
所以，可能你仅仅是暂时减轻了症状而已。
由于计算机系统的复杂性，性能的改善或者恶化可能会以一种平稳的方式进行，也可能是突变式。
一个渐变式性能恶化的例子是：
当将一些用户添加至一台服务器时，服务器的总体性能逐渐降低。
再举一个突变式性能恶化的例子，修改一个应用程序使得它能够存储和读取更大的notes可能导致NSF缓存超过它的最佳使用率，进而使得磁盘IO访问大量增加，最后导致服务器性能恶化。
在渐变式的变化中，运行过程中的小变化只会对性能造成比较小的影响，而对于突变式，运行过程中一个小的变化经常会对性能产生巨大的影响。
如果有可能，你应该尽量每次只做一个修改，然后密切地监视系统性能的变化情况。
本文不是为了帮助你如何实现性能最优化，而是关注那些服务器性能受系统不利因素影响的问题，这和前者有很大的不同。
我们将一步步地对问题进行分析，包括：
问题是什么？
记录问题的实质，诊断问题并采取修正操作，最后确定我们采取的修正操作是不是有效的。
定位
首先考虑下面这些问题。
1） 问题的现象是什么？
问题看起来是什么样的？
问题存在的迹象是什么？
重点是定义正常的情况。
一个性能问题的存在使得服务器运行不正常。
为什么我们需要明确这些呢？
很多次，客户确信Domino服务器有问题，但又不确定正常的运行情况是什么样的。
比如说，解决一个磁盘性能时遇到的网络问题，但是我们怎么知道对于系统来说正常情况是什么样的呢？
是10MB/sec正常还是100MB/sec的速度是正常的？
在处理性能问题时，我们一定要明确地知道系统的正常状态。
如果我们通过深入调查能够使得性能变好为什么还要做这件事情呢？
那是因为必须找出影响系统的一组变量集，一旦我们找到了这些变量，并作出必要的改动，服务器的平衡和正常运行已经恢复。
一旦我们超越解决这些导致偏离正常状态的问题时，我们开始进入了一个不同的舞台上。
现在，对系统的作出的改变不是为了恢复之前的平衡，而是要改变系统到一个新的和可能更好的状态。
在这一点上，改动变得更加实验性，而不是修正。
虽然并不完全是一件坏事，这些改动可能会使得事情更加糟糕，这个问题的范围变得永无止境。
2）另外一个要问的主要问题是：
问题在来自“哪里？
”为了回答这个问题，把你的系统分成两个逻辑独立的区域：
资源和资源管理。
我们可以对这些区域再进行划分。
对于资源而言，按照CPU，IO和内存来划分。
IO又可以再细分为磁盘IO和网络IO。
而对于资源管理，划分为应用（比如Domino），操作系统和硬件。
为了更加直观，我们绘制了下面这张图：
你会惊讶于有多少人未能沿着这些方针来考虑问题。
因为那么多的计算区域会重叠，解决的的也并不一定是问题所在，大多数人将依赖直觉和经验。
尽管这样可能有效，经验需要长时间的积累，而且不可能教别人如何来根据直觉解决问题。
这样做是不可取的，尤其是对于相对比较新的性能故障排除问题，它有可能会导致误解和错误的诊断。
通过对资源和资源管理使用分层方法，我们能够使用每层的逻辑来定位问题来自哪里。
3）问题的重现率怎样？
这相当重要，因为没有某种程度的重复性，我们就没有办法确定问题是什么，如何做出修改。
又怎么记录或测试以确定问题是不是真是我们当初所认为的问题？
如果问题仅仅发生一次，我们不能区分是它是一个问题或者仅仅是个随机事件..如果我们不能收集关于问题的数据，那么我们没法做出决定。
因为性能问题的解决本身就绝不是一个具体的过程，问题的解决过程是一个相当反复的过程，这一点及其重要。
如果你能够对照上面的表格指出问题是什么固然是好，但更经常发生的情况是：
你在几种可能性之间来回反复，或者根据你的经验和专家意见猜测一种最可能的解决方案。
文档记录
文档记录是任何类型问题判定的关键因素，性能问题也不例外。
文档记录使得性能问题的诊断不再是一个随意的过程，而是一个科学分析的过程。
当然我们可以根据对问题的猜测来对系统做出修改，但如果你没有证据证明问题所在，基本上也只是猜测而已。
考虑到你可能在与一些不同的对象打交道而且试图向你的管理层提出一个行动的意见，问题是：
怎么能够让不同的人都理解你所说的。
这确实经常发生，并且有时别人理解的和你所想表达的相去甚远。
无论如何，为了支持你的观点，你不仅需要确定问题存在于哪个部分，还需要明确性能问题所带来的变化。
这样，即使你自己不能确定问题的根本原因，你也具备了跟别人讨论的基础，当然为了表明系统有所变化，你需要保存问题出现之前系统的统计数字。
保存这些数据的代价是很低的，但它却会极大地减少你解决问题的时间。
尽管没有问题时这样做好像不重要，但是当问题发生时，文档记录就会变得非常有价值。
下面的表格列出了一些在windows平台上有用的故障诊断工具：
NSD，信号量调试工具，Domino系统统计（shstat）在对性能问题进行故障诊断时特别重要。
信号量是用来对资源访问限制的一个变量。
例如，用信号量来保护一个文件免受并发访问。
信号量可能是个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统计（showstat）可以从统计的角度对当前状态提供深刻的理解。
尽管可以用statrep收集历史的统计信息，在Domino控制台键入“showstat”来获取问题发生时的数据往往更加有效。
诊断
在性能故障诊断的这一阶段，你可以开始把每个领域的专家们加入进来。
在这里，你的任务是解释观察到的结果是什么，并从这推断需要做些什么。
然而这并不像听起来的那么简单。
确定问题的根源不仅需要知识，还需要理解在文档记录阶段获取的数据结果。
举例来说，一个人收集的统计信息可能表明，内存利用率不是很好（如：
拥挤拒绝）。
一位在这方面的专家可能认为，问题无疑是缺乏可用内存。
而另一位专家可能会觉得水印无关紧要，不太可能是造成问题的原因。
这里的主要缺陷是，我们进行的修改影响的只是我们记录的，而不是问题本身。
这进一步坚定了需要明确具体关注的问题，当改动产生预期效果的时候你才可以真正地得出结论，它是基于问题的症状，而不是我们认为我们所看到。
在这一阶段的主要障碍是：
要对各个资源的各种资源管理的架构上的局限和操作有一个深刻的理解。
当然，这是一个相当广泛的专题。
这也就是为什么要组织各方面专家参与的原因。
对于每一块区域，我们需要问自己，“这个问题主要是吞吐量问题还是带宽问题？
”换句话说，是我们限制了能够使用的资源或是资源缺乏，是什么原因造成了这个问题。
带宽问题往往体现的是硬件问题，而吞吐量的问题往往是操作系统的或者应用程序的问题。
例如，在某些情况下，我们已经看到在使用内格尔算法（数据捆绑在一起，以减少数据包发送）会对性能产生负面影响，因为系统由于人为的拖延而等待。
在这种情况下，并不是说是缺乏足够的带宽，而是缺乏带宽利用率。
有一点需要牢记的是资源使用效率往往会导致人们认为耗尽资源而实际上它是一个吞吐量问题。
如果系统没有了可用的CPU，自然的反应是增加CPU，然而再仔细检查，发现该处理器产生异常多的上下文切换。
在这种情况下，造成性能问题的原因并不是没有足够的CPU，而是CPU使用的方式。
测试
最后，在变更之后，需要测试，看看它们是否起到了预期的效果。
我们的测试是相对容易的。
因为我们只需要根据已知的常态来确定现状是否已恢复正常。
我们也要监测统计数据，这些数据帮助我们发现并关注问题及其根源。
统计数据应该与我们所做的变更相匹配。
否则就证明这个问题是我们意料之外的非正常问题，必须重新启动程序。
为了更好地了解如何应用这里提出的这些原则，在本文后面的篇幅里，我们会探讨您可能会遇到的不同类型的问题。
我们将用一些例子来说明我们使用了什么样的工具，为什么选择使用它们。
最后，我们将分析为什么我们这样诊断以及解决了什么问题。
注意：
不要被理论束缚。
性能问题并不总是一个简单的一次方程。
甚至是为了初步确定问题所属的领域，都需要至少迭代每一个可能的解。
如果它是一个更深入的问题，您可能需要更深入的迭代。
这就是为什么集所有功能于一身的工具，如NSD，是如此宝贵。
Backtotop
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没有分配给这个逻辑分区。
SystemDevices:
===============
name status location description
proc0 Available00-00 Processor
proc2 Available00-02 Processor
proc4 Available00-04 Processor
proc6 Available00-06 Processor
而在一个windows平台产生的NSD文件中，这些信息是位于输出信息的顶部并列在OSVersion那行（OSVersion :
WindowsXP5.1（Build2600）,PlatID=2,ServicePack2（1Processor））。
这一信息是从操作系统传递过来的。
我们在Windows系统的系统属性窗口也能看到这部分信息。
处理器的速度和数量将决定Domino分区的数量，以及能够跑的用户数和任务。
欲了解更多有关筛分Domino服务器的信息，请参阅以下内容：
"DominoforIBM xSeriesandBladeCenterSizingandPerformanceTuning"and"Dominofor iSeries（AS/400）".
操作系统
有许多工具可以查看系统的CPU使用率。
对于Windows系统，可以使用Windows任务管理器。
以上数字表明，CPU的使用率为100％。
一种情况是，管理员中午启动了磁盘清理。
cleanmgr.exe线程使用了93％的CPU。
直到该线程释放CPU，响应用户时间才会有所减少。
仅仅CPU使用率达到100％并不说明什么问题。
查看什么线程或进程正在使用的大部分CPU才能发现根本原因。
在Domino的启动过程中，CPU使用率会有一个急剧增长，这是正常的。
一旦服务器启动完成负荷将减少。
Domino
Domino有自己的一套收集信息的工具。
包括Domino统计（showstat）或Domino服务器信息屏幕（showsever），例如：
[01A8:
0006-08F8]LotusDomino（r）Server（Release6.5.3forWindows/32）04/10/200604:
22:
55PM
[01A8:
0006-08F8]Servername:
SET_Test1/Support
[01A8:
0006-08F8]Serverdirectory:
g:
\notes\data
[01A8:
0006-08F8]Partition:
g.notes.data
[01A8:
0006-08F8]Elapsedtime:
01:
10:
17
[01A8:
0006-08F8]Transactions/minute:
Lastminute:
6;Lasthour:
4;Peak:
23
[01A8:
0006-08F8]Peak#ofsessions:
2at04/10/200604:
20:
55PM
[01A8:
0006-08F8]Transactions:
35 Max.concurrent:
20
[01A8:
0006-08F8]ThreadPoolThreads:
40
[01A8:
0006-08F8]AvailabilityIndex:
100（state:
AVAILABLE）
[01A8:
0006-08F8]MailTracking:
NotEnabled
[01A8:
0006-08F8]MailJournaling:
Enabled,LocalDestination
[01A8:
0006-08F8]Sharedmail:
NotEnabled
[01A8:
0006-08F8]NumberofMailboxes:
1
[01A8:
0006-08F8]Pendingmail:
0 Deadmail:
0
[01A8:
0006-08F8]WaitingTasks:
0
[01A8:
0006-08F8]TransactionalLogging:
NotEnabled
[01A8:
0006-08F8]FaultRecovery:
Enabled
[01A8:
0006-08F8]ActivityLogging:
NotEnabled
[01A8:
0006-08F8]ServerController:
NotEnabled
[01A8:
0006-08F8]DiagnosticDirectory:
g:
\notes\data\IBM_TECHNICAL_SUPPORT
[01A8:
0006-08F8]ConsoleLogging:
Enabled
[01A8:
0006-08F8]ConsoleLogFile:
g:
\notes\data\IBM_TECHNICAL_SUPPORT\console.log
上面输出显示：
“AvailabilityIndex:
100（state:
AVAILABLE）,”，它代表了服务器可用性指数（SAI）。
SAI是一个从0到100的数字，代表了Domino服务器的相对可用性。
每个Domino服务器基于最近处理请求的响应时间定期决定自己的工作量。
工作量表示为一个从0到100的数字，其中0表示负载过重的服务器和100表明负载较轻的服务器。
重要的是要认识到，SAI不是一个百分比。
在Domino6.x和更高版本中，SAI通过查看以下区别计算而得：
空载系统中处理事务花费的时间和满载系统中处理事务花费的时间。
SAI可以调成取决于系统硬件能力。
请记住，SAI是服务器的相对可用性。
每个服务器基于负荷和服务能力可能有不同的SAIs。
SAI变化则表明性能变化。
欲了解更多信息，请参阅文件，题为“Domino6.xServerAvailabilityIndex（SAI）--UnderstandingHowSAIIsCalculated”（#1164405）。
你也可以通过在Dominonotes.ini中设置“Server_Show_Performance=1”使其提供有关性能信息，输出会显示Domino服务器每分钟处理事务的数量以及当前系统中活动用户的数量。
这一信息，每隔60秒记入到服务器控制台，可帮助跟踪在一段时间内系统的性能。
它还会显示用户和事务最高峰使用次数。
事务包括服务器上处理的所有事务（例如，路由，代理管理器，复制，病毒扫描器，和使用者的动作）。
[01A8:
0021-0254]04/10/200604:
30:
47PM 6Transactions/Minute,0NotesUsers[01A8:
0021-0254]04/10/200604:
31:
47PM 0Transactions/Minute,0NotesUsers[01A8:
0021-0254]04/10/200604:
32:
47PM 4Transactions/Minute,0NotesUsers
诊断和修正操作
随着时间的推移，Domino服务器上的负载可能增加，这可能会影响Domino的整体性能。
附加的Domino任务（例如，POP3或HTTP）和附加应用程序（如，LEI或anti-virus）可能会改变用户的请求响应时间。
为了提高响应时间，也许有必要改变硬件水平。
这些变化可能包括增加CPU，提高CPU的配置，或平衡CPU负载。
操作系统：
性能故障诊断是一个反复的过程，因此，通过消除一个瓶颈你可能会发现另一个。
比方说，通过增加内存解决页面问题后，可能发现我们的系统现在有CPU的问题。
在Windows系统中，性能监视器（Perfmon）可用于监视每秒的页面数量。
当每秒页面数乘以AvgDiskSec每转再乘以100大于12％至16％时它被认为是过度的。
（100*（内存：
页/秒*物理磁盘：
AvDiskSec/转））。
下图所示的平均页/秒是129。
Domino：
在Domino中，用户能够在邮件数据库以及其他数据库中创建代理并安排代理执行的时间。
用户代理可能产生足够的负荷在服务器上引起性能问题。
代理管理器的默认设置可能不适合你的环境。
通过调整最大并发代理数和延迟前忙的最大百分比（服务器文件中），你可以控制代理对服务器性能的影响。
除了控制的最大并发代理数，你也可以限制谁可以在服务器上运行代理。
（默认情况下，每个人都可以运行简单公式代理）。
你可以通过在非高峰时段执行代理来减轻由代理引入的性能问题。
代理中的函数调用也可以影响Domino服务器性能。
用户可能会创建一个简单的代理来执行邮件文件中的搜索功能。
如果邮件文件没有全文索引，代理调用全文搜索时会导致服务器生成一个临时的全文索引。
这个全文索引将只使用一次，
升级会员 