這里直接舉例，用一臺單核2G內存的服務器，部署gitlab（官方推薦是要8核的，單核肯定炸），不多說，下面直接開始實驗
在運行gitlab-ctl reconfigure 后，服務器變得異常卡頓，一段之間之后就hang在那里了
1.首先用top指令，查看服務器究竟是哪個地方出問題了
用top指令查看cpu指標，首先先來解釋下下面這幾個指標分別代表了什么
// 用戶態 CPU 時間（不包括下面的 nice 時間，但包括了 guest 時間） us // 內核態 CPU 時間 sy // 低優先級用戶態 CPU 時間（進程的 nice 值被調整為 1-19 之間時的 CPU 時間。這里注意，nice 可取值范圍是 -20 到 19，數值越大，優先級反而越低） ni // 空閑時間（不包括等待 I/O 的時間【iowait】） id // 等待 I/O 的 CPU 時間 wa // 處理硬中斷的 CPU 時間 hi // 處理軟中斷的 CPU 時間 si // 系統運行在虛擬機中的時候，被其他虛擬機占用的 CPU 時間 st // 補充說明，其實cpu性能的常見輸出參數還有以下兩個 // 通過虛擬化運行其他操作系統的時間，也就是運行虛擬機的 CPU 時間 guest // 以低優先級運行虛擬機的時間 gnice
詳細的說明可以百度，這里的問題就是wa異常的高，也就是等待io的時間太高
其實用top命令，下面輸出的內容就基本知道原因了（這里我就不截圖了），因為接下來我介紹一個非常好用的工具，能幫你快速定位到服務器究竟是哪里出了問題
2.vmstat工具
用vmstat查看指標后，發現cpu忙不過來，有一堆進程被阻塞了（b為29），而且內存也被占滿了
這里直接貼出以前整理好的腦圖，說明下vmstat的參數
有人可能說， 明知道cup是單核的配置，我怎么可能會讓它跑那么多進程，但是這種情況我確實在生產環境（32核的cpu）遇到過，案例是這樣的，有個定時計劃任務，每分鐘執行一次，隨著數據庫數據量越大，腳本處理數據的時間增強，到后期就超過了1分鐘的執行時間，之后腳本慢慢的堆積起來直接把腳本服務器搞炸了，所以在執行計劃任務的時候，一定要評估好，最好的方法就是每次執行先判斷下該腳本在后臺運行的線程數，小于一定的閾值后就不再執行，避免cpu處理不過來
3.實驗結束，清理測試環境
執行gitlab-ctl stop（這里特別提醒一下，按照上文做完實驗別立刻斷開中斷，不然再次連接的時候，大概率連不上），等了很久一段時間，這命令才終于執行成功
但是ps -axu | grep -i gitlab后發現還有很多相關進程還沒有被kill掉
ps -aux | grep gitlab | awk '{print $2}' | args kill -9 執行后，發現那些進程又會重新啟動，然后服務器有卡住了。。。
沒辦法就只能去google了，發現了條命令
systemctl stop gitlab-runsvdir
執行后，很多進程都停掉了，就剩下pgsql的和一個redis，-d啟動的守護進程想kill也kill不掉，接下來就不再說明怎么處理了，可以留給看到這篇博客的小伙伴們去google解決方法
