诡异的磁盘空间100%报警分析得出df -h与du -sh的根本性差别

诡异的 df -h 磁盘空间100%报警分析,如果没有大文件,很可能是后台部分程序造成,停掉程序就好了,如果磁盘空间是100%,很多操作会受到影响,包括添加用户,修改用户密码,修改crontab,vi编辑文件等

前言:
早晨磁盘报警刚清空完tomcat和nginx日志,使用的命令是类似echo “” > show_web-error.log或者> show_web-debug.log清空语句,然后rm -rf 掉一些tar.gz包,空出来30G空间。而且也关闭了tomcat的debug信息。刚刚又接到报警,磁盘100%了。怎么回事?

1,进去df -h下,确实100%了,如下所示:
[root@localhost ~]# df -h
文件系统              容量  已用 可用 已用% 挂载点
/dev/mapper/VolGroup00-LogVol00
113G  113G     0 100% /
/dev/sda1              99M   13M   82M  14% /boot
tmpfs                 8.8G     0  8.8G   0% /dev/shm
确实已经100%了,再去/去检查

2,去/根目录check,du -sh *
[root@localhost ~]# cd /
[root@localhost /]# du -sh *
7.8M bin
6.9M boot
131M data
196K dev
111M etc
178M home
131M lib
23M lib64
119M logs
16K lost+found
8.0K media
0 misc
8.0K mnt
0 net
0 nohup.out
3.8G opt
15M pcre-8.33
2.1M pcre-8.33.zip
du: 无法访问 “proc/11575/task/11575/fd/1565”: 没有那个文件或目录
du: 无法访问 “proc/15403/task/14464/fd/625”: 没有那个文件或目录
0 proc
1.4G product
153M repo
143M root
37M sbin
8.0K selinux
363M soft
8.0K srv
0 sys
20K temp
100K tftpboot
2.1G tmp
8.6G usr
184M var
30M varnish-3.0.3
56M zabbix-2.0.8
[root@localhost /]#
看到,占据的磁盘空间所有的加起来也不到30G,可是df -h下来,确实100%呢?差异在哪里?

3,baidu,google资料,找到 http://www.chinaunix.net/old_jh/6/465673.html 里面有这么2段话:
(1):
When you open a file, you get a pointer.  Subsequent writes to this file
references this file pointer.  The write call does not check to see if the file
is there or not.  It just writes to the specified number of characters starting
at a predetermined location.  Regardless of whether the file exist or not, disk
blocks are used by the write operation.

The df command reports the number of disk blocks used while du goes through the
file structure and and reports the number of blocks used by each directory.  As
far as du is concerned, the file used by the process does not exist, so it does
not report blocks used by this phantom file.  But df keeps track of disk blocks
used, and it reports the blocks used by this phantom file.
以及leolein朋友的回复:
谢谢,就是这个原因。
我因为磁盘快满了就删除了一些过期的文件,可能应用程序还在使用这些文件句柄,所以导致了我说的问题。
我把所有的应用程序都停止后,du和df的结果就大致相同了

(2):
This section gives the technical explanation of why du and df sometimes report
different totals of disk space usage.

When a program that is running in the background writes to a file while the
process is running, the file to which this process is writing is deleted.
Running df and du shows a discrepancy in the amount of disk space usage.  The
df command shows a higher value.

如果文件已经删除了,但是还有残留的进程引用它(具体不知道怎么表达好),则df看到的空间使用量并没有减去那些已经删除的文件。而创建并写入一个文件是,判断空间是否足够是依据df(本人认为),所以df 100%的时候就不能写入文件了。–但是创建文件是可以的,我做过测试。查看这些残留进程(姑且这么称呼,我也不知道那些进程叫什么)的方法是lsof
# lsof /home | grep /home/oracle/osinfo | sort +8 | grep ‘^.*070920.*$’
sadc    17821   root    3w   REG  253,1 326492112 926724 /home/oracle/osinfo/070920sar.data (deleted)
sadc    17861   root    3u   REG  253,1 326492112 926724 /home/oracle/osinfo/070920sar.data (deleted)
sadc    17981   root    3u   REG  253,1 326492112 926724 /home/oracle/osinfo/070920sar.data (deleted)
top     17858   root    1w   REG  253,1 169919916 927111 /home/oracle/osinfo/070920top.data (deleted)
top     17977   root    1w   REG  253,1 169919916 927111 /home/oracle/osinfo/070920top.data (deleted)
注意后面的deleted
然后把这些进程都kill掉就可以释放空间了。

我想起了,我早晨在执行echo “” >shop_web.log类似操作的时候,并没有停止tomcat应用,所以应用是一直往log里面写数据的,那么我>的那一刻,是du -sh *可能看到磁盘空间有了,df -h也可以看到磁盘释放了,但是当tomcat应用继续往shop_web.log里面写日志的时候,加载的还是最初打开的那个执行>shop_web.log之前的占据很大磁盘空间的缓存文件。所以磁盘其实一直没有释放掉,而能坚持一天不报警,是由于我rm了一些tar.gz包所释放的空间。

