Linux设备上没有空间之复盘

某天前端在调接口的时候，发现登陆页面得验证码接口竟然没有响应数据，显示的是500响应码。因而我一路排查，首先排查验证码接口所属的微服务是否正常，经过lsof -i:服务端口进行排查，发现该微服务进程存在，同时我在服务注册中心的服务管理列表也发现该服务正常注册。结合以前遇到的问题，验证码接口报500，没有及时响应数据，与Redis有关，验证码的数据会存放Redis，我再次排查Redis，发现Redis也正常，最后我看错误日志。我排查该问题的步骤:

• 第一排查提供验证码的微服务是否正常；
• 第二排查服务注册中心是否有该服务；
• 第三排查Redis是否正常运行；
• 最后查看日志。
  最后我从错误日志中看到了设备上没有空间这样的错误信息。当时我尚未意识到，多是Linux磁盘空间不足的缘由，下意识使用程序员的万能绝招”重启”，但”重启”并无从根本上解决这个问题，这里提到的”重启”是指重启Java应用而不是重启Linux服务器。最后发现重启也不能解决这个问题，因而我又下意识的以为是内存的缘由，因而便直接关闭其它无需和前端对接口的微服务，忽然发现问题一下解决了。因而就没有深究了。
  然后过了一个小时左右，前端又再次反馈其它接口有问题了，不能及时响应正确的数据，所有报500，这时我开始慌了，隐隐约约以为问题并未从根本上解决，根本不是内存的缘由，这时我才想起用free -m命令查看一下内存的使用，发现还有2个多G的内存，排除了内存不足的缘由，一般运行Java应用，内存不足会报以下异常:

Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000794500000, 576716800, 0) failed; error='Cannot allocate memory' (errno=12)

这时我冷静下来，看日志信息，再次发现了这句话”设备上没有空间”。因而经过关键字搜索，找到了问题所在，如图所示:

 

 

结合Windows，形象地归纳，就是个人系统盘C盘满了。

2、当时我很疑惑为何/dev/mapper/centos-root一下就满了呢？

我仔细想了下，发现我将不少软件和服务以及日志所有放在/usr下的某个目录里，因而我一路排查后，发现有这么几类文件占用很大的空间:

• 日志文件(Nacos日志以及各项微服务日志、MySQL日志、系统日志等足足10G以上，这时我终于明白了，为何日志要实时备份传输以及删除了)；
• 遗留的软件包和压缩包(10G以上)；
• 静态文件(离线地图，足足占了20G以上)和其它图片文件；
• 项目源代码以及打包成功后的jar(3个多G)；
• Maven仓库(足足占了5个多G)。

3、问题已经定位到了，那么我是如何解决这个问题的？

问题的根源在于不合理的占用系统盘空间，将这些不合理的从系统盘空间转移出去便可，转移到磁盘空间充足的，也就是/dev/mapper/centos-home下。

我作了这些事情:

• 备份日志，下载到本地(目前备份服务器尚未申请下来，同时关于哪些须要保留的，须要内部协商探讨)，原有的日志进行删除(这个工做能够脚本化)；
• 遗留软件包和压缩包直接删除；
• 静态文件迁移至/home下的某个用户目录，经过配置进行映射(确保迁移后仍不影响正常的访问)；
• 项目源代码迁移到/home下的某个用户目录；
• 修改Maven配置文件，仓库地址指向/home下的某个用户目录。

最终解决了这个问题，释放了50%的空间，其中还有15%暂时不能动。
这样一来，/dev/mapper/centos-root这个系统盘获得了充分释放，同时/dev/mapper/centos-home也获得了充分利用(再也不资源闲置)。

4、问题列表和具体解决措施

1.如何经过Linux命令知道当前磁盘空间使用状况?

命令格式以下:
du -sh 文件路径

du -sh *

执行就能看到当前文件以及文件夹所占用内存。占用内存多的，可进一步查看究竟是什么缘由占用这么多内存的。

