一切本来都是那样的宁静，所有的网络服务都在默默地工作着。然而近一段时间来，时常有人打电话反映一个相似的疑问 :在接收E-Mail时，服务器端时常应答超时，从而无法 正常收到E-Mail，但假如过一会儿再收，则又可能正常接收到。大众对此表现出了很大的不满。因此，咱们就高速 动手寻找疑问的根源，以争取尽快修正这个故障。

一、查阅基本信息

最先咱们翻看了归档资料，确定了E-Mail运行在一个配置为PIII 500MHz，128M内存，20G硬盘的工控机上，操作系统是Redhat linux 6.5，运用 Sendmail做为E-Mail Server，并且采用系统的passwd文件做为Sendmail邮件用户的认证文件。

根据网管日志记载该邮件系统的用户在这一段时间以来成长十分高速 ，用户数从1万名添加到了超过2万名。

二、初步剖析

议决上面信息的明白，咱们基本上确认速度变慢的首要的原由是用户量的增长。因此，在这此前提下执行 了剖析。

咱们在linux控制台下，输入以下命令查看系统的进程情况:

ps –auxw

咱们发觉，该命令列出了大量的发送邮件和POP进程。然后根据网管日志的记载，分别在低峰、平均、高峰期间执行 了并发用户数的检验，发觉在高峰情，并发的用户数已从原来的20个用户上升到了40个用户。

到此为止，咱们得出了初步的结论:由于用户的不断增长，并发用户也越来越多，使得机器无法 处理完这些并发请求，以致E-Mail服务器对用户响应过慢，甚至超时而无法 运用。因此，咱们认为处理这一故障的要领 就是升级机器。

三、深入剖析

这时，咱们突然间又留心到了40这个数字，咱们觉得现在运用的E-Mail Server服务器的性能不应该无法 处理40个用户同时访问的呀。咱们隐隐感觉到前面的剖析必须有什么地点疏忽了，以至得到了一个并不正确的结果。       因此，咱们便查看了另外一台配置相似，正在运行WEB服务的服务器，咱们发觉，该服务器在同时处理50个用户访问时，并没有感到处理能力不足。

这时，咱们开始进一步剖析 E-Mail服务的整个流程。最先用户的邮件接收程序议决 POP协议与服务器的POP模块执行 通讯，并提供用户名与密码；接着E-Mail服务器的POP模块要将用户提供的密码执行 加密；然后与系统文件/etc/passwd中的用户密码执行 逐行匹配，并找出相应的用户名，再执行 第二次匹配；假如匹配成功，则校验议决，否则就返回用户名或密码不正确。校验议决后，服务器开始将属于该用户的邮件传送给用户的邮件接收程序。这时，咱们想到了，所有的用户连接都有一个共同的环节，那就是都要打开系统文件/etc/passwd，执行 用户的验证，会不会是因此带来瓶颈疑问呢?

那么，咱们就在linux控制台上输入以下命令，查看运用 /etc/passwd文件有多少个进程:

fuser /etc/passwd

这时，列出了许多 POP进程，症结总算找到了。原来是因为系统文件/etc/passwd是一个文本文件，在用户名、密码的匹配流程中，是采用逐行执行 匹配，而咱们的/etc/passwd文件有2万多行，因此最好的情况是第一次匹配就成功，最坏的情况就是2万多次后才匹配成功，因此平均须要 1万次的匹配。该流程所消耗的时间足以使得电子邮件接收程序超时，而无法 等到匹配结束。

四、处理要领

故障的根源找到了，处理要领也就自然基本。因为服务器POP模块议决搜索密码文件验证一个用户的身份所需的时间很长，使得进程产生了积累，从而事实上加重了系统的负担，即此时正在运用邮件接收程序的用户在长时间内仍保持连接状态，而无法 正常执行 下一步的工作。所以首要是处理要领就是将采用文件文件/etc/passwd的要领转成数据库形式。

因此能够采用以下两种要领之一处理 :

1)运用 linux的NIS系统，将系统的密码文件/etc/passwd转换成为NIS的信息库。由于NIS采用的是数据库引擎，所以运行起来，便于查找，效率能够大大提高。

2)重新配置Sendmail，使其不采用系统文件/etc/passwd来执行 用户校验，而是采用一个特定的数据库存储，由于也是采用了数据库引擎，所以运行起来，便于查询，效率也可以够大大提高。

你还能够采用Postfix等内建数据库支持的E-Mail系统来替换Sendmail，由于Postfix能够直接在Sendmail基本上实现数据的自动转换，因些整个操作十分基本。

五、处理成效

咱们结尾采用了Postfix替换Sendmail，将其用户密码列表转换成为数据库模式，疑问就迎刃而解。现在咱们仍然在运用这台机器，并且用户已经增长到3万个，高峰时期用户的并发数也已经从40个上升到60-70个，但现在系统仍旧有条不紊地执行 着，运行良好。

六、体会

在这个基本的例子中，咱们深深地体会到在日常的系统维护工作中必须仔细地剖析疑问，而不要轻易地将疑问归结于服务器硬件能力上。

首要的要领 是:认真地、实事求是地检验每个进程在做什么;认真地研究服务的整个流程，剖析疑问最可能发生的地点 ;然后设计相应的检测工作，收集情况，对其论证。只有这样才能够最后定位疑问，并在此基本上提出行之有效的处理方案，最后处理疑问。

同时也从另一个侧面告诉每一个网管人员，日常积极有效地记载下网络的一些变动情况，在故障出现的时刻，这些资料能够有效地为疑问剖析提供数据依据。