--//生产系统昨天出现/u01磁盘空间不足的情况,清理出40g磁盘空间后,检查日志应用同事发现有点慢,主要这台机器还运行ogg.
--//感觉有点慢是正常的.另外检查发现存在大量logrotate进程以及后续awk命令进程.会不会是这些进程导致的缓慢.
--//我先清除这些进程.
service crond stop
ps -ef | grep logrotate
pkill -9 logrotate
pkill -9 awk
service crond start
--//看看我写的logrotate配置:
cat /etc/logrotate.d/oracle
/u01/app/oracle/diag/tnslsnr/dbcndg2/listener/trace/listener.log {
weekly
rotate 5
copytruncate
compress
notifempty
missingok}
/u01/app/oracle/admin/dbcndg2/adump/dbcndg2_ora_*.aud
{
monthly
rotate 0
notifempty
missingok
maxage 32
postrotate
find /u01/app/oracle/admin/dbcndg2/adump/ -name "dbcndg_ora_*.aud" -size 0 -exec rm {} \+
endscript}
--//我一下子没想明白为什么我要执行find ... -size 0 这样的操作.
--//看以前的工作笔记,其实开始并没有postrotate..www.pizei.com.endscript,我才突然想明白以前也出现类似磁盘满这样的情况下.
--//这样就会出现大量size=0 的aud文件,估计当时就是为了这样的情况设计的,清除size=0的aud文件.
--//为什么慢呢? 实际上这个问题我以前遇到过,管理的机器实在太多,遗漏一些机器要改.只不过当时仅仅做了记录,并没有发表出来.
--//11g下改变了aud的文件命名格式加入时间戳,这样每个生成的文件是唯一的,这样logrotate的state file(缺省是
--///var/lib/logrotate.status)会越滚越大.这样每次执行越来越慢.10g下没有时间戳,也就是最大65XXX个文件(虽然可能也很慢,但至
--//少这是一个定数,另外好像最大进程号linux现在也可以修改,可以设置更大不止65XXX,我没有这方面的经验以及测试).
--//检查 /var/lib/logrotate.status已经达到129M.清除文件.
>| /var/lib/logrotate.status
--//另外检查:
ls -ltrh
total 108M
drwxr-xr-x 2 oracle oinstall 4.0K 2015-03-16 17:34:35 dpdump
drwxr-xr-x 2 oracle oinstall 4.0K 2015-03-16 17:34:43 hdump
drwxr-xr-x 2 oracle oinstall 4.0K 2015-03-16 17:34:49 pfile
drwxr-xr-x 2 oracle oinstall 107M 2021-06-22 10:14:06 adump
--//看看adump页游的目录大小107M,就知道即使清除了/var/lib/logrotate.status文件,也是不可能完成的操作.
--//如果你使用如下命令调试也可以发现执行很慢.
logrotate -dv /etc/logrotate.d/oracle
--//为什么adump目录占用空间这个大呢?
$ mv adump adump.xxx
$ mkdir adump
$ cd adump
--//等上一小会,发现每分钟基本发起10个连接.我估计不知道那个变态公司开发的无聊的监测软件.我感觉对方的开发不会写程序,
--//完全可以连上不断开连接,每次执行语句前监测连接是否正常就ok了.
--//这样admup目录达到这个数量级别就很正常了.
--//1个月产生 246010*30 = 432000个文件.
--// 10710241024/432000 = 259.71,每个文件在目录占用25X字节?,不熟悉也没有看过linux的目录结构.先放一下.
--//也就是我不能再使用logrotate清除oracle aud文件的方式来维护数据库aud日志,要么使用find+cron的方式,要么使用链接
-
--//我有一些服务器已经采用find+cron方式,有机会再整理把,先注解如下内容: