출처 : http://faq.hostway.co.kr/?mid=Linux_ETC&page=9&document_srl=1423

관리자가 없어 자주 확인을 하지 않는 서버들의 경우는 홈페이지가 열리지 않는 경우 
하드웨어 장애가 아닐 경우에 상당수 많은 부분을 차지 하는 것이 파티션 사이즈가 100% 가 되면서 문제가 발생되곤 합니다.

이 경우 근본적인 해결책은 로그를 logrotate와 같은 형태로 분할 진행할 수 있겠지만, 
급한대로 로그를 비워야할 때 어떻게 해야 할지 모르는 경우가 있다.

 

1. Log file은 apache, mysql, 등 어플리케이션 설정내에서 경로가 지정되어 있기 때문에, 삭제 하

    게 되면 오류가 발생 하게 됩니다.
   아래와 같이 /usr 혹은 /var 파티션이 100%가 되는 경우가 상당 수 발생.

   [root@hostway /]# df -Th
   Filesystem    Type    Size  Used Avail Use% Mounted on
   /dev/sda1     ext3    1.9G  826M  963M  47% /
   /dev/sda6     ext3    950M   19M  884M   3% /tmp
   /dev/sda3     ext3    4.6G  485M  3.9G  11% /var
   /dev/sda2     ext3    9.2G  9.2G  0G  100% /usr
   /dev/sda7     ext3     92G   64G   24G  74% /home
   /dev/sda8     ext3    118G   93G   20G  83% /data

2. 이 경우 어떤 파일 혹은 디렉토리가 큰 용량을 차지하고 있는지 확인이 필요 합니다.

 

   방법 1) du 명령을 통해 용량이 큰 디렉토리 및 파일 확인


   [root@hostway ~]# cd /usr


   [root@hostway usr]# du -sh *
   578M    lib
   55M     libexec
   7.2G    local
   16K     lost+found
   
   [root@hostway usr]# cd local

   [root@hostway local]# du -sh *


  위와 같은 형태로 찾아 찾아 들어가는 형태로 파일이 커진 파일을 확인 할 수 있습니다.


   방법 2) find를 이용해 /usr 디렉토리 밑에 200M 이상 파일들 찾는 방법 예시
 
   [root@hostway usr]# find /usr -size +200000 -print

   위 방법들로 파일 사이즈가 큰 것들을 찾을 수 있습니다.

 

3. 보통 문제가 되는 파일들은 /usr/local/apache2/logs/~~  경로와 같이 웹 로그 파일들이 쌓이는

   부분에서 문제가 발생 합니다.
   예를 들어 /usr/local/apache2/logs/access.log 파일의 크기가 3.5G나 되는 경우 로그를 여는데도

   상당 수 시간이 소요되며, 서버의 부하가 발생 합니다.
   이 경우 로그가 꼭 필요하다면, 여유가 있는 다른 파티션으로 이동 후 비워주는 작업을 해주셔야

   합니다.

   아래 명령을 수행 하게 되면 null (0) 값으로 access.log를 채우게 되면서 결과적으로는 사이즈가 
   0이 되어지고 파일은 남아있습니다.

   [root@hostway usr]# cat /dev/null > /usr/local/apache2/logs/access.log   

   /usr 파티션에는 아래와 같이 3.5G 여유공간이 생깁니다.


   [root@hostway /]# df -Th
   Filesystem    Type    Size  Used Avail Use% Mounted on
   /dev/sda1     ext3    1.9G  826M  963M  47% /
   /dev/sda6     ext3    950M   19M  884M   3% /tmp
   /dev/sda3     ext3    4.6G  485M  3.9G  11% /var
   /dev/sda2     ext3    9.2G  5.7G  3.5G  70% /usr
   /dev/sda7     ext3     92G   64G   24G  74% /home
   /dev/sda8     ext3    118G   93G   20G  83% /data

 

   위와 같은 원인이 발생하는 이유는 공간부족으로 인해 데몬이 구동하기 위해 필요한 pid 파일이

   생성되지 못하기 때문입니다.


  - Mysql의 bin log 같은 경우엔 주의가 필요로 합니다.
    제일 마지막 번호의 log 인 즉 데몬이 쿼리를 쌓고 있는 파일은 비우시면 안됩니다.


===========================================================================================

2>/dev/null 의미란??

출처 : http://shakii.tistory.com/94

오늘 해커스쿨 운동장(?)에서 놀다 보니 2>/dev/null 관련된 문제가 있었다

   

일단 문제는 역시 내 수준하고는..... 너무 어려워 ㅜㅜ

   

암튼 그래서 먼저 풀어 보신분들의 해답(?)등을 참고 하다보니 위에 같은 명령어가 나오길래...

   

/dev/null 알겠는데...

   

1>/dev/null

2>/dev/null

   

은 처음 보는거라 생소 했다.. 그래서 네이버에게 물어보니 이러한 답변이...

   

A.

   

B.

   

C.

   

일단 A와 B은 같은 의미

   

그럼 B와 C의 차이는 뭐냐

   

1의 의미는 STDOUT(standard output)

2의 의미는 STRERR(standard error)

   

STDOUT은 표준출력으로, 정상적인 메시지를 출력하고

STDERR은 표준에러로, 에러메시지를 출력하는것이다

   

다시 말해

B는 표준출력을 /dev/null로 redirection하고 (정상적인 메시지를 null로)

C는 표준에러를 /dev/null로 redirection 한다 (에러메시지를 null로)

   

정상적인 메시지는 안보인다

   

위와 다르게 Permission denied인 에러메시지들은 안보인다

   

   

표준출력, 표준에러 그리고 표준입력도 있는데 이것을 리눅에서는 "파일"이라고 부른다.

   

   



PS: /dev/null 자체를 모르시는 분도 계실듯..

나는 이것을 쉽게 생각해서 "블랙홀"이라고 배웠다

이파일에 쓰는 모든것은 영원히 사라진다는것으로 아무것도 아닌(null) 장치파일이라고 볼수 있다(?)

어떠한 작업의 출력되는 내용을 보고 싶지 않을때, 이곳으로 그 출력을 보내버리면,

아무것도 보여지지 않게 되는것이다. 이럴때 아주 유용하게 쓰이게 된다

파일을 지울때는 rm 명령어로 지우면 되겠지만 텍스트로 이루어진 로그파일이라도

그 로그파일이 시스템에서 사용중일수 있다 그러면 삭제하는것은 위험 하기 때문에

그럴때

"/dev/null > 로그파일.log"

위와 같이 해주면 로그파일의 속(?)을 비워주게 되는것이다.



+ Recent posts