下载文档原格式
服务器典型故障排除操作手册目录1.服务器常见故障类型分类 (1)2.服务器常见故障现象及其对应的排除方法 (1)2.1服务器开机无显示（加电无显示和不加电无显示） (1)2.2加电BIoS自检报错 (1)2.3系统安装阶段故障和现象 (2)2.4操作系统启动失败 (2)2.5系统运行阶段故障 (2)3.服务器故障排错的基本原则 (3)3.1尽量恢复系统出厂配置 (3)3.2从基本到复杂 (3)3.3部件交换对比测试 (3)4.服务器故障排除需要收集哪些信息 (4)4.1服务器信息 (4)4.2故障信息 (4)5.服务器硬件故障处理实际案例 (4)6.服务器常见软故障解决思路与实例 (7)7.服务器常见内存故障现象实例 (9)1.服务器常见故障类型分类第1类开机无显示第2类加电BlOS自检阶段故障第3类系统和软件安装阶段故障和现象第4类操作系统启动失败第5类系统运行阶段故障2.服务器常见故障现象及其对应的排除方法2.1服务器开机无显示（加电无显示和不加电无显示）2.1.1检查供电环境2.1.2检查电源和故障指示灯（故障指示灯状态，目前很多厂商的服务器都有故障指示灯，或故障诊断卡等。
）2.1.3按下电源开关时，键盘指示灯是否亮、风扇是否全部转动2.1.4是否更换过显示器，尝试更换另外一台显示器2.1.5插拔内存,用橡皮擦擦拭一下金手指，如果在故障之前有增加内存，去掉增加的内存尝试2.1.6 1.6是否添加了CPU,如果有增加CPU尝试去掉2.1.7 1.7去掉增加的第三方I/O卡包括Raid卡等2.1.8ClearCMOS（记得使用跳线来清除，尽量不要直接拔电池，每款服务器清除跳线位置不一致，具体找不到电话联系一下厂商客服）2.1.9尝试更换主板、内存等主要部件2.1.101.10清除静电，将电源线等外插在服务器上的线缆全部拔掉，然后轻按开机键几下2.2加电BK）S自检报错2.2.1 2.1根据BIOS自检报错信息提示2.2.2查看是否外插了第三方的卡或者添加部件，如果有还原基本配置重2.2.3做最小化测试2.2.4尝试清除CMOS3.2.5看能否正常进入BloS2.3系统安装阶段故障和现象2.3.1查看服务器支持操作系统的兼容版本（从厂商能查到兼容性列表）3.3.2系统安装蓝屏（对蓝屏故障代码诊断）4.3.3安装在分区格式化的时候找不到硬盘（阵列驱动没有安装或者没有配置阵列，可以尝试适应引导光盘安装）2. 3.4大于2T的硬盘式应该如何分区（必须使用阵列卡才能实现或者有外插识别卡）（使用阵列卡配置阵列分成一个小于2T的空间，一个大于2T的空间，然后将系统安装在小于2T的上面，安装好系统后在使用GPT方式分区即可）2.3.5安装过程是死机（检查兼容性列表——查看硬盘接口选择是否正确-一阵列驱动安装是否正确-一尝试最小化配置安装检查是否为内存和CPU等问题）2.3.6引导光盘安装失败（使用引导光盘安装失败，查看引导光盘版本是否匹配，尝试手动安装系统，如有阵列重新配置阵列引导安装）2.4操作系统启动失败2.4.1在系统启动自检过程中有报错（具体查看启动报错信息在定方案）3.4.2启动系统蓝屏（查看蓝屏代码核对）4. 4.3进入登陆界面死机（查看进入单用户或者安全模式是否正常，进入BIOS是否正常、是否会死机，进入磁盘阵列查看阵列状态是否正常，检查测试硬盘是否有坏道，最小化配置启动）5.4.4忘记密码（windows使用PE破解，IinUX进入单用户破解）2.5系统运行阶段故障2.5.1安装数据库等应用软件报错（对系统版本和软件版本是否兼容，查看报错信息是否缺少插件）2.5.2系统运行速度变慢（查杀病毒,检测阵列状态,测试硬盘有无坏道，重新安装系统或者修复）2.5.3运行蓝屏（查看蓝屏代码目录）2.5.4运行死机（检查进入BIOS是否死机，进入系统后测试部件温度是否正常，windows系统查看dump文件）3. 5.5硬盘拷贝数据文件速度变慢（测试硬盘是否有坏道，如果有阵列检查阵列状态，检查改变条带大小，与软件应用要求测试对比）3.服务器故障排错的基本原则3.1尽量恢复系统出厂配置3.1.1硬件配置：去除第三方厂商备件和非标配备件3.1.2资源配置：清除CMOS、恢复资源初始配置4. 1.3BIOS>F∕W>驱动程序：升级最新的BIOS、F/W和相关驱动程序5. 1.4TPL：扩展的第三方的I/O卡是否属于该机型的硬件兼容列表（TPL）1.2从基本到复杂1.2.1系统上从个体到网络：首先将存在故障的服务器独立运行，待测试正常后再接入网络运行，观察故隙现象变化并处理。
故障名称及解决办法一、墨水压力异常：处理办法①墨水泵失灵，泵转速不正常致使检测的压力异常或高或低。
应检查墨路是否有堵塞或泄露。
②压力传感器失灵，实际压力正常但压力传感器回馈信号异常在CPU控制下泵速时高时低从而造成压力波动异常。
③墨路有泄露泵抽的有部分空气检测压力无。
应检查墨水系统泄露点。
二、真空压力异常：处理办法①墨线泵堵塞或管路有泄露，清洗墨线泵并检查墨线泵中心的小眼是否堵塞，清洗干净。
注意在拆和装时注意“0”形圈丢失或变形。
检查管路泄露点，排除后清洗干净。
②压力传感器损坏，检测到的压力数值不准确，更换新的压力传感器。
三机箱过热：处理办法①清洁空气过滤网及机箱内灰尘，同时关机，等机箱温度降低后再开机。
②风扇不转，检查风扇是否损坏，检查风扇电源插头是否松动接触不良或无电压。
四充电墨点检测故障：处理办法①充电槽上有墨水或与地短路，拆下充电槽彻底清洗充电槽，检查充电槽线路是否有断路或与地线连上。
②墨点没有形成，检查在充电槽中间是否有4个左右的完整墨点，太多或太少的话可进行调整，进“维护”菜单中的“打印头”调整“墨点调制电压”直到充电槽中有4个左右的完整墨点或打印效果正常为止。
③墨水使用时间太长或以过期，因墨水中含有太多的杂质使墨点充电不好。
进行排墨，整机清洗管路后加入新墨水，调整“墨点调制电压”直到打印正常为止。
五泵速过高：处理办法①过滤器堵塞，墨水无法从过滤器进入到墨路分配总承，更换过滤器或清洗过滤器。
②管路有堵塞或泄露，检查从泵到主过滤器之间的管路有无泄露或堵塞或管被折成死弯，100Psi弹簧螺丝是否太松。
检查全部墨水管路与接头是否有泄露的地方，排除后清洗干净。
③泵头齿轮老化，齿轮咬合缝隙太大。
更换新泵。
④在旧机器使用时，把墨水压力设置的太高或错把溶剂加到墨水箱中。
六泵速过低：处理办法①墨线泵堵塞，拆下墨线泵清洗。
②回墨管路有堵塞现象，检查管路并排除。
③墨水粘度太高，向墨箱中加入适当的溶剂。
七墨水压力过高：处理办法①墨线泵堵塞，拆下墨线泵清洗。
FOA维护培训（Domino基础部分）浙江省财政厅二零一一年十一月Domino 培训提纲目录Domino 培训提纲 (1)一、domino基础 (3)1、lotus组成 (3)2、domino相关文件、概念 (3)3、Domino Directory (5)3.1服务器文档 (6)3.2配置文档 (7)3.3个人文档 (8)3.4群组文档 (9)4、服务器命令 (10)4.1 Show命令 (11)4.2Tell 命令 (11)4.3开始和停止服务 (12)4.4、复制命令 (12)5、常用维护活动 (13)5.1注册用户 (13)5.2 重新认证用户 (14)5.3删除用户 (14)5.4设置邮件限额 (14)6、常用管理维护 (14)6.1 Fixup (15)6.2 Compact (15)6.3 Updall (16)6.4脱机维护 (17)6.5数据库恢复 (18)6.6 NSD文件使用 (18)6.7 convert (19)6.8 数据库签名 (20)6.9、创建/更新索引 (20)二、domino开发基础 (20)1、文档数据库介绍 (20)2、domino设计元素简介 (22)3、与日常维护有关的开发 (23)3.1工作流 (23)3.2作者、读者 (23)3.3安全控制 (23)3.4修改文档数据 (23)3.5调整当前办理人员 (23)3.6清理公文 (26)3.7清理邮件 (26)3.8解决邮件问题 (26)3.9数据目录扩充 (26)3.10服务器宕机后启动异常 (26)三、domino维护巡检 (28)一、domino基础1、lotus组成Lotus notes/Inotes(1)客户端-服务器应用程序。
(2)基于 Web、功能齐全的 Lotus Notes 客户端版本。
它可提供交互式界面，其中包括与 Web 浏览器内的 Lotus Notes 完全相同的功能Lotus Administrator是一款客户端-服务器应用程序，可提供图形界面，其主要目的在于管理和控制服务器，进入服务器的控制台，及执行各种基本任务.Lotus Domino Server是一款服务器产品，可提供企业级电子邮件、协作功能和自定义应用程序平台设置客户端连接服务器打开数据库访问服务器2、domino相关文件、概念（1）Names.nsf。
在Lotus Domino 服务器上如何设置DIIOP 相关参数以获取更佳性能产品：Lotus Domino平台：AIX, i5/OS, Linux, OS/400, Solaris, Windows, z/OS软件版本：7.0, 6.5, 6.0问题描述:您在Lotus® Domino® 服务器上启用了Domino IIOP (或称DIIOP，Internet Inter-ORB Protocol)。
为了最大限度提高系统性能，可以调整哪些选项呢?解答:提到DIIOP 性能优化, 对性能影响最大的配置参数是IIOP_IdleMinsAllowed 值。
为了提供更多信息的目的，本文也介绍了其他相关设置选项。
NAMES.NSF 设置IIOP_IdleMinsAllowed: (在Domino R5 的配置)这个参数是通过修改服务器配置文档中DIIOP 选项卡下“空闲会话超时”的值来控制的。
"IIOP_IdleMinsAllowed": 输入分钟数，在此时间内即使没有任何网络活动，会话仍保持为活动状态。
缺省值是60 分钟，0 代表会话不会由于闲置而被关闭。
**注意:** 设置这个选项是为了与R5 版本的服务器文档模板兼容。
这个选项在Lotus Domino R6 服务器中是不起作用的。
在R6 中，DIIOP 根据需要创建线程，所以不需要配置这个选项。
IIOP_IdleMinsAllowed输入分钟数，在此时间内即使没有任何网络活动，会话仍保持为活动状态。
缺省值是60 分钟，0 代表会话不会由于闲置而被关闭。
IIOP_IORHost输入运行DIIOP 任务的主机名或IP 地址。
网络参数信息编码后写入diiop_ior.txt 中，用于与服务器上DIIOP 任务建立连接.IIOP_HtmlDir输入外部HTML 目录路径。
注意默认路径是相对Notes 的数据目录而言的，除非您填写完整路径。
Domino服务器优化Domino服务器优化文档范本一、背景介绍在企业中使用Domino服务器时，优化服务器的性能可以提高系统的稳定性和效率。
本文档提供了关于Domino服务器优化的详细指南，以帮助管理员更好地管理和优化服务器。
二、硬件优化1.服务器硬件配置评估1.1 CPU和内存要求1.2 存储需求评估1.3 网络带宽需求评估2.磁盘优化2.1 确保磁盘驱动器速度符合要求2.2 分离数据库和日志文件到不同的磁盘驱动器2.3 定期进行磁盘碎片整理三、Domino服务器配置优化1.Domino服务器设置1.1 确保最新版本的Domino服务器安装1.2 优化Domino服务器配置文件1.3 启用重要性能参数2.任务和调度优化2.1 考虑将CPU密集型任务移至独立服务器 2.2 定期检查和调整任务计划2.3 配置邮件传输设置以提高性能3.Domino服务器安全性优化3.1 配置安全凭证3.2 启用SSL/TLS加密通信3.3 配置访问控制清单（ACL）四、数据库和索引优化1.数据库设计和结构优化1.1 确保适当的文档结构1.2 删除不必要的视图和文档1.3 定期进行数据库维护2.索引优化2.1 创建适当的视图和查询索引2.2 定期重建和压缩索引2.3 避免过多的视图索引五、性能监控和故障排除1.性能监控工具1.1 Domino服务器控制台1.2 Domino维度报告1.3 第三方性能监控工具2.故障排除2.1 使用Domino服务器日志进行故障排除 2.2 分析服务器负载和性能指标2.3 联系IBM支持获取帮助六、文档更新和版本记录添加更新的内容和日期附件：- Domino服务器配置文件样本- 磁盘碎片整理工具法律名词及注释：1.CPU：中央处理器，计算机的主要组成部分之一，负责执行计算机程序的指令。
2.ACL：访问控制清单，用于控制用户对数据库的访问权限的设置。
3.SSL/TLS：安全套接层/传输层安全协议，用于加密网络通信，确保数据的机密性和完整性。
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）构成。