4,重启tomcat和nginx应用
所以,我应该重启tomcat和nginx,应用不再加载旧的缓存文件,执行重启tomcat命令,由于tomcat应用比较多,所以写了一个脚本来执行
[root@localhost local]# cat /root/start_tomcat_port.sh
#!/bin/bash
PID=`ps -eaf|grep apache-tomcat-6.0.37_$1 |grep -v grep |grep -v start_tomcat_port |awk ‘{print $2}’`
echo $1
echo $PID
kill -9 $PID
rm -rf /var/tomcat/$1.pid
/usr/local/apache-tomcat-6.0.37_$1/bin/startup.sh
[root@localhost local]#
执行重启tomcat:
sh /root/start_tomcat_port.sh 6100;
sh /root/start_tomcat_port.sh 6200;
sh /root/start_tomcat_port.sh 6300;
sh /root/start_tomcat_port.sh 6400;
sh /root/start_tomcat_port.sh 6500;
sh /root/start_tomcat_port.sh 6700;
sh /root/start_tomcat_port.sh 7100;
sh /root/start_tomcat_port.sh 7200;
sh /root/start_tomcat_port.sh 7300;
执行重启nginx:
service nginx restart

5,再去check下磁盘空间
[root@localhost local]# df -h
文件系统              容量  已用 可用 已用% 挂载点
/dev/mapper/VolGroup00-LogVol00
113G   18G   90G  17% /
/dev/sda1              99M   13M   82M  14% /boot
tmpfs                 8.8G     0  8.8G   0% /dev/shm
[root@localhost local]#

看到df -h命令正常了,已经释放了90G的磁盘空间,现在磁盘使用率才17%,nagios报警解除了。

6,汇总一些原理分析
实现原理:
du -s命令通过将指定文件系统中所有的目录、符号链接和文件使用的块数累加得到该文件系统使用的总块数;
df命令通过查看文件系统磁盘块分配图得出总块数与剩余块数。
du是用户级程序,不考虑Meta Data(系统为自身分配的一些磁盘块)

ps:应用程序打开的文件句柄没有关闭的话,会造成df命令显示的剩余磁盘空间少。而du则不会。
例子:
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>

int main(int argc,char **argv)
{
if(open(“tempfile”,O_RDWR) < 0){
fprintf(stderr,”open error”);
exit(-1);
}

if(unlink(“tempfile”) < 0){
fprintf(stderr,”unlink error”);
exit(-1);
}

printf(“file unlinked\n”);
sleep(15);
printf(“done\n”);
exit(0);
}

文章来源:http://blog.csdn.net/mchdba/article/details/38305081

京东金融趣闻

据小道消息,2017年04月10日,京东金融来了一群不俗之客,定眼望去,各种明星大咖。

据小道消息,2017年04月10日,京东金融来了一群不俗之客,定眼望去,各种明星大咖。

此次行动非常神秘,各大媒体查询不到一丁点相关消息的报道。

一般情况下,企业请明星来,无非为了为公司产品找代言人,从而增加公司产品曝光率和可信赖度。可此次京东金融在请来各种大咖的情况下,现场竟然没有看到一家媒体记者的出现。

根据新进八卦人士 二皮 的敏锐观察,这是相当反常的事情,内部一定有不可告人的秘密。为了一探究竟,二皮暗地联系了在京东内部工作的线人进行询问。果然发现了惊天大秘。。。

原来京东金融技术部门有一个长相又帅,能力又高的保定农村的帅小伙,是在京东金融做java开发的,这么多明星大咖齐聚,其实就是为了一睹其芳容。。。

那么,这个神秘的帅小哥是谁呢,经过多方采访取证,原来是2012年毕业于邯郸大学的名字叫王建的一个帅哥,据可靠消息,该帅哥至今还是单身一个人哦,有意向的妹子抓紧了,机不可失,失不再来!!!

 

 

以上内容纯属瞎编,如有雷同,纯属巧合^_^!

描述字段超过限制

微信群发接口发送失败,错误码:45004,错误内容:description size out of limit,最快最方便的解决办法,请这里看过来!

每天正常调用的微信群发接口,突然发现当天图文消息没有群发成功,查看微信返回状态码为 45004,说明 description size out of limit,看字面意思,是文章说明超限制了。。。

人家既然有限制了,咱就改呗。可是该怎么改,改成多少长度合适呢,不知道直接看微信接口文档。。。

上接口文档里查,状态码只给出了说明:“描述字段超过限制”。根据提示“description size out of limit”,应该是说“description”这个字段的,赶紧去找这个字段,修改长度。可是,把代码认认真真,仔仔细细的看了一遍,也没有这个参数啊。。。

还是啃官方接口文档去,认真看一遍,原来“description”,在接口里面是用的“digest”这个键,是用来放文章摘要的,好那就为这个值做下处理好了。。。

再次查阅文档,尼玛,光说超限,竟然没给出具体限制是多少!这坑货,也没谁了。。。这让人怎么改,随便写个数,想想还要用测试号去一遍一遍测试,也是够了。。。

