iis Web站點崩潰的原因分析

2019-11-02 16:51:15

字體：大中小

來源：轉載

供稿：網友

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

　　磁盤已滿

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

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

　　 C指針錯誤

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

　　內存泄漏

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

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

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

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

　　進程缺乏文件描述符

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

　　線程死鎖

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

上一篇：絕招：隱藏管理員賬號三分鐘搞定

下一篇：保護(IIS)web服務器安全的15個技巧