디스크가 찼다는 말을 들었다. 무엇을 지워야 할지 아무도 몰랐다.
Table of contents
Open Table of contents
무엇이 차지하고 있는지 봤다
du -sh 로 디렉터리별 용량을 세니 /data 가 41기가였고 그 안에서 로그가 33기가였다.
2.1G /data/upload
5.4G /data/backup
33G /data/log열어 보니 catalina.out 하나가 18기가였다. Apache 액세스 로그도 여덟 달 전 것이 남아 있었다.
서버는 CentOS 5.5 였고 파티션이 하나였다. 로그가 / 를 채우면 Tomcat 만 멈추는 것이 아니라 MySQL 도 같이 멈춘다.
지워도 되는지 아무도 몰랐다
catalina.out 을 지워도 되느냐는 물음에 아무도 답을 못 했다. 언제까지 둬야 하는지 정한 적이 없기 때문이다.
정하지 않으면 아무도 못 지운다. 지웠다가 필요해지면 그 책임을 져야 하니 그냥 두게 되고, 그래서 계속 쌓인다.
무엇에 쓰는지로 정했다
각 파일이 무엇에 쓰이는지 물어서 표로 정리했다.
catalina.out 장애 조사에 쓴다 30일
Apache 액세스 로그 통계에 쓴다 90일
업로드 파일 서비스에 쓴다 지우지 않는다
MySQL 백업 복구에 쓴다 일 7 / 주 4 / 월 3
임시 파일 그날 처리에만 쓴다 1일장애 조사에 30일이면 되는지는 운영 담당에게 물어 답을 받았다. 내가 정할 것이 아니었다. 쓰는 쪽이 얼마나 거슬러 올라가는지를 알고 있다.
정하고 나니 지울 수 있게 됐다.
지우는 방법과 자동화
catalina.out 처럼 하나로 계속 쌓이는 파일은 일부만 지울 수 없다. 전부 지우거나 안 지우거나다. 먼저 logrotate 로 날짜별로 나뉘게 바꿨다. Apache 쪽은 CustomLog 가 한 파일로 몰아 쓰고 있었다.
지우려다 또 멈춘 지점이 있었다. Tomcat 이 그 파일을 열어 놓고 쓰는 중이라 rm 해도 디스크가 안 빈다. 프로세스가 파일 핸들을 놓을 때까지 자리를 차지한다. lsof | grep deleted 로 보면 나온다.
$ cp /data/log/catalina.out /data/log/catalina.out.20111103
$ : > /data/log/catalina.out지우는 대신 내용을 비웠다. logrotate 의 copytruncate 가 이 방식이다. Tomcat 은 신호를 받아 파일을 다시 열지 못해서 이 옵션이 필요하다.
손으로 하면 다시 차니 /etc/logrotate.d/tomcat 에 설정을 두었다. CentOS 는 /etc/cron.daily/logrotate 로 매일 돌리게 돼 있어서 crontab 에 따로 넣을 것이 없었다. 오래된 백업은 find 로 지우게 crontab 에 걸었다. find 에 -delete 를 붙이기 전에 목록만 먼저 뽑아 봤다. 조건이 잘못되면 필요한 것이 지워지기 때문에 눈으로 보고 나서 붙였다.
마지막으로 df 사용률이 80퍼센트를 넘으면 메일이 오게 했다. 찬 뒤에 아는 것과 차기 전에 아는 것은 다르다. 찬 뒤에는 서비스가 이미 멈춰 있다.
정리
- 지워도 되는지 아무도 모르면 정한 적이 없는 것이고 그래서 계속 쌓인다
- 무엇에 쓰는지로 보존 기간을 정한다
- 기간을 정하는 것은 내가 아니라 그것을 쓰는 쪽이다
- 하나로 쌓이는 파일은 일부만 못 지우니 날짜별로 나뉘게 먼저 바꾼다
- 프로세스가 쓰는 중인 파일은
rm해도 자리가 안 빈다 - 그럴 때는 지우지 말고 비운다. logrotate 의
copytruncate가 그 방식이다 - 손으로 지우면 다시 찬다.
/etc/logrotate.d에 두고 자동으로 돌린다 - 지우는 명령을 붙이기 전에 목록만 먼저 뽑아 눈으로 본다
- 찬 뒤가 아니라 차기 전에 알려 주게 한다