有許多種原因可能導(dǎo)致Web站點無法正常工作，這使得系統(tǒng)地檢查所有問題變得很困難。下面將集中分析總結(jié)導(dǎo)致Web站點崩潰的最常見的問題。如果可以解決這些常規(guī)問題，那么也將有能力對付出現(xiàn)的一些意外情況。

　　磁盤已滿
 
　　導(dǎo)致系統(tǒng)無法正常運行的最可能的原因是磁盤已滿。一個好的網(wǎng)絡(luò)管理員會密切關(guān)注磁盤的使用情況，隔一定的時間，就需要將磁盤上的一些負載轉(zhuǎn)存到備份存儲介質(zhì)中(例如磁帶)。

　　日志文件會很快用光所有的磁盤空間。Web服務(wù)器的日志文件、SQL*Net的日志文件、JDBC日志文件，以及應(yīng)用程序服務(wù)器日志文件均與內(nèi)存泄漏有同等的危害?？梢圆扇〈胧⑷罩疚募４嬖谂c操作系統(tǒng)不同的文件系統(tǒng)中。日志文件系統(tǒng)空間已滿時Web服務(wù)器也會被掛起，但機器自身被掛起的幾率已大大減低。

　　C指針錯誤

　　用C或C++編寫的程序，如Web服務(wù)器API模塊，有可能導(dǎo)致系統(tǒng)的崩潰，因為只要間接引用指針(即，訪問指向的內(nèi)存)中出現(xiàn)一個錯誤，就會導(dǎo)致操作系統(tǒng)終止所有程序。另外，使用了糟糕的C指針的Java模擬量(analog)將訪問一個空的對象引用。Java中的空引用通常不會導(dǎo)致立刻退出JVM，但是前提是程序員能夠使用異常處理方法恰當?shù)靥幚礤e誤。在這方面，Java無需過多的關(guān)注，但使用Java對可靠性進行額外的度量則會對性能產(chǎn)生一些負面影響。

　　內(nèi)存泄漏

　　C/C++程序還可能產(chǎn)生另一個指針問題：丟失對已分配內(nèi)存的引用。當內(nèi)存是在子程序中被分配時，通常會出現(xiàn)這種問題，其結(jié)果是程序從子程序中返回時不會釋放內(nèi)存。如此一來，對已分配的內(nèi)存的引用就會丟失，只要操作系統(tǒng)還在運行中，則進程就會一直使用該內(nèi)存。這樣的結(jié)果是，曾占用更多的內(nèi)存的程序會降低系統(tǒng)性能，直到機器完全停止工作，才會完全清空內(nèi)存。

　　解決方案之一是使用代碼分析工具(如Purify)對代碼進行仔細分析，以找出可能出現(xiàn)的泄漏問題。但這種方法無法找到由其他原因引起的庫中的泄漏，因為庫的源代碼是不可用的。另一種方法是每隔一段時間，就清除并重啟進程。Apache的Web服務(wù)器就會因這個原因創(chuàng)建和清除子進程。

　　雖然Java本身并無指針，但總的說來，與C程序相比，Java程序使用內(nèi)存的情況更加糟糕。在Java中，對象被頻繁創(chuàng)建，而直到所有到對象的引用都消失時，垃圾回收程序才會釋放內(nèi)存。即使運行了垃圾回收程序，也只會將內(nèi)存還給虛擬機VM，而不是還給操作系統(tǒng)。結(jié)果是：Java程序會用光給它們的所有堆，從不釋放。由于要保存實時(Just In Time，JIT)編譯器產(chǎn)生的代碼，Java程序的大小有時可能會膨脹為最大堆的數(shù)倍之巨。

　　還有一個問題，情況與此類似。從連接池分配一個數(shù)據(jù)庫連接，而無法將已分配的連接還回給連接池。一些連接池有活動計時器，在維持一段時間的靜止狀態(tài)之后，計時器會釋放掉數(shù)據(jù)庫連接，但這不足以緩解糟糕的代碼快速泄漏數(shù)據(jù)庫連接所造成的資源浪費。

　　進程缺乏文件描述符

　　如果已為一臺Web服務(wù)器或其他關(guān)鍵進程分配了文件描述符，但它卻需要更多的文件描述符，則服務(wù)器或進程會被掛起或報錯，直至得到了所需的文件描述符為止。文件描述符用來保持對開放文件和開放套接字的跟蹤記錄，開放文件和開放套接字是Web服務(wù)器很關(guān)鍵的組成部分，其任務(wù)是將文件復(fù)制到網(wǎng)絡(luò)連接。默認時，大多數(shù)shell有64個文件描述符，這意味著每個從shell啟動的進程可以同時打開64個文件和網(wǎng)絡(luò)連接。大多數(shù)shell都有一個內(nèi)嵌的ulimit命令可以增加文件描述符的數(shù)目。

