공간이 떨어지는 것은 악의가 전혀 개입하지 않은 채 서버가 멈추는 가장 흔한 이유입니다. 사이트는 500을 돌려주고, 데이터베이스는 쓰지 못하며, 메일은 나가지 않습니다 — 그동안 df -h는 몇 기가바이트가 비어 있다고 보고합니다. 그런 일이 벌어지는 세 가지 경우와, SMART에 대해 알아 둘 만한 것을 짚어 봅시다.

첫 번째 경우: inode가 떨어졌다

파일 시스템에는 한정된 자원이 둘 있습니다. 내용을 위한 공간과 파일에 대한 기록입니다. 두 번째는 첫 번째와 무관하게 떨어집니다.

df -h
df -i

두 번째 명령의 IUse%가 100이면 문제는 inode입니다. 공간은 있는데 파일을 하나도, 빈 것조차 만들 수 없습니다.

범인은 늘 같습니다. 수백만 개의 자잘한 파일. 가비지 컬렉션이 망가진 /var/lib/php/sessions의 PHP 세션. 한 번도 비워지지 않는 애플리케이션 캐시. 막힌 메일 큐. 썸네일 디렉터리. 이렇게 찾을 수 있습니다.

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

이 명령은 파일이 가장 많은 디렉터리를 나열합니다. 큰 시스템에서는 몇 분 걸립니다 — 정상입니다.

두 번째 경우: 파일은 지웠는데 공간이 돌아오지 않았다

더 교활한 상황입니다. 누군가 커진 로그를 rm으로 지웠는데, 거기에 쓰던 프로세스가 여전히 그것을 열어 둔 채 붙잡고 있습니다. 파일은 이제 디렉터리에 없지만 공간은 여전히 차지돼 있고, 그 프로세스가 재시작될 때까지 그대로입니다.

sudo lsof +L1

이 명령은 파일 시스템에서 링크 수가 0인데도 여전히 어떤 프로세스가 붙잡고 있는 파일을 보여 줍니다. 치료법은 그 프로세스를 재시작하거나 부드럽게 다시 읽히는 것이지, 「기가바이트가 어디로 갔나」를 뒤지는 것이 아닙니다.

여기서 규칙이 나옵니다. 커진 로그는 지우지 말고 비우도록 잘라 냅니다. 그러면 열려 있는 서술자가 계속 쓸모 있는 상태로 남습니다.

sudo truncate -s 0 /var/log/huge.log

그리고 곧바로 회전을 설정하세요 — 그러지 않으면 일주일 안에 모든 것이 되풀이됩니다.

세 번째 경우: 로그가 먹어 치웠다

공간이 정확히 어디로 갔는지는 층층이 내려가며 보면 알 수 있습니다.

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

-x 플래그는 다른 파일 시스템으로 헤매 들어가지 않게 합니다. 이것이 없으면 집계가 /proc과 네트워크 마운트로 기어들어 갑니다. 이 모든 것은 ncdu가 있다면 그쪽이 더 편합니다.

익숙한 대식가들:

  • journald. 명령 하나로 정리됩니다: journalctl --disk-usage. /etc/systemd/journald.conf의 SystemMaxUse=500M 줄로 상한을 두고, journalctl --vacuum-size=200M으로 한 번 청소합니다;
  • 보안 도구의 로그. 기본 설정의 Suricata는 서른 종류의 이벤트를 쓰고 자기 회전은 설정하지 않습니다 — 실제 서버에서 이틀에 15 GB를 만들었습니다. audit.log와 nginx의 디버그 로그도 마찬가지입니다;
  • 백업, 같은 디스크에 쓰이고 한 번도 지워지지 않는 것;
  • apt의 캐시 — apt clean이 가끔 기가바이트 몇 개를 돌려줍니다.

/boot에 대해 한마디

옛 커널로 차오르는 작은 파티션입니다. 그 자체로 사이트를 무너뜨리지는 않지만 업데이트를 완전히 멈춰 세웁니다. 새 커널이 설치되지 않고, 패키지 대기열 전체가 그 뒤에 막힙니다. 치료는 apt autoremove --purge, 예방은 자동 업데이트 설정에서 쓰지 않는 커널의 자동 삭제를 켜는 것입니다.

SMART: 어떤 속성이 중요한가

먼저 한마디. 가상 서버에서는 SMART를 대개 쓸 수 없습니다 — 디스크는 가상이고 그 아래의 물리 디스크는 보이지 않습니다. 결함이 아니라 그저 데이터가 없는 것입니다. 이후의 모든 이야기는 전용 서버와 자기 하드웨어에 관한 것입니다.

sudo smartctl -a /dev/sda

SMART overall-health self-assessment test result: PASSED 줄은 안심할 이유가 되지 못합니다. 드라이브가 죽기 직전까지 사실상 초록으로 남으니까요. 봐야 할 것은 구체적인 카운터입니다.

  • 5, Reallocated_Sector_Ct — 재할당된 섹터. 0이 아니면 드라이브는 이미 나빠지고 있고, 시간에 따라 늘어나면 미루지 말고 교체하세요;
  • 197, Current_Pending_Sector — 읽히지 않아 판정을 기다리는 섹터. 그중 가장 불안한 것입니다. 대개 데이터의 일부가 이미 복구 불가능함을 뜻합니다;
  • 198, Offline_Uncorrectable — 같은 것이며, 검사로 확인된 것;
  • SSD: Percentage Used / Media_Wearout_Indicator — 소모된 쓰기 수명. 예측 가능한 숫자이며, 교체를 계획하는 기준이 되는 값입니다.

반면 온도와 가동 시간은 그 자체로는 아무것도 말해 주지 않습니다. 5년을 돌았지만 오류 카운터가 0인 드라이브가, 속성 197에 1이 있는 새 드라이브보다 믿음직합니다.

지켜보는 일의 의미

위의 모든 것은 이미 벌어진 일에 대한 반응입니다. 그런데 차오르는 디스크도 SSD의 마모도 느리고 완전히 예측 가능한 과정입니다. 2주치 점유 그래프는 공간이 떨어질 날짜를 훨씬 앞서 보여 줍니다. 「사이트가 새벽 세 시부터 죽어 있다」와 「목요일에 로그를 정리해야 한다」의 차이는, 그 숫자가 눈앞에 있느냐 없느냐뿐입니다. 조립된 모습이 어떤지는 아래 데모 페이지에서.