☰

CentOS 6에 공간이 부족하여 회수해야 합니다. [닫기]

tag-icon • tag-icon centos disk-usage
CentOS 6에 공간이 부족하여 회수해야 합니다. [닫기]

CentOS 6에는 모든 공간을 사용한다고 하는데 공간이 어디로 갔는지 알 수 없는 문제가 있습니다.

100% 다 쓴 것 같아요

df -h

Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/vg_sugar-lv_root   50G   49G     0 100% /

50G 중 49G는 공평하지만 정확히 무엇이 사용되었는지 확인하려고 하면 다음과 같습니다(x는 설치 삭제를 의미함).

du -xsh /*

1.8G    /usr
2.0G    /var

이것이 바로 2개의 가장 큰 디렉터리이며, 다른 모든 디렉터리를 합친 경우 1G 미만입니다.

다음은 디스크 /dev/mapper/vg_sugar-lv_root에 대한 정보입니다. 이는 50G에 가깝게 표시됩니다(이것은 가상 머신입니다).

fdisk -l

Disk /dev/mapper/vg_sugar-lv_root: 53.7 GB, 53687091200 bytes
255 heads, 63 sectors/track, 6527 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

노드 수는 7%입니다.

df -i

Filesystem                   Inodes  IUsed     IFree   IUse% Mounted on
/dev/mapper/vg_sugar-lv_root 3276800 200552    3076248    7% /

시스템이 여러 번 다시 시작되었으므로 모든 로그 파일이 삭제되었을 것입니다. 이 문제를 해결하는 방법에 대한 몇 가지 팁을 알고 싶습니다.

답변1

좋아요, 그러면 해결책을 게시하겠습니다. 이 예에서는 로컬 디렉터리 /mnt/backup에 설치된 네트워크 위치 /mnt/backup입니다. 일단 제거되면

umount /mnt/backup

로컬 디렉터리가 백업으로 가득 찬 45G를 차지한다는 것을 보여줍니다.

cd /mnt/backup/ du -h 39G ./servers-unix-hq/sugar.gnsa.local 39G ./servers-unix-hq 4.5G ./db-mysql-hq/sugar.gnsa.local 4.5G ./db-mysql-hq 44G 일부 오래된 백업을 삭제했고 이제 MySQL이 시작됩니다.

답변2

이는 일반적으로 누군가가 늘어나는 파일을 자르는 것이 아니라 삭제하는 경우 발생합니다. 파일을 쓰는 프로그램이 디스크 공간을 닫을 때까지 디스크 공간은 해제되지 않습니다.

lsof +L1삭제되었지만 여전히 열려 있는 모든 파일과 해당 파일을 열어두는 프로세스의 목록을 가져옵니다 . 출력은 다음과 같습니다.

# lsof +L1
COMMAND     PID     USER   FD   TYPE DEVICE SIZE/OFF NLINK    NODE NAME
php-fpm7.  1364     root    3u   REG   0,45        0     0   41658 /tmp/.ZendSem.plytyh (deleted)

COMMAND 및 PID 필드는 어떤 프로세스가 파일을 열어두고 있는지 알려주고, NAME은 파일 이름이 무엇인지 나타냅니다. TYPE 필드의 값은 REG이며 이는 일반 파일임을 나타냅니다. SIZE/OFF 값은 삭제된 파일의 크기에 대한 아이디어를 제공할 수 있지만 항상 신뢰할 수 있는 것은 아닙니다(프로그램이 파일 끝에 계속 추가하고 그 사이에 아무것도 업데이트하지 않는 경우에만 해당). 다행히도 이 값은 대부분의 로그 파일의 기본값입니다).

문제의 원인을 파악한 후에는 문제를 해결할 수 있는 여러 가지 방법이 있습니다.

1. 가능하다면 해당 프로세스의 로그 로테이션 기능을 호출한다.

문제 파일이 로그 파일이고 열려 있는 프로세스에 로그 회전을 허용하는 기능이 있는 경우(예: 프로세스에 모든 로그 파일을 닫았다가 다시 열도록 지시할 수 있음) 로그 회전 기능을 트리거할 수 있습니다. 많은 데몬은 kill -HUP이 목적을 위해 하나 이상의 다른 신호를 받아들입니다. 삭제된 파일의 데이터는 먼저 복구하지 않으면 손실됩니다(아래 참조).

2. 파일을 열어두는 프로세스를 중지했다가 다시 시작하세요.

파일을 열어 둔 상태에서 프로세스를 중지했다가 다시 시작하면 문제가 해결되고 삭제된 파일의 내용이 영구적으로 손실됩니다(먼저 복원하지 않는 한 아래 참조).

3. (해결 방법) 삭제된 파일에 액세스했지만 여전히 열려 있는 파일을 0 크기로 자릅니다.

출력에서 PID 및 FD 번호를 사용하면 lsof +L1루트 액세스 권한이 있는 경우 파일 시스템을 통해 "삭제되었지만 여전히 열려 있는" 파일에 계속 액세스할 수 있습니다 /proc. 위 예의 파일은 /proc/1364/fd/3.

(FD 번호 뒤의 모든 문자는어떻게프로세스가 파일에 액세스하고 있으므로 무시할 수 있습니다. )

cat삭제된 파일의 내용을 복구해야 하는 경우 출력을 다른 파일(여유 공간이 충분한 다른 파일 시스템)로 전송하면 됩니다 .

디스크 공간만 확보해야 하는 경우 명령을 사용하여 파일을 0 크기로 잘라낼 수 있습니다 > /proc/1364/fd/3(즉, 명령 없이 명령줄을 사용하면 출력을 잘라낼 파일로 리디렉션하기만 하면 됩니다).

노트:기존 데이터만 삭제됩니다. 더 많은 데이터가 삭제된 파일에 누적되는 것을 방지할 수는 없지만 유지 관리 중단 시간을 예약할 수 있을 때까지 중요한 서비스를 계속 실행할 수 있습니다.

기록 중인 로그 파일을 삭제하는 것은 초보 Unix 시스템 관리자가 흔히 저지르는 실수입니다. 거의 모든 사람들이 Unix/Linux 경력에서 적어도 한 번은 이런 실수를 합니다. 좋은 사람들은 자신의 실수로부터 교훈을 얻어 실수가 발생하면 고치고 미래에는 실수를 피하는 방법을 배웁니다.

관련 정보