업그레이드 과정에서 RAM+스왑 메모리에 가장 큰 부하가 걸리는 시점은 ‘ember’ 프로세스가 실행될 때입니다. 업데이트를 할 때마다 이전보다 부하가 더 커지는 것 같고, 권장 최소 사양 컴퓨터에서 실행할 수 없는 수준에 가까워지고 있습니다.
실제로 문제가 발생하기 전에 이 부분을 살펴보는 것이 좋을 것 같습니다. (비용 문제로 인해 권장 최소 사양을 높이는 것이 해결책이 되지는 않기를 바랍니다. 디스크 공간이 허락한다면 스왑 공간을 늘리는 것이 도움이 될 것입니다. 원칙적으로는 더 비싸지만 RAM이 더 큰 인스턴스로 일시적으로 이전하는 것도 가능합니다.)
저는 권장 최소 사양 내의 작은 인스턴스 두 대에서 규모가 modest한 포럼 두 개를 운영하고 있습니다. 두 경우 모두 RAM+스왑=3G입니다. 한쪽은 RAM 1G와 스왑 2G가 있는 Digital Ocean 인스턴스이고, 다른 쪽은 RAM 2G와 스왑 1G가 있는 Hetzner 인스턴스입니다.
DO 머신에서 ps auxc를 사용하여 ember 프로세스의 스냅샷 세 가지를 첨부합니다.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
1000 10342 87.7 65.1 32930460 657936 ? Rl 16:57 2:23 ember
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
1000 10342 84.9 60.7 43572204 612668 ? Rl 16:57 2:57 ember
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
1000 10342 81.2 55.2 43405220 557128 ? Rl 16:57 3:40 ember
물론 43GB의 프로세스 크기가 전부 가상 메모리에 존재하는 것은 아닙니다. 사용 가능한 메모리가 3G이기 때문입니다. RSS가 RAM 크기의 65%를 사용하는 것은 인상적이지만, 그 자체로는 문제가 되지 않습니다. 사용 가능한 메모리와 스왑의 양을 보면 머신이 Out of Memory (OOM) 상태에 근접해 있음을 알 수 있으며, 이는 가장 가능성이 높은 결과로 일부 프로세스가 강제 종료되고 업데이트가 깔끔하게 종료되지 않는 상황을 초래할 것입니다.
시점별 스냅샷으로 free 명령어의 출력을 보여드립니다:
# free
total used free shared buff/cache available
Mem: 1009140 863552 72768 6224 72820 34868
Swap: 2097144 1160628 936516
실패에 가장 가까운 상황을 포착하기 위해 vmstat 5를 사용했습니다.
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 1392140 61200 11632 76432 41 32 117 93 0 1 2 1 97 0 0
1 1 1467220 63416 324 67284 8786 20499 13178 20567 2539 8924 77 13 0 10 0
0 2 1593340 57916 1096 53832 24262 46868 29986 46889 5377 18534 44 22 0 34 0
4 0 1155632 120680 2772 86280 39111 35424 54768 37824 6987 25174 38 27 0 35 0
3 0 1102988 74096 2852 85276 11261 246 12610 271 1879 6365 86 6 0 8 0
많은 컨텍스트 스위치(cs), 많은 디스크 활동(bi, bo) 및 많은 스왑 활동(si, so)을 볼 수 있습니다. 그러나 가장 중요한 것은 스왑 사용량이 1.6G까지 증가하고 사용 가능한 메모리가 60M까지 줄었으며 버퍼 사용량이 54M에 불과하다는 점입니다. 이는 사용 가능한 3G의 가상 메모리 중 약 2.6G가 사용 중임을 의미합니다. 이는 용량의 87%입니다. (5초 간격으로 샘플링하고 있기 때문에 실제로는 더 나쁠 수 있습니다.)
8월에 업데이트했을 당시에도 상황이 우려스러웠습니다(약 2G 사용으로, 오늘처럼 임계치에 매우 근접하지는 않았지만):
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 700404 62740 1956 48748 35 29 108 92 3 8 2 1 96 0 1
1 0 741000 65996 1880 44360 3708 11190 3982 11191 643 1437 92 4 0 3 1
1 0 834836 70452 1480 53856 528 18969 4274 18974 532 1575 93 6 0 1 0
4 1 1010144 82192 4644 44400 30065 38803 35455 39946 4432 19267 28 26 0 39 7
1 0 644116 307764 1644 55348 24406 21154 27724 21945 2551 8672 52 22 0 21 6