干脆,哥直接把“digest”赋空,空了总不超限了吧。测试发现消息发送成功。。。

如果您了解微信接口对文章摘要的长度限制,热烈欢迎答疑解惑

不知道取消了微信接口的文章摘要,对SEO方面有没有影响,后期会研究出微信对文章摘要的具体限制长度的

js文件被浏览器缓存的思考

网上找的关于js缓存的问题,由于大多数用户不知道 Ctrl + F5,这一对web开发者来说就像吃饭一样的快捷键,所以感觉这篇文章还是很有可借鉴性的。类似的所有静态资源,其实都可以采用这种方式啊。。。。

js文件被浏览器缓存的思考

我们的用户量大,修改js文件后,用户反馈登录出现问题。实际上刷新一下就没事了。就是因为用户的浏览器使用的还是本地缓存的js代码。

强制刷新一般就会重新去服务器获取新的js代码。但不能让用户每次都这样子去做。

于是我思考一个问题:

如果修改了js文件中的js代码,发布代码到线上后。用户的浏览器使用的还是原来js缓存。所以并不会马上生效。

如何才能让浏览器使用最新的js文件呢?

很多人想到的第一反应是,在在后面加一个时间戳来解决。这样url地址每次变化,浏览器就会请求服务端的js,而不会使用缓存。 这样是解决了。但是会导致浏览器每次都要去请求服务端的js文件。占用带宽。作为技术,能不能有种更好的办法呢?既能避免用户的浏览器每次去请求服务端获取js文件。又能在发布新的js代码后,能够使用最新的js文件? 据说,在问号后面加版本号,现在很多网站都这么干。加个版本号能够解决问题吗? 加个版本号,js有个版本。如果每次发布新的js代码。后面就会附加新的版本号。然后用户加载html页面的时候。版本号附加在在

如果没有修改,那么版本号还是原来的,这样做到了:不发布代码的时候,浏览器使用的是本地缓存。因为版本号没有变化。

现在疑问是,js的版本号如何生成呢?

生成一个日期吗?

当天的日期比较好。

这样的确解决了问题。让用户可以使用。

只不过出现一个新的问题来临了。

js文件加上当天的发布日期作为版本号即可了。

有些人针对url后面带时间戳的做法,会导致浏览器每次请求都不会缓存,因为每次请求时间都会变化,url就变化了,于是浏览器认为是一个新的地址了。

有人针对这个问题的解决办法是:这里URI不是静态,可能会造成某些浏览器不会进行缓存,可以采用伪静态配合URL重写来解决

网上查询资料,纵观大家的解决思路总结如下:

1、修改js的文件名。我觉得这样很麻烦。造成版本系统的维护困难。不建议。除非是完全ftp。不过每次发布都修改文件名称。的确造成维护的时候很茫然,接手的人看到文件名称变化,会比较难维护

2、路径后面加时间戳或者随机数的方式。

一般都是在html模版中使用一个时间戳或者随机数函数生成一个值。

今天和明天的值不同了,重新请求服务器。使用时间戳,每刷新一次html,值都不同。随机数也是一样的

不推荐使用这种方式。

因为这样的方式导致的问题是,每次刷新html,时间戳都是变化的,url就总是唯一的,于是浏览器总是去请求服务端获取js文件,不会使用浏览器本地的缓存。占用带宽,影响速度

3、路径后面加js的版本号。这样是业界比较成熟的做法。

关键是这个版本号,怎么做版本? 难道真的纳入版本系统里面去?不是的。我突然灵感来,想到一种程序员自己控制的办法。

自己主动加时间,如果本次发布,修改了哪几个js文件。那么就在后面加上一个时间点:年月日

如果一天会发布多次对js文件的修改,那么程序员还要精确点。年月日时分秒即可。

如下:

我去看了一下淘宝,发现也是这样一种方式额,不知道对不对? 如下: 15年8月12日补充: 公司有好几千万注册会员,于是第三方应用使用我们网站会员帐号实现在第三方网站登录,需要设计oauth2.0授权的平台,于是需要参考微博的oauth体制。 无意中发现他们的css也是使用年月日来控制 进一步思考: 这种加时间方法是可行。。不是系统生成的时间,不是所有js文件都加。 是不是可以进一步考虑一种办法,用程序来进行开关呢? 自己勾选。如果这个文件修改了。那么就设置为更新。模版中判断,就根据这个开关,把时间戳自动打上去? 不过这样子觉得没必要。因为还没到那么重大。其实初期,完全可以程序手动把日期打上去即可了。 该了什么js文件,就给哪个js文件加,这样已经是折衷了。就跟改代码一样。代码都要修改的,这点改也没多少工作量。 总结思路: js文件的内容修改了,可以加个t参数表明一下日期,用这个日期来作为版本号,看到日期也能知道是哪天发布的。 没有修改js文件根本就不用修改日期。 实践:

如果下一次修改了这个js文件,那么发布的时候,就修改日期

没有修改的js文件,保留原来的值不动即可。

文章来源:http://www.cnblogs.com/wangtao_20/p/4589898.html