这里直接举例，用一台单核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解决方法
