上个周在项目运维中出现了一个非日常问题,特此记录下来,分享与自学

在前端日常通过BASH操作git的时候,突然给我反馈了这样一条信息。

因为项目的代码部署使用gitlab搭建的,很快下意识的我就先开始对gitlab进行排查,一般gitlab的问题只需要通过“三大件”即可解决,即关闭、开启、重启,对象下面的语法

gitlab-ctl stop  //关闭
gitlab-ctl start  //开启
gitlab-ctl restart  //重启

那么一顿猛如虎的restart之后我发现gitlab项目由之前的500变成了502,redis重启失败,原因不得而知,接下来通过搜索知可通过gitlab自带的日志去查取报错信息

gitlab-ctl status   //查看gitlab服务状态
gitlab-ctl tail //查看日志信息

由于日志是动态日志,跑的比我眼转的都快,所以感觉这个日志好像对我用处不是特别大,大多能看到redis链接失败 或者重启失败之类的,不过这个肯定是有原因的,项目从来都是一直稳定运行,为什么突然后down掉了呢。于是我再次提取了下上面的报错信息。No Space left on device.这句话翻译过来是磁盘空间不足,哦,磁盘空间不足导致没办法IO操作,导致git没办法正常执行,这是初步判定,于是我上了服务器。

df -l  //此命令在根目录下执行时为检查linux服务器的文件系统的磁盘空间占用情况(只显示本地文件系统信息)
size参数为总空间 | used参数为已经使用空间 | Avail参数为剩余空间  | use% 参数为已使用百分比

查看了系统磁盘占用之后,发现  /dev/mapper/VolGroup-lv_root 100% ,磁盘根目录已满。于是下一步就是找出不需要的垃圾文件删掉即可

du -sh /文件夹      //查看当前目录下各个文件占用空间大小

逐层排查,发现我这边服务器有一个27G大的垃圾文件,于是把它删掉之后重启gitlab服务,再去使用git操作,发现丝般顺滑。