转载

Linux下/var/spool/clientmqueue空间不足的解决

今天收到一封报警邮件，内容如下：
------------------------------------

报警内容: Free disk space is less than 15% on volume /var
------------------------------------
报警级别: PROBLEM
------------------------------------
监控项目: Free disk space on /var (percentage)：10 %
------------------------------------
报警时间:2015.10.07-09:56:24

这条报警邮件的信息已经很清楚了，是/var目录下的空间不足了，我们来看一看是怎么回事。
首先到目录下查看df -h的时候，空间剩余9%,说明这个空间还在不断的收缩中。
# df -h
Filesystem            Size Used Avail Use% Mounted on
/dev/sda3             7.8G 908M 6.5G 13% /
/dev/sda6             7.8G 6.7G 746M 91% /var
/dev/sda5             7.8G 2.0G 5.5G 27% /usr
/dev/sda1             122M   12M 104M 10% /boot
tmpfs                  48G   36K   48G   1% /dev/shm
/dev/shm               48G   36K   48G   1% /tmp
/dev/sda7             497G 391G   81G 83% /home
然后在/var/spool/clientmqueue下发现了大量的文件，绝大部分的空间消耗都在这儿。
随便拿出一条来看看到底是什么内容。发现是一个脚本在检查listener的日志。
# more dfs32Ct1KE012443
Start: 20140402205501
checking listener listener ...OK
checking listener listener_1525 ...OK
checking listener listener_1528 ...OK
checking listener listener_1523 ...OK
checking listener listener_1522 ...OK
End: 20140402205516
进一步进行验证，拿出最新的5个文件，查看文件内容也是如此。
clientmqueue]# ls -lrt|tail -5
-rw-rw---- 1 oracle smmsp   228 Oct 7 10:02 dft97221Lc010415
-rw-rw---- 1 oracle smmsp   919 Oct 7 10:03 qft97231cW026036
-rw-rw---- 1 oracle smmsp   228 Oct 7 10:03 dft97231cW026036
-rw-rw---- 1 oracle smmsp   919 Oct 7 10:04 qft97241rm007778
-rw-rw---- 1 oracle smmsp   228 Oct 7 10:04 dft97241rm007778
clientmqueue]# more dft97241rm007778
Start: 20151007100401
checking listener listener ...OK
checking listener listener_1525 ...OK
checking listener listener_1528 ...OK
checking listener listener_1523 ...OK
checking listener listener_1522 ...OK
End: 20151007100416
说明基本可以说明是因为检查listener的脚本产生了大量的日志文件。
因为这种日志文件对我们确实没有太多的用处，可以考虑删除，当然直接删除还是会报错误的，可以慢慢分批删除 ls|xargs -n 10 rm
删除后空间马上释放出来了。释放了近6G的文件。
# df -h
Filesystem            Size Used Avail Use% Mounted on
/dev/sda3             7.8G 908M 6.5G 13% /
/dev/sda6             7.8G 1.1G 6.4G 15% /var
/dev/sda5             7.8G 2.0G 5.5G 27% /usr
/dev/sda1             122M   12M 104M 10% /boot
tmpfs                  48G   36K   48G   1% /dev/shm
/dev/shm               48G   36K   48G   1% /tmp
/dev/sda7             497G 391G   81G 83% /home

问题现在解决了，我们来看看问题是怎么回事，对于crontab 中设置的job如果有输出内容，这些内容会以mail的形式发送给对应的cron job用户，如果这个时候sendmail没有启动就会在这个路径下产生这些日志文件。
首先抓取了最新的文件内容。可以看到文件生成的频率很高，几乎是每分钟一个文件。
clientmqueue]# ll
total 64
-rw-rw---- 1 oracle smmsp 228 Oct 7 10:08 dft97281ag005351
-rw-rw---- 1 oracle smmsp 228 Oct 7 10:09 dft97292uQ011260
-rw-rw---- 1 oracle smmsp 228 Oct 7 10:12 dft972C1Xg025752
-rw-rw---- 1 oracle smmsp 228 Oct 7 10:13 dft972D11d025507
-rw-rw---- 1 oracle smmsp 228 Oct 7 10:14 dft972E1IS008404
-rw-rw---- 1 oracle smmsp 228 Oct 7 10:15 dft972F1Oi023669
-rw-rw---- 1 oracle smmsp 228 Oct 7 10:16 dft972G1Xr006590
-rw-rw---- 1 oracle smmsp 228 Oct 7 10:17 dft972H1I8022068
-rw-rw---- 1 oracle smmsp 919 Oct 7 10:08 qft97281ag005351
-rw-rw---- 1 oracle smmsp 919 Oct 7 10:09 qft97292uQ011260
-rw-rw---- 1 oracle smmsp 919 Oct 7 10:12 qft972C1Xg025752
-rw-rw---- 1 oracle smmsp 919 Oct 7 10:13 qft972D11d025507
-rw-rw---- 1 oracle smmsp 919 Oct 7 10:14 qft972E1IS008404
-rw-rw---- 1 oracle smmsp 919 Oct 7 10:15 qft972F1Oi023669
-rw-rw---- 1 oracle smmsp 919 Oct 7 10:16 qft972G1Xr006590
-rw-rw---- 1 oracle smmsp 919 Oct 7 10:17 qft972H1I8022068
查看crontab -l可以看到，检查脚本执行的频率还是很高的。
2-9,12-29,31-59 * * * * . $HOME/.xxxxprofile;$HOME/dbadmin/scripts/lsnr_check.sh
对于listener的检查，其实不需要这么频繁的监控，可以适当把频率放慢一些，根据普遍的机器设置还是一个小时2次检查。比如这样设置：
9,39 * * * * . $HOME/.xxxxprofile;bash $HOME/dbadmin/scripts/lsnr_check.sh
日志文件清除了，日志文件的生成频率也降低了，但是问题还是指标没有治本。
对于这些检查日志，可以当做一个后台任务，不需要每次检查都生成大量的日志，一种方式就是直接屏蔽日志，比如设置为下面的形式。
9,39 * * * * . $HOME/.xxxxprofile;bash $HOME/dbadmin/scripts/lsnr_check.sh > /dev/null 2>&1
这样这个问题的解决就告一段落了，可见一个很细小的变化经过长年累月的积累就会成为一个明显的问题，监控中的设置频率过高反而可能有潜在的问题。

正文到此结束