我的E-Mail伺服器为什么变慢了

　　那么，我们就在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个，但现在系统还是有条不紊地进行着，运行良好。

　　六、体会

　　在这个简单的例子中，我们深深地感受到在日常的系统管理工作中必须仔细地分析问题，而不要轻易地将问题归结于服务器硬件能力上。

织梦好，好织梦

　　主要的办法是:认真地、实事求是地检查每个进程在做什么;认真地研究服务的整个流程，分析问题最可能发生的地方;然后设计相应的检测工作，收集情况，对其论证。只有这样才能够最终定位问题，并在此基础上提出行之有效的解决方案，最终解决问题。

看完这篇，您有何感觉呢？