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

一、查閱基本信息

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

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

二、初步分析

通過(guò)上面信息的了解，我們基本上確認(rèn)速度變慢的主要的原因是用戶量的增長(zhǎng)。因此，在這此前提下進(jìn)行了分析。

我們?cè)趌inux控制臺(tái)下，輸入以下命令查看系統(tǒng)的進(jìn)程情況:

ps –auxw

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

到此為止，我們得出了初步的結(jié)論:由于用戶的不斷增長(zhǎng)，并發(fā)用戶也越來(lái)越多，使得機(jī)器無(wú)法處理完這些并發(fā)請(qǐng)求，以致E-Mail服務(wù)器對(duì)用戶響應(yīng)過(guò)慢，甚至超時(shí)而無(wú)法使用。因此，我們認(rèn)為解決這一故障的辦法就是升級(jí)機(jī)器。

三、深入分析

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

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

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

那么，我們就在linux控制臺(tái)上輸入以下命令，查看使用/etc/passwd文件有多少個(gè)進(jìn)程:

fuser /etc/passwd

這時(shí)，列出了很多POP進(jìn)程，癥結(jié)總算找到了。原來(lái)是因?yàn)橄到y(tǒng)文件/etc/passwd是一個(gè)文本文件，在用戶名、密碼的匹配過(guò)程中，是采用逐行進(jìn)行匹配，而我們的/etc/passwd文件有2萬(wàn)多行，因此***的情況是***次匹配就成功，最壞的情況就是2萬(wàn)多次后才匹配成功，因此平均需要1萬(wàn)次的匹配。該過(guò)程所消耗的時(shí)間足以使得電子郵件接收程序超時(shí)，而無(wú)法等到匹配結(jié)束。

四、解決方法

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

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

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

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

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

五、解決效果

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

六、體會(huì)

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

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

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