事情起因
部署一個服務，人家說了最低配置是3G，我沒當回事，拿著個2G的服務器直接就上了，結果，哈哈，都能猜到結果：服務器內存爆了！！！而且最可氣的是服務器還登不進去，重啟之后內馬上又被拉滿了，根本連接進不去。算是一次小小的事故，記錄是為了不再犯同樣的錯誤。
排查根因
上面說到，內存爆滿，重啟后短時間繼續爆滿，排查的問題的時間很有限，要快速定位到問題。其實我想到了：有服務在開機后自動重啟，并且迅速拉起了其他子進程導致。本來給個3G的內存啥事也沒有（本地測試都過了的），奈何云服務器就那么點資源，而且當時買的時候也沒考慮那么多。
解決問題
針對以上猜想，查詢一下最占用內存的都是哪些進程：
ps aux|head -1;ps aux|grep -v PID|sort -rn -k +4|head
果然，有一個進程52.6%，就是它了，kill掉。
結果很快內存又滿了，再次重啟，發現有兩個用戶git和gitlab占用最高，于是把這個用戶的所有進程都干掉：
pkill -u git
或者
killall -u git
好了，暫時沒有問題了，于是很滿意地吃飯去了。之后我想著那不要再重啟一次吧，果然不出我所料，重啟后又爆了。我仔細想了想剛剛壞之前執行過什么命令，應該就是它導致的，是的，就是gitlab-ctl這個主控進程一直在自動拉起其他子進程，本來內存要求就不夠，自然會爆掉。
gitlab-ctl stop
一大推子進程被停掉了，還是不放心，于是禁止這個程序開機自啟：
systemctl disable gitlab-runsvdir.service
至此，問題圓滿解決。
反思總結
1、別人給的配置不是亂給的，最小配置一定是經過測試的，畢竟寸‘土’寸金，這一點不用質疑；
2、趕快給服務器裝上監控，不要再裸機跑了，配置上必要的告警，及時知道資源的監控狀況；
3、不要隨便使用root用戶操作，如果今天這個進程是root運行的，那估計很難救了，在沒查清楚是哪個進程之前你總不能把root下的所有進程都kill了吧？
4、雖然只是個人服務器上的一次小小事故，但是同樣適用于生產，請謹慎操作，對自己也對他人負責；
5、最后把今天用到的linux命令再次做一個梳理吧：
：kill某個用戶下的所有進程的命令（四種方式）
pkill -u git
killall -u git
pgrep -u git | xargs kill -s 9# cut -c 9-15都是為了拿到pid，也可以用awk '{print $2}' 替換
ps -ef | grep git | grep -v grep | cut -c 9-15 | xargs kill -s 9
ps -ef | grep git | grep -v grep | awk '{print $2}' | xargs kill -s 9
：查看占用資源最大的進程：
# +4表示的是內存，cpu則+3
ps aux|head -1;ps aux|grep -v PID|sort -rn -k +4|headps aux --sort -rss | head
方法不止一種，第一先解決問題，第二再慢慢積累。
轉：關于資源占用的更多騷操作。
共勉。
