網(wǎng)站故障處理記實(shí):apache引起的麻煩 |
發(fā)布時間: 2012/8/13 11:22:31 |
春節(jié)還沒過完就接到同事的電話,說論壇訪問速度慢,遭致用戶強(qiáng)烈的投訴,要求我馬上處理。這個bbs是運(yùn)行在RedhatAS5上,由apache、mysql、php和discuz組成,有129550位注冊會員,同時在線的最高人數(shù)11128,按照當(dāng)前的硬件條件,應(yīng)該滿足訪問需求(新上線的HP服務(wù)器)。在瀏覽器輸入論壇的url,果然很慢,再聯(lián)系朋友幫忙測試,打開網(wǎng)絡(luò)還是很慢。
惡意攻擊?mysql癱瘓? 先不管這么多,登錄到服務(wù)器上去看看再做下一步打算。還好,登錄比較順利。運(yùn)行命令uptime看系統(tǒng)負(fù)載,很低呀,再運(yùn)行命令top,跟uptime得出的結(jié)論基本吻合,于是得出結(jié)論:系統(tǒng)負(fù)載不大。 是否被惡意攻擊呢?基于這個想法,察看系統(tǒng)帳號—打開文件/etc/passwd,沒看見任何異常;運(yùn)行命令iptables–L–n發(fā)現(xiàn)防火墻規(guī)則仍按我當(dāng)初設(shè)定的策略執(zhí)行,這些跡象表明,系統(tǒng)不存在安全問題。 那會不會是mysql的性能問題呢?用mysql客戶端連接數(shù)據(jù)庫,察看負(fù)載,其情況如下: 從輸出結(jié)果看,連接數(shù)和保持時間也在正常范圍內(nèi)。以前曾經(jīng)有過mysql數(shù)據(jù)庫連接數(shù)過多(達(dá)到設(shè)定的最大連接數(shù))及會話保持時間(Time)過長的事故,從而導(dǎo)致網(wǎng)站訪問速度變慢,以至于無法忍受。由此分析,這個故障不是由mysql數(shù)據(jù)庫所引起的。 現(xiàn)在還剩下apache了,看來該懷疑一下它了。我們先看看有多少個httpd進(jìn)程,其過程如下:
這個結(jié)果表明請求數(shù)比較大但卻沒有得到適時的響應(yīng),再看一下這些請求都是發(fā)往那些服務(wù)端口,只需運(yùn)行netstat–anp|grep–vunix,發(fā)現(xiàn)絕大部分請求是針對80端口的。由這個現(xiàn)象基本可以斷定是apache引起的麻煩。那好,我就從這里著手。關(guān)apache服務(wù)再啟用,這時察看httpd進(jìn)程,馬上就是256.既然這樣,我就在配置文件httpd.conf加入下面的代碼塊: 執(zhí)行apachectl–t,報(bào)錯,警告說MaxClients超過256,以至于apache服務(wù)不能正常運(yùn)行,該小一點(diǎn)呢?好,改成150,運(yùn)行后,查httpd進(jìn)程數(shù),剛好150。用瀏覽器訪問論壇,還是十分的緩慢?磥淼贸蟮姆较蚋模駝t瞬間apache達(dá)到最大連接數(shù),就不再響應(yīng)新的請求。從前面的操作(把MaxClients的值改大超過256)可以知道,必須重新編譯和安裝apache才可以達(dá)到目的。當(dāng)時曾經(jīng)嘗試把a(bǔ)pache置于worker模式,但在編譯時涉及到php,不想再節(jié)外生枝,就不再繼續(xù)。我用的apache版本是httpd-2.2.6,進(jìn)安裝包所在的目錄(如我的目錄是/root/httpd-2.2.6,即解壓httpd-2.2.6.tgz后生成的目錄),修改文件server/mpm/prefork/prefork.c,把第77行的值改成1500,如下圖所示: 然后再編譯,運(yùn)行和安裝。再使配置文件httpd.confMaxClients的值為1500,運(yùn)行apachectl–t檢查語法是否正確,無誤后啟用apache服務(wù)apachectlstart.現(xiàn)在,我們再回過頭來察看apache的進(jìn)程數(shù),基本上在170-400這個范圍,并且在不停的變化,隔設(shè)定的1500這個值還差得遠(yuǎn);另外那些等待的請求值也降低了,這意味apache能正常響應(yīng)用戶的請求。在瀏覽器輸入論壇的url,速度正常,再請其他朋友幫著測試,一切正常。 本文出自:億恩科技【mszdt.com】 服務(wù)器租用/服務(wù)器托管中國五強(qiáng)!虛擬主機(jī)域名注冊頂級提供商!15年品質(zhì)保障!--億恩科技[ENKJ.COM] |