지난번에 삼바 서버(ubuntu 8.04 ltr) 공유가 가득 찼는데, 가서 보니 공유에 너무 많은 것이 있는 것을 볼 수 없었습니다.
5개의 그룹 공유가 있고 각 사용자는 개별 공유를 갖습니다.
한 사용자는 22GB의 데이터를 가지고 있고 몇몇 다른 사용자는 10-20MB의 데이터를 가지고 있으며 다른 사용자는 모두 비어 있습니다.
그러니까 아마 총 26기가 정도 될 것 같아요
어제 몇 개의 파일을 삭제하고 오늘 약 250MB의 공간을 확보했는데 다시 확인해보니 완전히 꽉 찼고 일부 오래된 파일을 삭제하고 약 170MB의 항목을 확보했지만 여유 공간이 천천히 줄어드는 것을 볼 수 있습니다.
나는 계속해서df -h
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 241690180 229340500 169200 100% /
varrun 257632 260 257372 1% /var/run
varlock 257632 0 257632 0% /var/lock
udev 257632 72 257560 1% /dev
devshm 257632 52 257580 1% /dev/shm
lrm 257632 40000 217632 16% /lib/modules/2.6.24-28-generic
/휘발성 물질
내 HDD를 너무 많이 차지하는 것이 무엇인지 찾아내려면 어떻게 해야 하나요? (나는 일반적으로 유닉스를 처음 접했기 때문에 이것이 잘 설명되지 않았다면 사과드립니다)
답변1
(이것은 Linux에 초점을 맞춘 답변입니다. 다른 UNIX 변형은 다를 수 있습니다.)
문제와 관련된 정보에는 (1) 파일 시스템을 채우는 파일과 (2) 해당 파일에 쓰는 프로세스라는 두 가지 정보가 있습니다.
노트
아래에서 명령에 문자를 입력하면 $실제 값을 대체해야 하는 자리 표시자가 될 것입니다. 다행히도 그렇게 해야 할 곳과 하지 말아야 할 곳은 분명합니다.
어떤 파일?
대부분의 파일 시스템 유형에는 실제로 개별 파일에서 사용할 수 있는 두 가지 리소스, 즉 메타데이터(예: inode)와 실제 데이터가 있다는 점에 유의하세요. 다음과 같은 명령을 사용하여 inode 수를 확인할 수 있습니다(Google에서 정의를 검색하지만 이는 파일을 구성하는 구조에 대한 "포인터"입니다).
df -i
... 그리고 이미 알고 있듯이 다음과 같은 내용은 실제 데이터가 사용하는 공간을 보여줍니다.
df -h
또한 디스크에 존재하지 않는 파일이 파일 시스템 공간을 차지할 수 있다는 점에 유의하세요. 이러한 파일은 일부 프로세스에 의해 여전히 열려 있는 상태이지만 제거되었습니다(아래에서 다루겠습니다).
전체 파일 시스템을 식별한 후에는 많은 작은 파일, 몇 개의 큰 파일 또는 둘 다를 찾기 시작해야 합니다. 메타데이터 리소스 부족은 일반적으로 작은 파일이 많기 때문에 발생하는 반면, 실제 데이터 리소스 부족은 일반적으로 몇 개의 큰 파일로 인해 발생합니다. 나는 이 명령을 사용하여 큰 파일을 찾는 것을 좋아합니다.
sudo find $file_system -mount -ls | awk '{print $7, $11}' | sort -rn > $output
... 그리고 이 명령은 작은 파일이 많은 디렉토리를 찾는 데 도움이 됩니다(업데이트:: 파일 이름 처리를 개선하기 위해 null 종료를 추가했습니다.):
sudo find . -mount -print0 | xargs -0n 1 dirname | sort | uniq -c | sort -rn > $output
... 이러한 명령은 실행하는 데 시간이 걸릴 수 있으며 이에 따라 많은 I/O를 수행할 수 있습니다. 실행한 후에는 전체 내용을 읽어 $output문제가 되는 파일이나 디렉터리를 찾을 수 있습니다. 각각의 이름과 위치는 데이터의 출처에 대한 힌트를 제공할 수 있지만 약간의 Linux 경험이 필요합니다.
위반자를 식별한 후에 rm $file는 문제를 제거할 수 있습니다.
어떤 프로세스?
파일 시스템을 가득 채울 가능성이 있는 프로세스를 찾는 가장 간단한 방법은 다음과 같은 명령을 실행하는 것입니다.
fuser -c $file_system 2>/dev/null
... 주어진 파일 시스템에 대해 열린 파일 설명자(파일 및 네트워크 소켓)가 있는 프로세스의 PID를 알려줍니다(이 2>/dev/null부분은 필요하지 않은 일부 정보를 제거합니다). 이러한 PID를 통해 어떤 프로세스가 파일 시스템을 채우고 있는지 추론할 수 있습니다. 다음을 사용하여 프로세스를 검색합니다.
ps -ef | grep $pid
또한 이 명령을 실행하면 훨씬 더 자세한 정보를 얻을 수 있습니다(그리고 디스크에 해당 파일 이름이 없는 열려 있는 파일을 식별하는 데 도움이 됩니다. 위에서 언급한 내용입니다).
sudo lsof $file_system | grep $directory_filling_up
... 그리고 명령에서 의심스러운 PID를 식별한 경우 fuser다음을 수행할 수 있습니다.
sudo lsof -p $pid
문제는 fuser명령 lsof을 실행할 당시 시스템의 스냅샷만 제공한다는 것입니다. 실행 시 문제가 되는 프로세스가 작성되지 않으면 운이 없는 것입니다. 시간이 지남에 따라 반복적으로 실행하고 출력을 저장하여 이에 대응할 수 있습니다. 이를 위해서는 출력을 통해 패턴을 찾거나 이를 수행하는 프로그램을 작성해야 합니다. 대안은 다음과 같은 도구를 사용하는 것입니다.시스템탭. SystemTap을 사용하면 모든 종류의 유용한 정보를 트랩할 수 있으며 "프로그래밍 가능"합니다. 일정 기간 동안 어떤 프로세스가 어떤 파일에 쓰고 있는지 확인할 수 있는 일부 샘플 소스 파일도 함께 제공됩니다. 완벽하겠지만 고급 도구이고 많은 Linux 지식이 필요합니다.
문제가 되는 프로세스를 식별한 후에는 종료할 수 있습니다(그리고 다시 시작할 수도 있습니다). 프로세스가 운영 체제나 잘 패키지된 소프트웨어와 연결되어 있는 경우 이를 다시 시작하는 메커니즘이 있을 수 있지만 Linux 배포판에 따라 다릅니다(Ubuntu에서는 와 같은 것을 실행할 수 있다고 생각 /etc/init.d/$init_script restart하지만 배포판의 문서를 확인하세요). 그렇지 않으면 작동하지 않는 경우 kill $pid또는 으로 죽일 수 있습니다 . 프로세스를 다시 시작해야 하는 경우를 대비하여 kill -9 $pid프로세스가 어떻게 실행되었는지(예: 에 표시된 인수는 무엇인지 ps -ef) 주의 깊게 기록해 두십시오(해당 소프트웨어 설명서를 참조해야 할 수도 있음).
답변2
du디스크를 채우고 있는 파일이 포함된 디렉터리를 추적하는 데 사용됩니다 .
cd /
du -h --max-depth 1
/에서 가장 많은 공간을 사용하는 디렉토리가 표시됩니다. du 명령을 실행하여 파일 시스템을 탐색하여 범인을 찾으십시오.
예를 들어
cd /
du -h --max-depth 1
/usr은 시스템에서 사용되는 3.5G 중 2.3G를 사용하고 있음을 보여줍니다.
cd /usr
du -h --max-depth 1
/usr/lib는 /usr의 2.3 중 1.1G를 사용합니다.
이는 삭제된 열린 파일로 인해 발생할 수도 있습니다.
당신이 사용할 수있는이소프열려 있지만 링크가 해제된(삭제된) 파일을 찾으려면
lsof +L1
트릭을 수행해야합니다. 매뉴얼 페이지에 다음과 같이 명시되어 있습니다.
양식의 사양은
+L1연결이 해제된 열린 파일을 선택합니다. 양식 사양은+L1 <file_system>지정된 파일 시스템에서 링크되지 않은 열린 파일을 선택합니다.
답변3
뭔가가 / 파티션을 채우고 있습니다. 아마도 /var/log, 또는 에 있는 내용일 것입니다 /home. 이는 설정에 따라 다릅니다. 또한 사용자가 액세스할 수 있는 위치를 살펴보세요.
문제의 각 디렉터리에서 다음 명령을 실행합니다. 그러면 공간을 가장 많이 소비하는 하위 디렉터리가 표시됩니다.
cd /directory
du -cks -x * .* |sort -n
ducks이 아이디어는 의 스크립트 ( du -cks) 에서 차용되었습니다.리눅스 서버 해킹오라일리에서. 나는 이 명령을 자주 실행한다.
내 경험에 따르면 이는 거의 항상 로그 파일의 크기가 커지고 증가하기 때문입니다. 이 경우 다음을 사용하십시오.로그로테이션, 그리고반드시 압축을 사용하세요. 기본 압축 비율로 gzip 압축을 사용하면 로그 파일이 80-95% 더 작아집니다(1GB /var/log/messages는 200MB 이하로 쉽게 압축될 수 있음). 이로 인해 CPU에 적당한 양의 로드가 발생하지만 이것이 서버의 실제 성능에 영향을 미치는 경우는 거의 본 적이 없습니다. 어떤 사람들은 Bzip2 압축을 사용하는 것을 선호 gzip --best하지만 제 경험상 이로 인해 추가적인 이점은 거의 없이 CPU 오버헤드가 많이 발생합니다. gzip일반적으로 기본 비율이면 충분합니다.
그리고 분명히 이 문제는 때때로 사용자가 나쁜 일을 했기 때문에 발생합니다. 위의 명령 을 사용하여 du범인을 찾으십시오.
답변4
범인일 가능성이 있는 로그는 다음과 같습니다. 최근 수정된(또는 생성된) 파일을 크기별로 정렬하는 명령은 다음과 같습니다.
D=$(date --rfc-3339 date);
sudo sh -c 'find / -xdev -mtime -1 -type f -print0 |xargs -0 du -0sbc' \
|tee ~/recent-files.$D |sort -zn |tee ~/recent-by-size.$D |xargs -0n1
이 명령을 매일 실행할 수 있습니다. 일일 증가량에 따라 이러한 파일을 정렬하기 위해 SQL과 같은 작업을 수행하는 방법이 있을 수 있습니다.
(편집) 성장을 모니터링하려면 다음을 사용하십시오.GT5
sudo aptitude install gt5
cd /
gt5
하루 후; ± 기호를 찾아보세요
gt5