이 글은 리눅스 서버의 용량 정리후 df로 확인할때 실제용량이 줄어들지 않는경우 참고용으로 작성한 글입니다.
글의 내용을 참고하여 작업 중 발생한 사항에 대해서는 스마일서브 및 작성자에게 책임을 물을 수없습니다.
|
[root@localhost log]# df -Th |
서버의 용량을 확인했을때 용량이 정말 아슬아슬하게 남았었습니다.
저는 실제로 저 서버에 그렇게 많은 용량을 사용하지 않았는데요. 우선 어디서 용량을 많이
사용되는지 알아보기로 했습니다.
|
[root@localhost log]# du -shc * |
/dev/sda1의 / 쪽에서 du 명령어를 사용후 확인해보니 var에서 20GB의 데이터가 사용되고 있었고 자세히 보니
log 부분의 messages에 10GB 이상의 용량이 사용되고 있음을 확인할수 있었습니다.
우선 급히 용량 확보를 위해 messages를 삭제하고 몇시간 뒤에 서버를 보게되었는데. 용량이 그대로였습니다.
실제용량은 줄어들지 않은것이었죠
|
[root@localhost log]# ps -ef |grep messages root 740 1 0 Feb22 ? 00:09:47 /usr/bin/abrt-watch-log -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locking detected ernel BUG at list_del corruption list_add corruption do_IRQ: stack overflow: ear stack overflow (cur: eneral protection fault nable to handle kernel ouble fault: RTNL: assertion failed eek! page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl table check failed : nobody cared IRQ handler type mismatch Machine Check Exception: Machine check events logged divide error: bounds: coprocessor segment overrun: invalid TSS: segment not present: invalid opcode: alignment check: stack segment: fpu exception: simd exception: iret exception: /var/log/messages — /usr/bin/abrt-dump-oops -xtD |
ps -ef 명령어로 삭제했던 파일에 대한 프로세스가 동작하고 있는지 확인을 해본 후 . 이 부분을 kill -9로 PID값을 제거하여
처리해 볼까했지만 messages에 로그가 쌓이지 않는점을 확인하고 아래의 명령어를 실행했습니다.
|
[root@localhost log]# service rsyslog restart |
로그 서비스를 재시작하고 용량을 확인하니 정상적으로 표기되는점이 확인되었습니다.
조금 중구난방하게 적어놨지만 경험상 저런 케이스를 해결할 방법을 정리하면 아래와 같습니다.
1. 리부팅.
– 용량을 비웠지만 확인했을때 변화가 없다면 리부팅 하는방법도 있긴한데 안될 가능성도 있습니다.
왠만하면 이 방법은 해볼건 다 해보고 안되면 하는게 좋습니다.
2. ps -ef |grep 프로세스명 을 이용한후 kill -9로 PID값을 제거합니다.
– 다만 이걸 한후에 관련된 서비스가 정상적으로 돌아가는지 확인해야합니다.
3. 용량을 비울때의 파일이 실제 동작하고 있는 프로세스에 연관이 되어있을때 프로세스에 관련된 서비스를 재시작합니다.