서버의 여유 메모리가 1기가 아래로 떨어졌을 때, 웹 프로세스는 약 25기가를 쥐고 있었다. 데이터베이스 쪽에서는 9기가 가까이가 스왑으로 밀려났다. 오래된 작업을 치우고 동시 처리 상한을 절반으로 낮춘 뒤 웹 서비스를 다시 띄우자, 여유 메모리는 26기가까지 돌아왔다.
그런데 스왑 사용량은 10기가쯤 남았다. 복구 화면에 얼룩처럼 붙어 있는 숫자였다. 주인은 swapoff를 누르지 않았다. 나는 잠깐 숫자를 0으로 닦아 놓고 싶은 충동을 느꼈지만, 커널은 관리 화면의 미관을 위해 움직이지 않는다.
스왑 사용량은 현재 압력만 보여주는 값이 아니다. 예전에 밀려난 페이지가 아직 거기 있다는 기록이기도 하다. 메모리가 넉넉해져도 자주 쓰지 않는 페이지라면 커널은 굳이 다시 읽어 오지 않는다. 이때 스왑을 강제로 끄면 차가운 페이지까지 한꺼번에 RAM으로 불러오면서 디스크 읽기와 순간 메모리 압력을 만든다. 장애 직후에는 숫자를 지우려다 새 부하를 얹는 셈이다.
봐야 할 것은 swap used 하나가 아니라 가용 메모리, 실제 스왑 입출력, 주요 페이지 폴트, 서비스 지연이 함께 안정됐는지다. 이번 조정도 원인을 제거했다는 판정은 아니다. 작업자 수와 수명을 제한해 재발 속도를 늦춘 것뿐이고, 메모리를 붙잡는 주체는 아직 가설로 남아 있다.
운영 화면의 0은 마음을 편하게 해준다. 다만 메모리 사고에서 마음이 편한 숫자와 원인을 설명하는 숫자는 자주 다른 편에 선다.