被迫学习一波Linux命令

事情起因

部署一个服务,人家说了最低配置是3G,我没当回事,拿着个2G的服务器直接就上了,结果,哈哈,都能猜到结果:服务器内存爆了!!!而且最可气的是服务器还登不进去,重启之后内马上又被拉满了,根本连接进不去。算是一次小小的事故,记录是为了不再犯同样的错误。

排查根因

上面说到,内存爆满,重启后短时间继续爆满,排查的问题的时间很有限,要快速定位到问题。其实我想到了:有服务在开机后自动重启,并且迅速拉起了其他子进程导致。本来给个3G的内存啥事也没有(本地测试都过了的),奈何云服务器就那么点资源,而且当时买的时候也没考虑那么多。

解决问题

针对以上猜想,查询一下最占用内存的都是哪些进程:
ps aux|head -1;ps aux|grep -v PID|sort -rn -k +4|head
果然,有一个进程52.6%,就是它了,kill掉。
结果很快内存又满了,再次重启,发现有两个用户gitgitlab占用最高,于是把这个用户的所有进程都干掉:
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|head

ps aux --sort -rss | head

方法不止一种,第一先解决问题,第二再慢慢积累。

转:关于资源占用的更多骚操作。

共勉。

你可能感兴趣的:(学习,linux,elasticsearch)