網站崩潰的原因
1.訪問量過高，超出系統承載能力
2.這個訪問量，不僅包括正常訪問，也有異常訪問的，包括攻擊在內。（黑客攻擊，黑客領用軟件請求服務器所有端口，但是不釋放端口，就導致其他用戶進不了這個網站。）
3.服務器配置過低，低於預期網站發展的設想，雖然是超負載，但是因為配置太低了。
4.服務器配置不低，但是存在多個網站，為某一個網站個體，划分的資源不足以承載網站運轉。
5.網站本身，存在代碼循環等沖突性錯誤，或者不斷地查詢導致資源耗盡。
怎么減小網站崩潰的可能
可以更換內存、磁盤空間大一點，穩定一點的服務器，也可以升級維護數據庫，完善代碼，定期維護網站。適時引流分散一下來訪人員的時間點。
第一，內存泄漏
C/C++程序還可能產生另一個指針問題：丟失對已分配內存的引用。當內存是在子程序中被分配時，通常會出現這種問題，其結果是程序從子程序中返回時不會釋放內存。如此一來，對已分配的內存的引用就會丟失，只要操作系統還在運行中，則進程就會一直使用該內存。這樣的結果是，曾占用更多的內存的程序會降低系統性能，直到機器完全停止工作，才會完全清空內存。
第二，C指針錯誤
用C或C++編寫的程序，如Web服務器API模塊，有可能導致系統的崩潰，因為只要間接引用指針(即訪問指向的內存)中出現一個錯誤，就會導致操作系統終止所有程序。另外，使用了糟糕的C指針的Java模擬量(analog)將訪問一個空的對象引用。Java中的空引用通常不會導致立刻退出JVM，但是前提是程序員能夠使用異常處理方法恰當地處理錯誤。
第三，數據庫中的臨時表不夠用
許多數據庫的臨時表(cursor)數目都是固定的，臨時表即保留查詢結果的內存區域。在臨時表中的數據都被讀取后，臨時表便會被釋放，但大量同時進行的查詢可能耗盡數目固定的所有臨時表。這時，其他的查詢就需要列隊等候，直到有臨時表被釋放時才能再繼續運行。
第四，線程死鎖
由多線程帶來的性能改善是以可靠性為代價的，主要是因為這樣有可能產生線程死鎖。線程死鎖時，第一個線程等待第二個線程釋放資源，而同時第二個線程又在等待第一個線程釋放資源。我們來想像這樣一種情形:在人行道上兩個人迎面相遇，為了給對方讓 道，兩人同時向一側邁出一步，雙方無法通過，又同時向另一側邁出一步，這樣還是無法通過。雙方都以同樣的邁步方式堵住了對方的去路。假設這種情況一直持續下去，這樣就不難理解為何會發生死鎖現象了。
第五，磁盤已滿
導致系統無法正常運行的最可能的原因是磁盤已滿。一個好的網絡管理員會密切關注磁盤的使用情況，隔一定的時間，就需要將磁盤上的一些負載轉存到備份存儲介質中(例如磁帶)。
日志文件會很快用光所有的磁盤空間。Web服務器的日志文件、SQL*Net的日志文件、 JDBC日志文件，以及應用程序服務器日志文件均與內存泄漏有同等的危害。可以采取措施將日志文件保存在與操作系統不同的文件系統中。日志文件系統空間已 滿時Web服務器也會被掛起，但機器自身被掛起的幾率已大大減低。
第六，服務器超載
Netscape Web服務器的每個連接都使用一個線程。Netscape Enterprise Web服務器會在線程用完后掛起，而不為已存在的連接提供任何服務。如果有一種負載分布機制可以檢測到服務器沒有響應，則該服務器上的負載就可以分布到其 它的Web服務器上，這可能會致使這些服務器一個接一個地用光所有的線程。這樣一來，整個服務器組都會被掛起。操作系統級別可能還在不斷地接收新的連接， 而應用程序(Web服務器)卻無法為這些連接提供服務。用戶可以在瀏覽器狀態行上看到connected(已連接)的提示消息，但這以后什么也不會發生。
總之，還有許多因素也極有可能導致服務器租用或服務器托管站點無法工作。有許多種原因可能導致Web站點無法正常工作，這使得系統地檢查所有問題變得很困難。
服務器宕機原因及解決辦法
什么是服務器宕機？
服務器宕機指的是服務器由於某些原因導致服務器無法正常運轉，造成網絡無法使用，對於網站來說，服務器宕機帶來的影響很大，他不但造成訪客對網站無法訪問，甚至影響到網站在搜索引擎上的排名。
在服務器的使用過程中，服務器的宕機隨時都有可能出現，首先我們要找到服務器宕機的原因，才能找到對應的解決方案。
服務器宕機可能分為兩種情況，服務器的假死機和死機
假死機（非藍屏死機）是由於硬件資源暫時性的被消耗殆盡，因為無法對外部指令進行相應的現象，通常是網站處於訪問高峰期，帶寬等資源跑滿，通常只需要等待一段時間，等待服務器騰出更多的資源即可恢復正常
而死機，如果通過ping測試服務器，鍵盤切換數字鍵和大寫字母鍵功能，顯示器無畫面輸出，或者鼠標光標沒有任何反應，則表示服務器硬件出現故障
服務器出現故障的常見原因
1.服務器性能的原因
性能問題中，最常見的服務器宕機原因是運行很糟糕的SQL，但也不能確定一定是這樣的，還有其他的可能，比如也有些問題是由於服務器Bug或錯誤的行為導致的。
此外，較差的Schema和索引設計是第二大影響性能的問題。
2.運行環境的原因
如果是運行環境問題，那么最常見的就是磁盤空間耗盡。
3.數據丟失或損壞的原因
數據丟失，一般情況下是由於droptable的錯誤操作導致，並總是便隨着缺少可用備份的問題。
4.復制的原因
如果是復制問題，那么一般是由於主備數據不一致導致的。
既然了解了服務器宕機的原因，那么如何判斷或查看服務器宕機的原因呢?
(1)查看是否是誤操作導致
(2)查看是否是應用程序異常導致
(3)查看是否是應用程序導致內存溢出或者泄露，outofmemory導致
(4)查看是否是流量負載過大導致
(5)查看是否是遭受黑客入侵攻擊導致
當查出造成服務器宕機的原因后，我們又該如何進行解決呢?
以上介紹了關於服務器宕機的原因、判斷、解決，當然你也可以選擇萬變雲的雲主機，因為其中一個服務器出問題時，會啟用其他服務器，以保障你網站安全的運行，可以大大降低網站無法訪問的幾率。
如何查看服務器宕機的原因？
1.是否是應用程序導致內存溢出或者泄露導致，out of memory導致？
2.是否是進程過多或不斷創建，導致資源耗盡導致？
3.是否是數據庫程序死鎖，或者連接數過多導致？
4.是否是應用程序異常導致？
5.是否是流量負載過大導致？
6.是否是遭到黑客入侵導致？
7.是否是操作有誤導致？
服務器宕機如何解決？
1、發現服務器宕機后，及時聯系服務器商解決相關問題，因為也許短暫的宕機，會給你帶來重大損失。
2.做好防范准備。可以准備兩個網站空間，他們存放的內容相同，而ip地址不相同，並且機房的地理位置不同，這樣兩個主機，同時出現宕機的可能性就大大降低了。第一時間發現服務器宕機問題后，可以迅速的通過修改dnspod.com中的域名記錄，指向目前正常的網站空間，
dnspod解析生效的時間是實時的，而一般的dns服務器刷新時間比較長，對外聲稱24小時生效，但是按照實際經驗來看，差不多30分鍾內生效，否則就要檢查域名綁定是否正確了。
阿里雲雲服務器如何進行宕機排查？
1.啟動機器，看是否能登錄。
2.看以下幾個方面：連接數過多，應用程序異常，流量負載過大，遭受黑客入侵攻擊 誤操作，如果無法查看故障現場，請檢查以下可能的原因: 應用程序導致內存溢出或泄露，進程過多或者不斷創建，資源耗盡，數據庫程序死鎖，如果能登陸，可以查詢系統日志查看是否有異常記錄。
將近百萬訪問量，每天上午9點左右和晚上10點左右必定會宕機。每次重啟服務器后問題都沒有了，沒法知道具體是那塊所造成。開始仔細想問題在那邊，H5新聞站點基本上都是使用搜索引擎運行的，包括后來我開發的PC站點全部采用搜索引擎運行，不會有任何數據庫操作。以為是mysql配置需要優化，所以就開始做起了服務器優化。
1、第一看見就是服務器IO過高造成了宕機，經過排查是mysql所占用，開始調整H5項目把直接操作數據庫的部分都改成搜索引擎。重啟后通過mysql命令行 show processlist; 查看正常，懷疑這個時候是腳本沒運行，所以查不到問題了。
2、為了不影響業務運作，把線上有收益的業務遷移到其它服務器。磁盤重新分布，圖片，數據庫，搜索引擎全部分開，發現mysql磁盤過高，由此可以完全定位IO過高和mysql脫不了一點干系。
3、開始做mysql配置優化，不能讓服務器宕機，經過兩天的調試，服務器不宕機了，IO還是能夠達到80%以上。平時偶爾也發現IO也不小。開始頭疼了應用程序和服務器都優化了還是不見有個好的效果。
4、持續觀察IO狀況，在IO高的時候排查mysql，發現有部分sql運行時間都是在30秒以上，IO都是讀的負載過高，肯定是這個原因導致的，這條sql所使用的字段沒有索引，加上索引后，IO明顯下降到5%左右。
5、當時心里非常激動，花了兩天調試服務器各種配置優化。結果發現饒了這么大一個彎。最終還是因為mysql索引優化問題，最終問題還是出現在爬蟲上面，每次爬蟲跑的時候都會比對數據，再數據表越來越大的時候，字段沒有索引就慢如蝸牛。雖然繞彎了還是有很大的收獲的，在各種配置優化上也更明白的認識到了很多場景的優化方式。
6、很多時候都是本地開發好的項目，怎么玩都正常，只要上線都會有點問題，運營一段時間后問題也越來越多，這都是沒有考慮到很多因素的問題。