답변:
다음 logrotate과 같은 구성을 사용하여을 통해 먼저 회전하십시오 .
/path/to/the/log {
missingok
notifempty
sharedscripts
daily
rotate 7
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
compress
}
그런 다음 자정에 크론 작업을 만들어 회전 된 파일을 삭제하십시오.
30 2 * * * nice -n 19 ionice -c2 -n7 rm -f /path/to/the/log/file.1
큰 파일을 빠르게 삭제하려면 truncate-명령을 사용하여 크기를 0으로 줄인 다음 삭제하십시오.
truncate -s 0 monthly.log && rm -f monthly.log
퀀 타가 권장하는 것처럼 먼저 로그 로테이션해야합니다.
truncate와는 어떻게 다른 >가요?
truncate함께 사용하기 쉽습니다 sudo보다 >. 또한 더 쉽습니다 find -exec.
: > /path/to/monthly.log작업으로 파일을 자르거나 제로화합니다 . 그런 다음 Apache 프로세스를 다시 시작하고 향후에 이런 일이 발생하지 않도록 로그 회전을 설정하십시오 ...
그러나 이것은 종종 발생합니다.
참조 : IO /로드를 중단하지 않고 Linux에서 100GB 파일을 삭제하는 방법이 있습니까?
:. 당신은 그냥 할 수 있습니다> /path/to/monthly.log
noop있지만 교육 관점에서 더 의미가 있습니다.
true > /path/to/monthly.log같은 일을하고, 그 다음에 덜 구식이다 :?
데이터가 필요하지 않은 경우 / dev / null을 사용하여 자릅니다.
cat /dev/null > monthly.log
웹 서버는 잘린 후에도 파일에 데이터를 계속 기록하므로 파일 rm monthly.log을 제거하는 (와 달리 ) 웹 서버를 다시 시작할 필요가 없습니다 .
즉각적인 위기를 해결 한 후 Quanta가 제안한대로 로그 로테이션을 고려하십시오. 이런 일이 다시 일어나길 원하지 않습니다. Apache 로그 파일은 CentOS에서 기본적으로 이미 회전되어 있습니다.
syslog를 통해 웹 로그를 보내는 것도 고려하십시오 ( /usr/bin/logger예 :) . syslog를 사용하여 생성 된 로그에는 일반적으로 이미 로그 로테이션이 설정되어 있습니다.
>logfile고양이에 대한 필요
ext3 파일 시스템을 사용하는 경우 ext4로 전환하십시오.
Ext3은 모든 개별 4k 블록의 위치를 저장하기 때문에 대용량 파일을 삭제하는 데 시간이 오래 걸릴 수 있습니다. 파일 내용이 디스크에서 어디에 있는지 추적하기 위해 총 50MiB의 부기 데이터가 있습니다. 이 큰 블록 목록은 많은 간접 블록에 흩어져있을 수 있으며 파일을 삭제할 때 모두 업데이트해야합니다. 이러한 모든 간접 블록에 액세스하려는 디스크는 아마도 지연의 원인 일 수 있습니다.
반면 Ext4는 최대 128MiB의 "extents"에 파일을 할당합니다. 이 50GiB 파일은 13107200 개별 블록 번호가 아닌 400 개의 익스텐트 레코드를 사용하여 inode 테이블에 기록 할 수 있으므로 파일을 삭제할 때 필요한 디스크 I / O의 양이 크게 줄어 듭니다.
기존 ext3 파일 시스템을 대신하여 ext4로 변환하면 새 파일이 범위를 사용하여 할당되지만 기존 파일은 여전히 차단 목록을 사용합니다. chattr +e명령을 사용하여 범위를 사용하여 기존 파일을 재 할당 할 수 있습니다 . 성능 측면에서 이것은 파일을 복사 한 다음 원본을 삭제하는 것과 비슷합니다.
문제는 아파치 웹 서버 사용자보다 디스크 작업보다 우선 순위가 높은 권한있는 사용자로부터 파일을 삭제한다고 가정합니다. 로그 파일을 삭제하도록 선택한 방법 (rm -f 또는 truncate by>)에 관계없이 디스크 우선 순위 작업을 최소로 낮춰야합니다.
ionice -c3 rm -f filename.log