一切本來都是那樣的寧靜，所有的網(wǎng)絡服務都在默默地工作著。然而近一段時間來，經(jīng)常有人打電話反映一個相同的問題:在接收E-Mail時，服務器端經(jīng)常應答超時，從而無法正常收到E-Mail，但如果過一會兒再收，則又可能正常接收到。大家對此表現(xiàn)出了很大的不滿。因此，我們就迅速動手尋找問題的根源，以爭取盡快修復這個故障。

一、查閱基本信息

首先我們翻看了歸檔資料，確定了E-Mail運行在一個配置為PIII 500MHz，128M內(nèi)存，20G硬盤的工控機上，操作系統(tǒng)是Redhat linux 6.5，使用Sendmail做為E-Mail Server，并且采用系統(tǒng)的passwd文件做為Sendmail郵件用戶的認證文件。

根據(jù)網(wǎng)管日志記載該郵件系統(tǒng)的用戶在這一段時間以來發(fā)展十分迅速，用戶數(shù)從1萬名增加到了超過2萬名。

二、初步分析

通過上面信息的了解，我們基本上確認速度變慢的主要的原因是用戶量的增長。因此，在這此前提下進行了分析。

我們在linux控制臺下，輸入以下命令查看系統(tǒng)的進程情況:

ps –auxw

我們發(fā)現(xiàn)，該命令列出了大量的發(fā)送郵件和POP進程。然后根據(jù)網(wǎng)管日志的記錄，分別在低峰、平均、高峰期間進行了并發(fā)用戶數(shù)的檢查，發(fā)現(xiàn)在高峰情，并發(fā)的用戶數(shù)已從原來的20個用戶上升到了40個用戶。

到此為止，我們得出了初步的結論:由于用戶的不斷增長，并發(fā)用戶也越來越多，使得機器無法處理完這些并發(fā)請求，以致E-Mail服務器對用戶響應過慢，甚至超時而無法使用。因此，我們認為解決這一故障的辦法就是升級機器。

三、深入分析

這時，我們突然間又注意到了40這個數(shù)字，我們覺得現(xiàn)在使用的E-Mail Server服務器的性能不應該無法處理40個用戶同時訪問的呀。我們隱隱感覺到前面的分析一定有什么地方疏忽了，以至得到了一個并不正確的結果。

因此，我們便查看了另外一臺配置相同，正在運行WEB服務的服務器，我們發(fā)現(xiàn)，該服務器在同時處理50個用戶訪問時，并沒有感到處理能力不足。

這時，我們開始進一步分析E-Mail服務的整個過程。首先用戶的郵件接收程序通過POP協(xié)議與服務器的POP模塊進行通訊，并提供用戶名與密碼；接著E-Mail服務器的POP模塊要將用戶提供的密碼進行加密；然后與系統(tǒng)文件/etc/passwd中的用戶密碼進行逐行匹配，并找出相應的用戶名，再進行第二次匹配；如果匹配成功，則校驗通過，否則就返回用戶名或密碼不正確。校驗通過后，服務器開始將屬于該用戶的郵件傳送給用戶的郵件接收程序。這時，我們想到了，所有的用戶連接都有一個共同的環(huán)節(jié)，那就是都要打開系統(tǒng)文件/etc/passwd，進行用戶的驗證，會不會是因此帶來瓶頸問題呢?

那么，我們就在linux控制臺上輸入以下命令，查看使用/etc/passwd文件有多少個進程:

fuser /etc/passwd

這時，列出了很多POP進程，癥結總算找到了。原來是因為系統(tǒng)文件/etc/passwd是一個文本文件，在用戶名、密碼的匹配過程中，是采用逐行進行匹配，而我們的/etc/passwd文件有2萬多行，因此最好的情況是第一次匹配就成功，最壞的情況就是2萬多次后才匹配成功，因此平均需要1萬次的匹配。該過程所消耗的時間足以使得電子郵件接收程序超時，而無法等到匹配結束。

四、解決方法

故障的根源找到了，解決方法也就自然簡單。因為服務器POP模塊通過搜索密碼文件驗證一個用戶的身份所需的時間很長，使得進程產(chǎn)生了積累，從而事實上加重了系統(tǒng)的負擔，即此時正在使用郵件接收程序的用戶在長時間內(nèi)仍保持連接狀態(tài)，而無法正常進行下一步的工作。所以主要是解決方法就是將采用文件文件/etc/passwd的方法轉(zhuǎn)成數(shù)據(jù)庫形式。

因此可以采用以下兩種方法之一解決:

1)使用linux的NIS系統(tǒng)，將系統(tǒng)的密碼文件/etc/passwd轉(zhuǎn)換成為NIS的信息庫。由于NIS采用的是數(shù)據(jù)庫引擎，所以運行起來，便于查找，效率可以大大提高。

2)重新配置Sendmail，使其不采用系統(tǒng)文件/etc/passwd來進行用戶校驗，而是采用一個特定的數(shù)據(jù)庫存儲，由于也是采用了數(shù)據(jù)庫引擎，所以運行起來，便于查詢，效率也可以大大提高。

你還可以采用Postfix等內(nèi)建數(shù)據(jù)庫支持的E-Mail系統(tǒng)來替換Sendmail，由于Postfix可以直接在Sendmail基礎上實現(xiàn)數(shù)據(jù)的自動轉(zhuǎn)換，因些整個操作十分簡單。

五、解決效果

我們最后采用了Postfix替換Sendmail，將其用戶密碼列表轉(zhuǎn)換成為數(shù)據(jù)庫模式，問題就迎刃而解。現(xiàn)在我們?nèi)匀辉谑褂眠@臺機器，而且用戶已經(jīng)增長到3萬個，高峰時期用戶的并發(fā)數(shù)也已經(jīng)從40個上升到60-70個，但現(xiàn)在系統(tǒng)還是有條不紊地進行著，運行良好。

六、體會

在這個簡單的例子中，我們深深地感受到在日常的系統(tǒng)管理工作中必須仔細地分析問題，而不要輕易地將問題歸結于服務器硬件能力上。

主要的辦法是:認真地、實事求是地檢查每個進程在做什么;認真地研究服務的整個流程，分析問題最可能發(fā)生的地方;然后設計相應的檢測工作，收集情況，對其論證。只有這樣才能夠最終定位問題，并在此基礎上提出行之有效的解決方案，最終解決問題。

同時也從另一個側(cè)面告訴每一個網(wǎng)管人員，日常積極有效地記錄下網(wǎng)絡的一些變動情況，在故障出現(xiàn)的時候，這些資料能夠有效地為問題分析提供數(shù)據(jù)依據(jù)。