讓Web站點崩潰最多見的七大緣由

1 磁盤已滿

致使系統沒法正常運行的最可能的緣由是磁盤已滿。一個好的網絡管理員會密切關注磁盤的

使用狀況，隔必定的時間，就須要將磁盤上的一些負載轉存到備份存儲介質中（例如磁帶）
。

日誌文件會很快用光全部的磁盤空間。Web服務器的日誌文件、SQL*Net的日誌文件、

JDBC日誌文件，以及應用程序服務器日誌文件均與內存泄漏有同等的危害。能夠採起措施將日誌文件

保存在操做系統不一樣的文件系統中。日誌文件系統空間已滿時Web服務器也會被掛起，但機器自身被掛起的概率已大大減低。

2 C指針錯誤

用C或C++編寫的程序，如Web服務器API模塊，有可能致使系統的崩潰，

由於只要間接引用指針（即，訪問指向的內存）中出現一個錯誤，就會致使操做系統終止全部程序。另外，使

用了糟糕的C指針的Java模擬量（analog）將訪問一個空的對象引用。Java中的空引用一般

不會致使馬上退出JVM，可是前提是程序員可以使用異常處理方法恰當地處理錯誤。在這方面，
Java無需過多的關注，但使用Java對可靠性進行額外的度量則會對性能產生一些負面影響。

3 內存泄漏

 C/C++程序還可能產生另外一個指針問題：丟失對已分配內存的引用。當內存是在子程序中被

分配時，一般會出現這種問題，其結果是程序從子程序中返回時不會釋放內存。如此一來，對已分配的內存的引用就會丟失，

只要操做系統還在運行中，則進程就會一直使用該內存。這樣的結果是，曾佔用更多的內存的程序會下降系統性能，直到機器徹底中止

工做，纔會徹底清空內存。

4進程缺少文件描述符

 
若是已爲一臺Web服務器或其餘關鍵進程分配了文件描述符，但它卻須要更多的文件描述符，則服務器或進程會被掛起或報錯，直至獲得了所需的文件描述符爲止。

文件描述符用來保持對開放文件和開放套接字的跟蹤記錄，開放文件和開放套接字是Web服務器很關鍵的組成部分，其任務是將文件複製到網絡鏈接。默認時，大多數

shell有64個文件描述符，這意味着每一個從shell啓動的進程能夠同時打開64個文件和網絡鏈接。大多數shell都有一個內嵌的ulimit命令能夠增長文件描述符的數目。

5 線程死鎖

 
由多線程帶來的性能改善是以可靠性爲代價的，主要是由於這樣有可能產生線程死鎖。線程死鎖時，第一個線程等待第二個線程釋放資源，

而同時第二個線程又在等待第一個線程釋放資源。咱們來想像這樣一種情形：在人行道上兩我的迎面相遇，爲了給對方讓道，兩人同時向一側邁出一步，雙方沒法經過，又同時向另外一側邁出一步，

這樣仍是沒法經過。雙方都以一樣的邁步方式堵住了對方的去路。假設這種狀況一直持續下去，這樣就不難理解爲什麼會發生死鎖現象了。

 

解決死鎖沒有簡單的方法，這是由於使線程產生這種問題是很具體的狀況，並且每每有很高的負載。大多數軟件測試產生不了足夠多的負載，因此不可能暴露全部的線程錯誤。

在每一種使用線程的語言中都存在線程死鎖問題。因爲使用Java進行線程編程比使用C容易，因此Java程序員中使用線程的人數更多，線程死鎖也就愈來愈廣泛了。能夠在

Java代碼中增長同步關鍵字的使用，這樣能夠減小死鎖，但這樣作也會影響性能。若是負載太重，數據庫內部也有可能發生死鎖。

 

若是程序使用了永久鎖，好比鎖文件，並且程序結束時沒有解除鎖狀態，則其餘進程可能沒法使用這種類型的鎖，既不能上鎖，也不能解除鎖。這會進一步致使系統不能正常工做。這時必須手動地解鎖。

 
 

6 服務器超載

 

Netscape Web服務器的每一個鏈接都使用一個線程。Netscape Enterprise Web服務器會在線程用完後掛起，而不爲已存在的鏈接提供任何服務。

若是有一種負載分佈機制能夠檢測到服務器沒有響應，則該服務器上的負載就能夠分佈到其它的Web服務器上，這可能會導致這些服務器一

個接一個地用光全部的線程。這樣一來，整個服務器組都會被掛起。操做系統級別可能還在不斷地接收新的鏈接，而應用程序（Web服務器）卻沒法爲這些鏈接提供服務。用戶能夠在瀏覽器

狀態行上看到connected（已鏈接）的提示消息，但這之後什麼也不會發生。

 

解決問題的一種方法是將obj.conf參數RqThrottle的值設置爲線程數目之下的某個數值，這樣若是越過RqThrottle的值，就不會接收新的鏈接。那些不能鏈接的服務器將會中止工做，而

鏈接上的服務器的響應速度則會變慢，但至少已鏈接的服務器不會被掛起。這時，文件描述符至少應當被設置爲與線程的數目相同的數值，不然，文件描述符將成爲一個瓶頸。

 

7 數據庫中的臨時表不夠用

 

 
許多數據庫的臨時表（cursor）數目都是固定的，臨時表即保留查詢結果的內存區域。在臨時表中的數據都被讀取後，臨時表便會被釋放，但大量同時進行的查詢可能耗盡數目固定的全部

臨時表。這時，其餘的查詢就須要列隊等候，直到有臨時表被釋放時才能再繼續運行。這是一個不容易被程序員發覺的問題，但會在負載測試時顯露出來。但可能對於數據庫管理員（

DataBase Administrator，DBA）來講，這個問題十分明顯。

 

 此外，還存在一些其餘問題：設置的表空間不夠用、序號限制過低，這些都會致使表溢出錯誤。這些問題代表了一個好的DBA對用於生產的數據庫設置和性能進行按期檢查的重要性。而

且，大多數數據庫廠商也提供了監控和建模工具以幫助解決這些問題。

 

另外，還有許多因素也極有可能致使Web站點沒法工做。如：相關性、子網流量超載、糟糕的設備驅動程序、硬件故障、包括錯誤文件的通配符、無心間鎖住了關鍵的表。