--//生产零碎昨天呈现/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 {
weeklyrotate 5copytruncatecompressnotifemptymissingok}
/u01/app/oracle/admin/dbcndg2/adump/dbcndg2_ora_*.aud
{
monthlyrotate 0notifemptymissingokmaxage 32postrotate 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形式,有机会再整顿把,先注解如下内容: