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

　　本文讲述一个E-Mail服务器突然变慢后的观察、分析、解决过程。

　　一切本来都是那样的宁静，所有的网络服务都在默默地工作着。然而近一段时间来，经常有人打电话反映一个相同的问题:在接收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个，但现在系统还是有条不紊地进行着，运行良好。

　　六、体会

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

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

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