磁盤已滿

導(dǎo)致系統(tǒng)無(wú)法正常運(yùn)行的最可能的原因是磁盤已滿。一個(gè)好的網(wǎng)絡(luò)管理員會(huì)密切關(guān)注磁盤的使用情況诚亚，隔一定的時(shí)間站宗，就需要將磁盤上的一些負(fù)載轉(zhuǎn)存到備份存儲(chǔ)介質(zhì)中（例如磁帶）。
日志文件會(huì)很快用光所有的磁盤空間夷家。Web服務(wù)器的日志文件敏释、SQL*Net的日志文件、JDBC日志文件义屏，以及應(yīng)用程序服務(wù)器日志文件均與內(nèi)存泄漏有同等的危害“蛟可以采取措施將日志文件保存在與操作系統(tǒng)不同的文件系統(tǒng)中阳啥。日志文件系統(tǒng)空間已滿時(shí)Web服務(wù)器也會(huì)被掛起财喳，但機(jī)器自身被掛起的幾率已大大減低耳高。

C指針錯(cuò)誤

用C或C++編寫的程序，如Web服務(wù)器API模塊概荷，有可能導(dǎo)致系統(tǒng)的崩潰碌燕，因?yàn)橹灰g接引用指針（即，訪問(wèn)指向的內(nèi)存）中出現(xiàn)一個(gè)錯(cuò)誤愈捅，就會(huì)導(dǎo)致操作系統(tǒng)終止所有程序慈鸠。另外，使用了糟糕的C指針的Java模擬量（analog）將訪問(wèn)一個(gè)空的對(duì)象引用譬巫。Java中的空引用通常不會(huì)導(dǎo)致立刻退出JVM督笆，但是前提是程序員能夠使用異常處理方法恰當(dāng)?shù)靥幚礤e(cuò)誤胖腾。在這方面，Java無(wú)需過(guò)多的關(guān)注锨阿，但使用 Java對(duì)可靠性進(jìn)行額外的度量則會(huì)對(duì)性能產(chǎn)生一些負(fù)面影響记罚。

內(nèi)存泄漏

C/C++程序還可能產(chǎn)生另一個(gè)指針問(wèn)題：丟失對(duì)已分配內(nèi)存的引用。當(dāng)內(nèi)存是在子程序中被分配時(shí)末早，通常會(huì)出現(xiàn)這種問(wèn)題，其結(jié)果是程序從子程序中返回時(shí)不會(huì)釋放內(nèi)存郑趁。如此一來(lái)姿搜，對(duì)已分配的內(nèi)存的引用就會(huì)丟失舅柜，只要操作系統(tǒng)還在運(yùn)行中，則進(jìn)程就會(huì)一直使用該內(nèi)存变抽。這樣的結(jié)果是氮块，曾占用更多的內(nèi)存的程序會(huì)降低系統(tǒng)性能，直到機(jī)器完全停止工作逛钻，才會(huì)完全清空內(nèi)存锰提。
解決方案之一是使用代碼分析工具（如Purify）對(duì)代碼進(jìn)行仔細(xì)分析立肘，以找出可能出現(xiàn)的泄漏問(wèn)題。但這種方法無(wú)法找到由其他原因引起的庫(kù)中的泄漏茧痒，因?yàn)閹?kù)的源代碼是不可用的融蹂。另一種方法是每隔一段時(shí)間，就清除并重啟進(jìn)程区拳。Apache的Web服務(wù)器就會(huì)因這個(gè)原因創(chuàng)建和清除子進(jìn)程意乓。
雖然Java本身并無(wú)指針，但總的說(shuō)來(lái)笆凌，與C程序相比乞而， Java程序使用內(nèi)存的情況更加糟糕。在Java中放祟，對(duì)象被頻繁創(chuàng)建呻右，而直到所有到對(duì)象的引用都消失時(shí)声滥，垃圾回收程序才會(huì)釋放內(nèi)存侦香。即使運(yùn)行了垃圾回收程序，也只會(huì)將內(nèi)存還給虛擬機(jī)VM憾赁，而不是還給操作系統(tǒng)散吵。結(jié)果是：Java程序會(huì)用光給它們的所有堆矾睦，從不釋放。由于要保存實(shí)時(shí)（Just In Time缓溅，JIT）編譯器產(chǎn)生的代碼赁温，Java程序的大小有時(shí)可能會(huì)膨脹為最大堆的數(shù)倍之巨。
還有一個(gè)問(wèn)題袜匿，情況與此類似毁涉。從連接池分配一個(gè)數(shù)據(jù)庫(kù)連接，而無(wú)法將已分配的連接還回給連接池穆壕。一些連接池有活動(dòng)計(jì)時(shí)器喇勋，在維持一段時(shí)間的靜止?fàn)顟B(tài)之后，計(jì)時(shí)器會(huì)釋放掉數(shù)據(jù)庫(kù)連接贰拿，但這不足以緩解糟糕的代碼快速泄漏數(shù)據(jù)庫(kù)連接所造成的資源浪費(fèi)熄云。

