事情起因
部署一个服务，人家说了最低配置是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 gitkillall -u gitpgrep -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 9ps -ef | grep git | grep -v grep |awk '{print $2}' | xargs kill -s 9：查看占用资源最大的进程：
# +4表示的是内存，cpu则+3ps aux|head -1;ps aux|grep -v PID|sort -rn -k +4|headps aux --sort -rss | head方法不止一种，第一先解决问题，第二再慢慢积累。
转：关于资源占用的更多骚操作。
共勉。