증상
디스크가 또 찼다. df를 보면 407GB가 남아 있다. 그런데 쓰기가 실패한다.
원인
df가 보여주는 건 서버 전체다. 실제 한도는 계정 쿼터 10GB였다.
★★ 도구가 보여주는 분모를 먼저 확인한다. 공유 환경에서는 거의 모든 지표가 내 몫이 아니라 호스트 전체를 가리킨다. 프로세스 한도도 같다 — 서버의 코어 수가 아니라 계정의 ulimit 이 한도다.
같이 배운 것 — 정리 전에 영향 범위를 확정한다
무엇을 지워도 되는지 몰라서 손을 못 대는 상태가 오래 갔다. 실측해보니:
| 대상 | 크기 | 판정 |
|---|---|---|
| 업로드 원본 중 규격 초과분 1,002개 | 1.4GB | 축소 가능 |
| 특정 크기 썸네일 10,056개 | 642MB | 테마가 참조하지 않음 |
| 외부 플랫폼에 올린 상품 이미지 | — | 그쪽 CDN에 있다. 이 서버와 무관 |
★ "어디에 실제로 저장돼 있는가"를 확정하지 않으면, 막연한 공포로 아무것도 못 한다. 마지막 줄이 특히 그랬다 — 상품 이미지가 이 서버에 있다고 *가정*하고 있었다.
★★ 삭제가 아니라 축소를 골랐다
같은 파일명·경로를 유지하고 내용만 작게 만들면 DB와 모든 참조가 그대로 산다. 삭제는 참조가 하나라도 남으면 깨지지만, 축소는 깨질 것이 없다.
★ 되돌릴 수 없는 수단 대신 되돌릴 필요가 없는 수단을 고른다.
★★★ 목표치를 코드에 박는다
이 문제는 두 번째였다. 첫 번째 때도 정리해서 3분의 1을 회수했지만, 그건 한도에 닿았을 때의 응급처치였고 같은 자리로 다시 왔다.
이번에는 정리 크론이 목표 사용률에 도달하면 스스로 해제되게 했다.
★ 사람이 기억하는 임계는 위기 때만 작동한다. 코드에 있는 임계는 평시에 작동한다.
"목전에 오면 정리한다"는 계획이 아니라 한 번 더 겪겠다는 선언이다.