進(jìn)程缺乏文件描述符

如果已為一臺(tái)Web服務(wù)器或其他關(guān)鍵進(jìn)程分配了文件描述符缴允，但它卻需要更多的文件描述符，則服務(wù)器或進(jìn)程會(huì)被掛起或報(bào)錯(cuò)矗漾，直至得到了所需的文件描述符為止薄料。文件描述符用來(lái)保持對(duì)開(kāi)放文件和開(kāi)放套接字的跟蹤記錄摄职，開(kāi)放文件和開(kāi)放套接字是Web服務(wù)器很關(guān)鍵的組成部分誊役，其任務(wù)是將文件復(fù)制到網(wǎng)絡(luò)連接。默認(rèn)時(shí)琳钉，大多數(shù)shell有64個(gè)文件描述符势木，這意味著每個(gè)從shell啟動(dòng)的進(jìn)程可以同時(shí)打開(kāi)64個(gè)文件和網(wǎng)絡(luò)連接。大多數(shù)shell都有一個(gè)內(nèi)嵌的 ulimit命令可以增加文件描述符的數(shù)目歌懒。

線程死鎖

由多線程帶來(lái)的性能改善是以可靠性為代價(jià)的啦桌，主要是因?yàn)檫@樣有可能產(chǎn)生線程死鎖。線程死鎖時(shí)及皂，第一個(gè)線程等待第二個(gè)線程釋放資源甫男，而同時(shí)第二個(gè)線程又在等待第一個(gè)線程釋放資源。我們來(lái)想像這樣一種情形：在人行道上兩個(gè)人迎面相遇验烧，為了給對(duì)方讓道，兩人同時(shí)向一側(cè)邁出一步碍拆，雙方無(wú)法通過(guò)若治，又同時(shí)向另一側(cè)邁出一步慨蓝，這樣還是無(wú)法通過(guò)。雙方都以同樣的邁步方式堵住了對(duì)方的去路端幼。假設(shè)這種情況一直持續(xù)下去礼烈，這樣就不難理解為何會(huì)發(fā)生死鎖現(xiàn)象了。
解決死鎖沒(méi)有簡(jiǎn)單的方法婆跑，這是因?yàn)槭咕€程產(chǎn)生這種問(wèn)題是很具體的情況此熬，而且往往有很高的負(fù)載。大多數(shù)軟件測(cè)試產(chǎn)生不了足夠多的負(fù)載滑进，所以不可能暴露所有的線程錯(cuò)誤犀忱。在每一種使用線程的語(yǔ)言中都存在線程死鎖問(wèn)題。由于使用Java進(jìn)行線程編程比使用C容易扶关，所以 Java程序員中使用線程的人數(shù)更多阴汇，線程死鎖也就越來(lái)越普遍了〗诨保可以在Java代碼中增加同步關(guān)鍵字的使用鲫寄，這樣可以減少死鎖，但這樣做也會(huì)影響性能疯淫。如果負(fù)載過(guò)重，數(shù)據(jù)庫(kù)內(nèi)部也有可能發(fā)生死鎖戳玫。
如果程序使用了永久鎖熙掺，比如鎖文件，而且程序結(jié)束時(shí)沒(méi)有解除鎖狀態(tài)咕宿，則其他進(jìn)程可能無(wú)法使用這種類型的鎖币绩，既不能上鎖，也不能解除鎖府阀。這會(huì)進(jìn)一步導(dǎo)致系統(tǒng)不能正常工作缆镣。這時(shí)必須手動(dòng)地解鎖。

