在接收E-mail时，服务器端经常应答超时，从而无法正常收到E-mail，但如果过一会儿再收，则又可能正常接收到。大家对此表现出了很大的不满。因此，我们就迅速动手寻找问题的根源，以争取尽快修复。一、 查阅基本信息
首先我们翻看了归档资料，确定了E-mail运行在一个配置为PⅢ 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个，但现在系统还是有条不紊地运行着，状态良好。