　　線程死鎖

　　由多線程帶來的性能改善是以可靠性為代價的，主要是因為這樣有可能產(chǎn)生線程死鎖。線程死鎖時，第一個線程等待第二個線程釋放資源，而同時第二個線程又在等待第一個線程釋放資源。我們來想像這樣一種情形：在人行道上兩個人迎面相遇，為了給對方讓道，兩人同時向一側(cè)邁出一步，雙方無法通過，又同時向另一側(cè)邁出一步，這樣還是無法通過。雙方都以同樣的邁步方式堵住了對方的去路。假設(shè)這種情況一直持續(xù)下去，這樣就不難理解為何會發(fā)生死鎖現(xiàn)象了。 　　

　　解決死鎖沒有簡單的方法，這是因為使線程產(chǎn)生這種問題是很具體的情況，而且往往有很高的負載。大多數(shù)軟件測試產(chǎn)生不了足夠多的負載，所以不可能暴露所有的線程錯誤。在每一種使用線程的語言中都存在線程死鎖問題。由于使用Java進行線程編程比使用C容易，所以Java程序員中使用線程的人數(shù)更多，線程死鎖也就越來越普遍了。可以在Java代碼中增加同步關(guān)鍵字的使用，這樣可以減少死鎖，但這樣做也會影響性能。如果負載過重，數(shù)據(jù)庫內(nèi)部也有可能發(fā)生死鎖。

　　如果程序使用了永久鎖，比如鎖文件，而且程序結(jié)束時沒有解除鎖狀態(tài)，則其他進程可能無法使用這種類型的鎖，既不能上鎖，也不能解除鎖。這會進一步導(dǎo)致系統(tǒng)不能正常工作。這時必須手動地解鎖。

　　服務(wù)器超載

　　Netscape Web服務(wù)器的每個連接都使用一個線程。Netscape Enterprise Web服務(wù)器會在線程用完后掛起，而不為已存在的連接提供任何服務(wù)。如果有一種負載分布機制可以檢測到服務(wù)器沒有響應(yīng)，則該服務(wù)器上的負載就可以分布到其它的Web服務(wù)器上，這可能會致使這些服務(wù)器一個接一個地用光所有的線程。這樣一來，整個服務(wù)器組都會被掛起。操作系統(tǒng)級別可能還在不斷地接收新的連接，而應(yīng)用程序(Web服務(wù)器)卻無法為這些連接提供服務(wù)。用戶可以在瀏覽器狀態(tài)行上看到connected(已連接)的提示消息，但這以后什么也不會發(fā)生。

　　解決問題的一種方法是將obj.conf參數(shù)RqThrottle的值設(shè)置為線程數(shù)目之下的某個數(shù)值，這樣如果越過RqThrottle的值，就不會接收新的連接。那些不能連接的服務(wù)器將會停止工作，而連接上的服務(wù)器的響應(yīng)速度則會變慢，但至少已連接的服務(wù)器不會被掛起。這時，文件描述符至少應(yīng)當被設(shè)置為與線程的數(shù)目相同的數(shù)值，否則，文件描述符將成為一個瓶頸。

　　數(shù)據(jù)庫中的臨時表不夠用

　　許多數(shù)據(jù)庫的臨時表(cursor)數(shù)目都是固定的，臨時表即保留查詢結(jié)果的內(nèi)存區(qū)域。在臨時表中的數(shù)據(jù)都被讀取后，臨時表便會被釋放，但大量同時進行的查詢可能耗盡數(shù)目固定的所有臨時表。這時，其他的查詢就需要列隊等候，直到有臨時表被釋放時才能再繼續(xù)運行。

　　這是一個不容易被程序員發(fā)覺的問題，但會在負載測試時顯露出來。但可能對于數(shù)據(jù)庫管理員(DataBase Administrator，DBA)來說，這個問題十分明顯。

　　此外，還存在一些其他問題：設(shè)置的表空間不夠用、序號限制太低，這些都會導(dǎo)致表溢出錯誤。這些問題表明了一個好的DBA對用于生產(chǎn)的數(shù)據(jù)庫設(shè)置和性能進行定期檢查的重要性。而且，大多數(shù)數(shù)據(jù)庫廠商也提供了監(jiān)控和建模工具以幫助解決這些問題。

　　另外，還有許多因素也極有可能導(dǎo)致Web站點無法工作。如：相關(guān)性、子網(wǎng)流量超載、糟糕的設(shè)備驅(qū)動程序、硬件故障、包括錯誤文件的通配符、無意間鎖住了關(guān)鍵的表。