服務(wù)器超載

Netscape Web服務(wù)器的每個(gè)連接都使用一個(gè)線程试浙。Netscape Enterprise Web服務(wù)器會(huì)在線程用完后掛起董瞻，而不為已存在的連接提供任何服務(wù)。如果有一種負(fù)載分布機(jī)制可以檢測(cè)到服務(wù)器沒(méi)有響應(yīng)田巴，則該服務(wù)器上的負(fù)載就可以分布到其它的 Web服務(wù)器上钠糊，這可能會(huì)致使這些服務(wù)器一個(gè)接一個(gè)地用光所有的線程。這樣一來(lái)壹哺，整個(gè)服務(wù)器組都會(huì)被掛起抄伍。操作系統(tǒng)級(jí)別可能還在不斷地接收新的連接，而應(yīng)用程序（Web服務(wù)器）卻無(wú)法為這些連接提供服務(wù)管宵。用戶可以在瀏覽器狀態(tài)行上看到connected（已連接）的提示消息截珍，但這以后什么也不會(huì)發(fā)生攀甚。
解決問(wèn)題的一種方法是將obj.conf參數(shù)RqThrottle的值設(shè)置為線程數(shù)目之下的某個(gè)數(shù)值，這樣如果越過(guò) RqThrottle的值岗喉，就不會(huì)接收新的連接秋度。那些不能連接的服務(wù)器將會(huì)停止工作，而連接上的服務(wù)器的響應(yīng)速度則會(huì)變慢沈堡，但至少已連接的服務(wù)器不會(huì)被掛起静陈。這時(shí)，文件描述符至少應(yīng)當(dāng)被設(shè)置為與線程的數(shù)目相同的數(shù)值诞丽，否則鲸拥，文件描述符將成為一個(gè)瓶頸。

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

許多數(shù)據(jù)庫(kù)的臨時(shí)表（cursor）數(shù)目都是固定的僧免，臨時(shí)表即保留查詢結(jié)果的內(nèi)存區(qū)域刑赶。在臨時(shí)表中的數(shù)據(jù)都被讀取后，臨時(shí)表便會(huì)被釋放懂衩，但大量同時(shí)進(jìn)行的查詢可能耗盡數(shù)目固定的所有臨時(shí)表撞叨。這時(shí)，其他的查詢就需要列隊(duì)等候浊洞，直到有臨時(shí)表被釋放時(shí)才能再繼續(xù)運(yùn)行牵敷。
這是一個(gè)不容易被程序員發(fā)覺(jué)的問(wèn)題，但會(huì)在負(fù)載測(cè)試時(shí)顯露出來(lái)法希。但可能對(duì)于數(shù)據(jù)庫(kù)管理員（DataBase Administrator枷餐，DBA）來(lái)說(shuō)，這個(gè)問(wèn)題十分明顯苫亦。
此外毛肋，還存在一些其他問(wèn)題：設(shè)置的表空間不夠用、序號(hào)限制太低屋剑，這些都會(huì)導(dǎo)致表溢出錯(cuò)誤润匙。這些問(wèn)題表明了一個(gè)好的DBA對(duì)用于生產(chǎn)的數(shù)據(jù)庫(kù)設(shè)置和性能進(jìn)行定期檢查的重要性。而且唉匾，大多數(shù)數(shù)據(jù)庫(kù)廠商也提供了監(jiān)控和建模工具以幫助解決這些問(wèn)題孕讳。
另外，還有許多因素也極有可能導(dǎo)致Web站點(diǎn)無(wú)法工作巍膘。如：相關(guān)性卫病、子網(wǎng)流量超載、糟糕的設(shè)備驅(qū)動(dòng)程序典徘、硬件故障蟀苛、包括錯(cuò)誤文件的通配符、無(wú)意間鎖住了關(guān)鍵的表逮诲。