大型網站典型故障案例分析(摘錄)

一.寫日誌也會引起故障java

故障現象:某應用服務器集羣發佈不久後就出現多臺服務器相繼報警,磁盤可用空間低於警惕值,而且很快有服務器宕機,登陸到線上服務器,發現log文件夾的文件迅速增長,不斷消耗磁盤空間。web

緣由分析:這是一個普通的應用服務器集羣,不須要存儲數據,所以服務器裏配置的是一塊100G的小硬盤,安裝操做系統,web服務器,java虛擬機,應用程序後,空閒空間只有幾十G了,正常下夠有了,可是該應用的開發人員將log輸出的level全局配置爲Debug,這一次簡單的web請求就產生大量的log文件輸出,在高併發的用戶請求下,很快消耗完很少的磁盤空間。sql

經驗教訓:數據庫

應用程序本身的日誌輸出配置和第三方組建日誌輸出要分別配置apache

檢查log配置文件,日誌輸出級別至少爲warn,而且檢查log輸出代碼調用,調用級別符合真實日誌級別編程

二.高併發訪問數據庫引起的故障瀏覽器

故障現象:某應用發佈後,數據庫load居高不下,遠超過正常水平,持續報警緩存

緣由分析:檢查數據庫,發現報警是由於某條sql引發的,這條sql是一條簡單的有索引的查詢,不該該引發報警,經檢查其執行頻率太高,追查這個sql,發現被網站首頁應用調用,主頁被訪問多了,這個sql也就被執行的多了服務器

經驗教訓:網絡

首頁不該該訪問數據庫,首頁須要的數據能夠從緩存服務器或者搜索服務器獲取。

首頁最好是靜態的

 

三.緩存引起的故障

故障現象:沒有新應用發佈,可是數據庫服務器忽然load飆升,並很快失去響應,DBA將數據庫訪問切換到備機,Load也很快飆升,並失去響應,最終引起全站癱瘓

緣由分析:緩存服務器在網站服務器集羣中的地位一直比較低,服務器配置和管理級別比其餘服務器要低一些,人們認爲緩存是改善性能的手段,失去一些緩存也沒有什麼問題,有時候關閉一兩臺緩存服務器也確實沒啥問題,因此長期疏於管理。結果此次一個缺少經驗的工程師關閉了關閉了緩存服務器所有的幾十臺memcached,致使了網站所有癱瘓的重大事故

經驗教訓:

當緩存不只僅是提升性能,而是成爲網站架構不可或缺的一部分時,對緩存服務器的管理須要提升到和其餘服務器一個級別

 

四.應用啓動不一樣引起的故障

故障現象:某應用發佈後,服務器當即崩潰

緣由分析:應用程序web環境使用apache+jboss的模式,用戶請求經過apache轉發到jboss。在發佈時apache和jboss同時啓動,因爲jboss啓動須要加載不少應用並初始化,花費時間較長,結果jboss沒有徹底啓動,apache已經啓動完畢並接受用戶請求,大量的請求阻塞在jboss進程中,致使jboss崩潰。除了apache和jboss啓動不一樣步的狀況,還有不少相似的狀況,都須要後臺服務器準備好,前臺應用才能啓動,不然會致使故障

經驗教訓:

在本例中,啓動腳本首先啓動jboss,而後在腳本中不斷用curl訪問這個特定頁面,直到ok,才啓動apache。

 

 

五.大文件讀寫獨佔磁盤引起的故障

故障現象:某應用主要功能是管理用戶圖片,接到部分用戶投訴,表示上傳圖片很是慢,原來只需一秒,如今須要幾十秒,有時等半天結果瀏覽器顯示服務器超時。

緣由分析:圖片須要使用存儲,最有可能出錯的是存儲服務器,檢查存儲服務器,發現大部分文件只有幾百kb,而有幾個文件很是大,有幾百兆,讀寫這些大文件一次須要幾十秒,這段時間,磁盤通常這個文件操做獨佔,致使其餘用戶的文件讀寫慢。

經驗教訓:

存儲的使用須要根據不一樣文件類型和用途進行管理,圖片都是小文件,應該使用專用的存儲服務器,不能和大文件共存儲,批處理用的大文件可使用其餘類型的分佈式文件系統

六.濫用生產環境引起的故障:

故障現象:監控發現某個時間段內,某個應用忽然變慢,內部網絡訪問延遲很是厲害

緣由分析:檢查發現,該時段內網卡流量也降低,可是沒找到緣由。過了一陣子才知道,原來有工程師在線上生產環境進行性能壓力測試,佔用了大量交換機帶寬

經驗教訓:

訪問現象生產環境要規範,一不當心就會致使大事故

 

七.不規範的流程引起的故障

故障現象:某應用發佈後,數據庫load迅速飆升,超過報警值,回滾發佈後報警消除

緣由分析:發現該應用發佈後出現大量數據庫讀操做,而這些數據原本應該從分佈式緩存中提取,檢查緩存,發現數據已經被緩存了。檢查代碼,發現訪問緩存的代碼被註釋了。原來工程師在開發的時候,爲了測試方便,特地註釋讀緩存的代碼,結果開發完後,忘記了去掉註釋。直接提交代碼到線上服務器環境。

經驗教訓:

代碼提交前使用diff命令進行代碼比較,確認沒有不應提交的代碼!

 

八.很差的編程習慣引起的故障

故障現象:某應用更性某功能後,有少許用戶投訴沒法訪問該功能,一點擊就顯示出錯信息。

緣由分析:分析這些用戶都是第一次使用該功能,檢查代碼,發現程序根據歷史使用記錄構造一個對象,若是該對象爲null,就會致使NullPointException。

經驗教訓:

程序在處理一個輸入的對象時,若是不能明確該對象是否爲空,必須作空指針判斷

程序在條用其餘方法是,輸入的對象儘可能保證不是null,必要時構造空對象

 

 

摘錄自《大型網站技術架構核心原理與案例分析》

相關文章
相關標籤/搜索