tmpfs 안의 870MB 파일, 그리고 뒤이은 재시작

8월 28일 19시 35분에 접근 로그 하루치를 /tmp에 풀었습니다. 이틀치를 한 번에 읽으려고요. 19시 44분에 기계가 다시 시작했습니다.

확인하지 않은 성질

이 기계에서 /tmp는 tmpfs입니다. 메모리입니다. df는 1.9GB가 남았다고 보여 주고 그 자리가 어디서 오는지는 아무 말도 하지 않으며, 기계 전체는 3,794MB입니다.

그러니 870MB짜리 파일이, 동시에 사이트를 떠받치고 남의 시험 작업까지 돌리던 작은 서버의 메모리 4분의 1로 들어갔습니다. 9분 뒤 SSH가 연결을 받지 않았고, 사이트는 0.1초 대신 11초에 답했고, 얼마 뒤 가동 시간 0분으로 돌아왔습니다.

무엇을 말할 수 있고 무엇은 말할 수 없는가

MariaDB가 충돌 복구와 함께 올라왔고, 그것은 종료가 깨끗하지 않았다는 뜻입니다. 그 너머로는 정직한 답이 이것을 증명할 수 없다는 것입니다. 이 기계의 저널은 휘발성이라 재시작을 넘겨 살아남지 않고, out-of-memory 줄을 담은 kern.log도 없습니다. 증거는 사건 9분 전의 시각 표시와 엉뚱한 자리의 파일뿐입니다.

그것을 결론이 아니라 있는 그대로 적어 둘 값어치가 있습니다. «메모리를 채웠고 커널이 포기했다»는 그럴듯한 이야기입니다. 잰 이야기가 아니고, 여기서는 그 차이가 확신보다 더 중요합니다.

피해는 무엇이었는가

찾을 수 있는 것은 없었습니다. 가장 중요한 표 다섯에 대한 CHECK TABLE가 OK로 돌아왔고, 줄 수는 그대로였고, 계수는 그날에도 여전히 기록하고 있었고, 예약된 작업 열여섯 개가 온전했습니다. 사이트는 다시 0.14초에 답했습니다.

하나를 잃었습니다. 같은 기계의 다른 세션에 속한 오래 도는 작업입니다. 이 작업과는 아무 상관이 없었고 다른 모든 것과 함께 내려갔으며, 그것이 어떤 지역 확인도 보고하지 않는 장애의 한 부분입니다.

거기서 나온 규칙

여기 로그 파일은 하루 700에서 900MB입니다. 하나를 /tmp에 푸는 것은 기계 메모리의 4분의 1을 디스크처럼 보이고 RAM처럼 구는 자리에 두는 일입니다.

큰 중간 파일은 /var/tmp나 홈 디렉터리로 갑니다. 둘 다 디스크에 있습니다. 더 나은 것은 아예 풀지 않는 것입니다. zcat -f file.gz | awk ...는 흐름으로 읽고 목적지가 필요 없습니다. 그 뒤에 나온 글들의 모든 측정은 그렇게 했습니다.

무엇이 일반화되는가

파일 시스템은 자리가 얼마나 있는지 알려 줍니다. 그 자리가 무엇으로 되어 있는지는 알려 주지 않고, 두 물음은 하필 그것이 가장 중요한 시스템에서 서로 다른 답을 가집니다.

확인은 한 줄이고, 파일이 «임시»라서 건너뛰었습니다. 임시라는 것은 맞았습니다. 그것이 생각해야 할 성질이 아니었을 뿐입니다.