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

磁盤已滿

導致系統無法正常運行的最可能的原因是磁盤已滿。一個好的網絡管理員會密切關注磁盤的使用情況,隔一定的時間,就需要將磁盤上的一些負載轉存到備份存儲介質中(例如磁帶)。

日志文件會很快用光所有的磁盤空間。Web服務器的日志文件、SQL*Net的日志文件、 JDBC日志文件,以及應用程序服務器日志文件均與內存泄漏有同等的危害�？梢圆扇〈胧�將日志文件保存在與操作系統不同的文件系統中。日志文件系統空間已 滿時Web服務器也會被掛起,但機器自身被掛起的幾率已大大減低。

C指針錯誤

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

內存泄漏

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

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

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

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

進程缺乏文件描述符

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

線程死鎖

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

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

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

服務器超載

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

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

數據庫中的臨時表不夠用

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

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

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

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

文章來源于縱橫數據（www.qq-team.cn）