@lupnfer
2017-03-20T11:24:44.000000Z
字数 1860
阅读 1264
Debug
在Linux服务器上经常使用iostat和iotop命令来收集服务器IO信息,使用top命令收集CPU和内存使用信息,我们知道这3个命令是实时监控服务器IO,CPU,内存能信息的,即执行一次命令会不停的刷新信息,除非使用【Ctrl】+【C】来停止,当出现问题时使用这3个命令可以很快的定位出哪个程序占用的IO,CPU,内存较高,但是当问题出现在凌晨之后我们很少有热情精力在这个时间点来定位收集信息,但是这3个命令又不支持查询历史信息(虽然sar命令可以查询前一天的IO,CPU等非常多的信息,但是它没有提供程序信息),直接使用又不支持输出重定向功能,但是他们可以限制刷新次数,比如限制刷新1次,刷新1次之后命令自动停止,可将这一次的刷新重定向至文件中。使用这些小技巧加上定时任务就可以将问题出现前后的IO,CPU,内存保存在日志文件中,这样就不用熬夜担心错失凶案现场的信息了。
使用这种方式收集信息必须要注意不要让日志文件把服务器硬盘空间占满了,尤其是iotop会统计每一个程序的信息,尤其在DB9500服务器收集一次就会生成一个3M的文件,所以可以收集前10个IO较高的程序信息(先把iotop重定向一个临时文件,然后使用sed命令将前10行再次重定向至日志文件),这样可以避免日志文件过大的问题。
iotop -t -n 1
执行一次iotop命令,-t是打印时间点,-n 1即刷新一次即停止iotop命令
iostat -x 1 2
执行一次iostat命令,-x打印更详细的信息,1表示1秒刷新1次,2表示刷新2次即停止iostat命令。
iostat命令第一条的结果是不准确的,每次执行第一条的结果都是相同的,所以要想收集到正确的iostat信息必须要多刷新几次。
top -n 1
执行一次top命令,-n 1表示刷新1次即停止top命令。
下面是收集某局点DB9500信息的脚本,问题出现在00:00:00至00:30:00,所以我们打算收集23:30:00至00:30:00的相关信息和数据库日志
#!/bin/sh
LOGDIR=/var/log/collect
mkdir -p ${LOGDIR}
##打开数据库日志
sed -i /"log_min_duration_statement = "/c\ "log_min_duration_statement = 0" /bigdata/pgsql/data/postgresql.conf
service postgresql reload
for i in {1..1800}
do
iotop -t -n 1 > ${LOGDIR}/iotop_tmp.log 2>&1
sed '1,10p' -n ${LOGDIR}/iotop_tmp.log >>${LOGDIR}/iotop.txt 2>&1
###iostat命令打印的第一条永远是相同的,不准确的,所以要多打印几条
iostat -x 1 2 >> ${LOGDIR}/iostat.log 2>&1
top -n 1 >> ${LOGDIR}/top.log 2>&1
done
sar -A > ${LOGDIR}/sar.log 2>&1
##关闭数据库日志
sed -i /"log_min_duration_statement = 0"/c\ "log_min_duration_statement = -1" /bigdata/pgsql/data/postgresql.conf
service postgresql reload
sed -e '/collect.sh/d' -i /etc/crontab
service crond restart
在DB9500服务器上部署
1.将collect.sh拷贝至/bigdata/目录下,并修改权限
chmod 755 /bigdata/collect.sh
2.设置定时任务(信息收集完成后会自动将定时任务删除)
在/etc/crontab文件末尾增加一行
30 23 * * * root /bigdata/collect.sh
并执行命令
service crond restart
这样就完成部署,信息收集保存在/var/log/collect目录下。
并执行如下命名,确认结果和如下一致
[root]# grep 'log_min_duration_statement' /bigdata/pgsql/data/postgresql.conf
log_min_duration_statement = -1------------------------------------------该项配置必须为-1