計科專業(yè)從事嵌入式軟件開發(fā)多年，最近因為公司需要搞后臺研發(fā)，經(jīng)常選擇升級的時機放在凌晨，而且大型的數(shù)據(jù)處理也是放在這個時間段內(nèi)，經(jīng)常發(fā)生的服務(wù)器宕機也是在這個時段。都是在用戶使用少的時候開始折騰，折騰的次數(shù)多也就容易出現(xiàn)服務(wù)器問題。由于做的是物聯(lián)網(wǎng)設(shè)備，在工作中遇到的宕機主要有這么幾種情況，對大量數(shù)據(jù)的操作導(dǎo)致CPU占比在一段時間內(nèi)驟增從而導(dǎo)致數(shù)據(jù)接收模塊出問題，導(dǎo)致電銷外呼程序監(jiān)控出現(xiàn)問題，很多設(shè)備信息檢測不到了。

對數(shù)據(jù)庫的操作太頻繁導(dǎo)致效率的下降，也是影響電銷外呼程序性能很重要的一部分，其實服務(wù)器也是普通電腦的構(gòu)成，主要的資源是CPU和內(nèi)存，這兩個因素無論是哪種都有可能導(dǎo)致電銷外呼程序的崩盤，如果是CPU被占滿了，電銷外呼程序的反應(yīng)會變得異常緩慢源碼，時間長了可能還會慢慢緩過勁來，內(nèi)存如果占滿了那么會導(dǎo)致電銷外呼程序的崩潰，直接運行不下去了，其實宕機核心點不會跑出這兩種因素。

現(xiàn)在就常見的服務(wù)器宕機問題做個歸納總結(jié)：

1.磁盤空間被占滿，現(xiàn)在程序員運行的時候都習慣于帶上log打印，如果時間長了加上沒有清理的機制早晚會出問題，這個錯誤在平時運行過程中經(jīng)常出現(xiàn)，如果使用的云計算服務(wù)器通常在電銷外呼程序崩盤之前都會發(fā)個短信，通知你的電銷外呼程序處于崩潰的邊緣。

2.并發(fā)性能問題，如果多個人同時操作一個數(shù)據(jù)庫或者數(shù)據(jù)塊，會導(dǎo)致電銷外呼程序假死狀態(tài)源碼，這種屬于爭搶CPU資源問題，可以通過增加硬件配置以及優(yōu)化軟件代碼的效率去解決，數(shù)據(jù)量如何足夠大就可以考慮分布式的管理

3.數(shù)據(jù)受損或者被破壞導(dǎo)致電銷外呼程序崩盤，所以常見的做法是都會配置備份盤，出現(xiàn)問題抓緊拿到備份盤來頂上，現(xiàn)在公司使用的是阿里云的服務(wù)器，穩(wěn)定性相比之前好太多了，中間換過電銷電話云，騰訊云雖然價格低點，最后受不了直接換成阿里云，再也不想換回去了，數(shù)據(jù)的穩(wěn)定性永遠是第一位的。

4，一些沒有必要的誤操作，很多時候是因為程序員或者運維人員的誤操作大致服務(wù)器大面積的宕機，這種事件在很多云服務(wù)提供商身上都發(fā)生過，根本層面還是管理問題。后臺管理的任何細節(jié)都有可能

服務(wù)器宕機查找問題的幾個線索：

1.看看服務(wù)器是不是存在內(nèi)存泄漏問題，有些時候重啟機器開始還能正常運行弄了一段時間之后就會變得非常緩慢，十有八九都是內(nèi)存的問題

2.是否有黑客入侵造成，有些非常關(guān)鍵重要的數(shù)據(jù)也是黑客最感興趣的，一般來講這種概率不是很高

3.是不是數(shù)據(jù)庫死鎖導(dǎo)致的，訪問量過大導(dǎo)致，連接數(shù)過多造成的。

服務(wù)器宕機一旦發(fā)生就會引起用戶的無數(shù)的投訴，無論在什么情況下穩(wěn)定永遠是第一位，現(xiàn)在大的功能升級除非已經(jīng)百分百驗證成功，否則引起的后果不堪設(shè)想。

希望能幫到你。