测验：资源耗尽时的症状

서비스가 오후마다 죽고 재시작하면 한동안 괜찮아진다. 이 패턴이 가장 강하게 가리키는 것은?

• 시간이 지날수록 쌓이는 자원이 있고, 재시작이 그것을 모두 회수하고 있다
• 오후에 트래픽이 몰려 처리량 한계를 넘고 있으므로 수평 확장이 필요하다
• 배포가 오후에 이루어져 새 판의 결함이 그때마다 드러나고 있다
• 캐시가 오후에 만료되면서 하류 시스템의 응답이 느려지고 있다

기술자가 바닥난 프로세스에서 sqlite3 가 '데이터베이스 파일을 열 수 없다' 고 답했다. 이 메시지의 성격은?

• 데이터베이스 파일의 권한이나 경로에 실제로 문제가 있다는 신뢰할 만한 신호다
• 기술자를 흘린 코드가 어디인지 알려 주는 단서이므로 그 모듈부터 본다
• 자원이 바닥난 뒤 그다음에 자원을 요청한 코드가 실패한 것이라 원인을 가리지 않는다
• sqlite3 가 errno 24 를 그대로 전달하므로 다른 오류와 구별할 필요가 없다

파일 기술자 누수를 증명하려 한다. 가장 설득력 있는 자료는?

• 지금 열린 기술자가 900개라는 한 번의 관측과 그때의 프로세스 목록
• 요청 수를 바꿔 가며 잰 기술자 수의 점들과 그 기울기(요청 하나당 새는 개수)
• 오류가 나기 직전 한 시간 동안의 오류 로그 건수 추이
• 한도를 두 배로 올린 뒤 하루 동안 죽지 않았다는 관찰

RLIMIT_AS 로 주소 공간을 제한해 재현한 메모리 부족과, 커널 OOM 킬러가 죽인 경우의 가장 큰 차이는?

• 전자는 할당이 느려질 뿐 실패하지 않고, 후자만 실제로 실패로 이어진다
• 전자는 프로세스 전체에, 후자는 스레드 하나에만 적용된다
• 전자는 디스크 스왑을 쓰고 후자는 쓰지 않아 회복 속도가 다르다
• 전자는 MemoryError 예외라 트레이스백이 남고, 후자는 SIGKILL 이라 아무 자국도 남지 않는다

조사 중에 RLIMIT_NOFILE 을 일부러 낮춰 재현하는 이유로 가장 적절한 것은?

• 낮은 한도에서는 커널이 오류를 더 자세히 기록하므로 원인이 드러난다
• 한도를 낮추면 누수 자체가 줄어들어 문제의 크기를 가늠할 수 있다
• 열 시간 뒤에 만날 바닥을 몇 초 만에 만들어, 재현과 증명을 짧은 시간에 반복할 수 있다
• 소프트 한도는 낮출 수만 있고 올릴 수 없으므로 원래 값으로 되돌릴 필요가 없다

고갈 사건의 보고서에 증상 목록과 원인을 따로 적어야 하는 이유는?

• 다음 사람이 같은 메시지를 만났을 때 무고한 모듈을 몇 시간 뒤지지 않게 하기 위해서다
• 증상과 원인을 나누어 적어야 사건의 심각도를 등급으로 매길 수 있기 때문이다
• 오류 메시지는 저작권이 있어 원문 그대로 인용하면 안 되기 때문이다
• 모니터링 도구가 두 항목을 각각 다른 대시보드에 그리기 때문이다