博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
数据库磁盘警戒值报警的原因竟是它!
阅读量:6151 次
发布时间:2019-06-21

本文共 690 字,大约阅读时间需要 2 分钟。

   早上突然收到数据库磁盘使用量监控的短信息,其中/var 分区的使用量已经达到了警戒值,这个奇怪呀,数据库的服务器和这个分区没多大关系,难道是某个服务产生了大量的日志信息?

    迷迷糊糊的困死我了,起床收拾收拾,赶公交,坐地铁,快步走来到单位,远程登录看看其中原因。
     首先 df -TH 看看每个分区的使用量,果然 var 分区使用了86%之多,报警的阀值是85% ,然后进入分区在查看一下每个目录的使用大小 du -sh ./* |sort  其中spool这个目录占用最多的,再次进入spool目录 执行du -sh ./* 其中 clientmqueue 这个目录占用的最多了。
     那么为什么会造成这样的呢? 是这样的:当使用 sendmail 发邮件,或者系统的某些任务默认情况下处理完成后要发邮件给相关的用户比如计划任务和logwatch之之类的,首先会把邮件复制到这个目录里,然后sendmail后发送这些邮件,如果你系统的sendmail停止掉了就会堆积在/var/spool/clientmqueue 中的。
   仔细查看文件的内容都是一下日常系统登录操作、定时的报告系统磁盘的使用情况、和计划任务的报告邮件,这些文件可以直接删掉 有时候因为文件太多直接使用 rm -f 的话会报告错误:Argument list too long 这可能是 文件数量太多的原因,没关系分批删除即可 rm -f `find ./ ctime +天数` 

   其实这个功能可以禁用掉,但是不建议,因为这个是系统将一下平常的活  动情况通过邮件提交给用户,可以查找错误原因,并且对系统的情况有个大致的了解。

 

 

转载地址:http://msgya.baihongyu.com/

你可能感兴趣的文章
数据库之MySQL
查看>>
2019/1/15 批量删除数据库相关数据
查看>>
数据类型的一些方法
查看>>
Mindjet MindManager 2019使用教程:
查看>>
详解 CSS 绝对定位
查看>>
AOP
查看>>
我的友情链接
查看>>
NGUI Label Color Code
查看>>
.NET Core微服务之基于Polly+AspectCore实现熔断与降级机制
查看>>
vue组件开发练习--焦点图切换
查看>>
浅谈OSI七层模型
查看>>
Webpack 2 中一些常见的优化措施
查看>>
移动端响应式
查看>>
python实现牛顿法求解求解最小值(包括拟牛顿法)【最优化课程笔记】
查看>>
js中var、let、const的区别
查看>>
腾讯云加入LoRa联盟成为发起成员,加速推动物联网到智联网的进化
查看>>
从Python2到Python3:超百万行代码迁移实践
查看>>
Windows Server已可安装Docker,Azure开始支持Mesosphere
查看>>
简洁优雅地实现夜间模式
查看>>
react学习总结
查看>>