我的E-Mail伺服器為什麼變慢了

來源:互聯網
上載者:User

  一切本來都是那樣的寧靜,所有的網路服務都在默默地工作著。然而近一段時間來,經常有人打電話反映一個相同的問題:在接收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個,但現在系統還是有條不紊地進行著,運行良好。

  六、體會

  在這個簡單的例子中,我們深深地感受到在日常的系統管理工作中必須仔細地分析問題,而不要輕易地將問題歸結於伺服器硬體能力上。

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

  同時也從另一個側面告訴每一個網管人員,日常積極有效地記錄下網路的一些變動情況,在故障出現的時候,這些資料能夠有效地為問題分析提供資料依據。



相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。