下面就是我经过du -sh *命令查看内存占用最多的文件或文件夹:

• Nacos;
• MySQL;
• Nginx;
• Project。

2.为何Nacos会占用这么多内存呢？它仅仅是一个服务注册中心并不对外提供服务。

经过du -sh 命令，我排查到原来是nacos下的bin目录占用内存最多，其它不多，因而我进一步查看，发现bin目录下的log目录占用内存最多，由于该log目录下主要是nacos的访问日志，最后我经过du -sh 命令查看，如图所示:

 

 

由图可知，平均一个日志文件就是一百多M，足足占了十几个G也就不足为奇了。

个人解决办法很简单，分为两个方面:
第一方面是定时删除仅保留一个和备份迁移到/home下的某个目录;
第二个方面经过修改nacos的配置解决，具体参考以下连接:
Nacos系列(4)-Nacos各类日志太多问题的终极解决办法

3.为何MySQL会占用这么多磁盘空间？

经过命令排查(即du -sh *)，我发现是MySQL下的data目录占用磁盘空间最大，其中有一个足足占了4个多G，针对这样的问题，我将其直接由/usr/software目录下迁移到/home下，这样一来系统盘的空间再度获得释放，迁移后须要改mysql的配置文件(即my.cnf文件)。

4.Nginx为什么占用这么多磁盘空间？

之因此占用这么多，前面我提到过是由于离线地图，离线地图包括街道地图和卫星地图，两个加在一块儿足足二十多G，为此我将其迁移到/home下的某个目录，而后修改Nginx的核心配置nginx.conf文件进行映射，这样一来系统盘的空间再次获得释放，同时用户盘的空间获得了充分利用。

5.关于Project

Project主要放源代码和打包成功产生的jar，我仍是用老办法将其迁移(迁移到/home下的某个目录)。

5、问题的根本缘由是什么？为何我须要排查这么长时间才定位到这个缘由呢？

问题的根本缘由在于不规范性。正常来讲，不该该将用户磁盘空间作的事情放在系统磁盘空间(与Windows同理)。从这一刻起，我也深深意识到规范性的重要，不规范性致使的bug何止千千万万，仔细想来个人开发经历，形成bug的绝大多数缘由均是由于不规范，由于不规范，暴露出各类奇奇怪怪的bug。
另外从我排查问题来看也是颇有问题的，问题在于没有用正确的态度对待日志，其实一开始仔细排查日志，定位到这个关键信息，而后将这样的关键信息复制搜索引擎来寻找解决办法，这样一来就没必要浪费了近一个多小时来捣鼓这样的事情。

6、如何避免这样的问题再现？以及经过这样的问题总结出什么样的原则？

首先这样的问题属于运维范畴，而我做为公司的兼职运维，面对这样的问题，首先从规范入手，制定可行的规范，从根本上杜绝这样的问题再现，对于这样的问题，我总结的原则以下:

• (1)不一样的用户作不一样的事情，保持Linux用户的功能专注性(后面会提到一个重大bug,是由于违反这样的原则致使的)；
• (2)遇到问题，分为两个方面来解决，见过和没有见过，见过表示过去我遇到过这样的问题，能够借鉴以往经验来快速解决这个问题；没有见过的问题，严格遵照的流程:复现问题->仔细查看日志->定位问题->解决问题->总结并存入知识库(若有必要进行按期复盘)。总而言之，最关键的在于定位问题(如何定位问题，可经过重复复现问题->仔细查看日志这样的步骤来定位；
• (3)针对常见运维需求，编写脚本(如监控系统磁盘使用状况以及用户磁盘使用状况，超出阈值，自动告警和人工干预)，推动脚本自动化；
• (4)制定适合当下状况的运维规范(如安装软件安在哪一个目录、大文件放在哪一个目录、日志存放多久并备份后自动清除、每一个用户只作本身的事情等,根据实际状况不断增长和修订，按期写入文档进行维护)。