재시작 후 메모리 사용량이 서서히 증가합니다

언제부터였는지 정확히 모르겠지만, 지난 몇 주 사이에, 아마도 Discourse 업데이트 이후부터 사이트가 조금씩 느려지는 느낌이 들었습니다. 현재 3.4.0.beta2-dev 버전을 사용하고 있습니다.

서버 인스턴스의 사용 가능한 메모리가 거의 남지 않은 것을 확인하여 재부팅을 수행했습니다. Discourse가 시작된 직후에는 메모리 사용량이 정상(약 1.2GB)이었지만, 점차 증가하기 시작하여 곧 다시 느려지는 지점에 도달할 것으로 보입니다.

사이트는 특별히 바쁘지 않은 편(일일 방문자 20~30명)이며, 최근까지 수년간 문제가 없었습니다.

서버 인스턴스의 메모리는 2GB입니다. 제가 확인한 요구 사항(최소 1GB, 권장 2GB)에 따르면 충분한 용량으로 보입니다.

개인적으로는 메모리 누출처럼 느껴집니다. 물론 누출이 존재한다면 Discourse가 아니라 Docker 또는 기타 요인일 수도 있습니다. 해당 인스턴스는 Discourse 전용으로 사용되고 있습니다.

어떤 생각이 있으신가요? 이것이 누출인지 확인하고, 누출을 일으키는 프로세스를 식별하는 방법이 있을까요?

가용 메모리는 매우 모호한 개념입니다 - 메모리가 부족하다는 확실한 징후는 페이지ング 활동입니다.

free
또는
free -h
명령을 사용하면 현재 상태를 스냅샷으로 확인할 수 있습니다.

vmstat 5 5
명령은 페이지ング 활동을 포함한 시스템의 진행 상황을 파악하는 데 매우 유용합니다.

              total        used        free
Mem:          1.9Gi       1.5Gi        73Mi
Swap:         2.0Gi        54Mi       1.9Gi
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0  55524 111624  20080 385060    1    3    68    52  965  349  4  2 93  1  0
 0  0  55524 114884  20088 385152    0    0    13     8 1047  352  2  1 96  0  0
 0  0  55524 112428  20088 385160    0    0     0     3  831  319  3  1 95  0  0
 0  0  55524 111616  20096 385164    0    0     0    51  688  278  2  0 97  0  0
 0  0  55524 109884  20104 385168    0    0     0     8 1117  281  2  1 96  0  1

위 내용 중 문제가 있어 보이는 부분이 있나요? HTOP에서 가져온 메모리 사용량 수치가 FREE 명령어와 일치하는 것 같습니다.

제 가장 큰 우려는 메모리 사용량이 계속 증가하는 방식입니다. 특정 지점에 도달한 후 사이트 사용량에 따라 상하로 변동하다가 그 부근에서 안정화될 것으로 기대했습니다. 그러나 이 지속적인 상승 추세는 우려스럽습니다.

현재로선 아무 문제 없어 보입니다. 페이지ング(paging)에 해당하는 si와 so에 활동이 없고, bi와 bo에 해당하는 디스크 트래픽도 매우 적습니다.

리눅스는 디스크 캐싱을 위해 유휴 메모리를 사용하므로, free 메모리가 줄어드는 것은 나쁜 일이 아닙니다. free 명령어의 출력 결과는 사용 가능한 RAM을 보여주며, man 페이지에는 다음과 같이 설명되어 있습니다.

available
스왑 없이 새로운 애플리케이션을 시작할 수 있는 메모리 양에 대한 추정치.

vmstat의 경우, buff와 cache 열은 디스크 캐시에 사용된 메모리를 나타내며, I/O 성능을 향상시키기 위해 커질 수 있지만 메모리 압박이 발생하면 줄어듭니다. 따라서 free와 vmstat 모두에서 ‘free’ 값은 비관적인 측정치라고 볼 수 있습니다.

네, 감사합니다. 느려지는 현상이 메모리 부족으로 보인 것과 무관했을 수도 있습니다. 계속 모니터링하겠습니다.

아직도 무언가가 서서히 커지고 있을 가능성은 있습니다.

무엇이 일어나고 있는지 파악하기 위한 제 전술 중 하나는 다음과 같습니다:

# ps aux|sort -n +5|tail
systemd+    1659  0.0  1.3 904384 54588 ?        S    16:44   0:00 /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
root         830  0.0  1.6 2253324 65208 ?       Ssl  16:44   0:01 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
systemd+    1682  0.0  1.9 904516 78092 ?        Ss   16:44   0:01 postgres: 13/main: checkpointer 
systemd+   18757  0.1  2.1 912368 85644 ?        Ss   18:06   0:00 postgres: 13/main: discourse discourse [local] idle
1000        1688  0.1  6.5 1006548 256428 ?      Sl   16:44   0:10 unicorn master -E production -c config/unicorn.conf.rb
1000        2189  0.1  8.5 5657760 333248 ?      Sl   16:45   0:06 unicorn worker[3] -E production -c config/unicorn.conf.rb
1000        2113  0.1  8.5 5656608 334352 ?      Sl   16:45   0:07 unicorn worker[2] -E production -c config/unicorn.conf.rb
1000        2044  0.4  8.7 6052196 342380 ?      Sl   16:44   0:23 unicorn worker[1] -E production -c config/unicorn.conf.rb
1000        2006  1.7  9.0 5628640 352492 ?      Sl   16:44   1:33 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  3.1 11.1 6033652 435388 ?      SNl  16:44   2:54 sidekiq 6.5.12 discourse [0 of 5 busy]

(또는 ps auxc)

CPU와 (디스크) I/O 활동을 쉽게 모니터링할 수 있다면, 메모리 사용량보다는 이 둘을 주시하는 것을 권장합니다. 특히 I/O에 주목해 보세요. CPU 사용률이 낮고 I/O가 높으며 포럼이 느리다면, 이는 RAM 부족이 심각한 영향을 미치고 있음을 나타낼 수 있습니다.

버그를 제외하고 사이트가 느려지는 몇 가지 이유가 있습니다. 하나는 사용자 수, 사용자 활동, 데이터베이스 크기의 점진적인 증가이고, 다른 하나는 Discourse가 개발되면서 기능이 추가되고 소프트웨어 구성 요소가 업데이트됨에 따라 점점 더 커지는 것입니다.

하지만 응답성과 현재 머신이 적절한 사양인지에 관심을 기울이는 것이 가치가 있습니다.

(참고로, Hetzner의 가장 저렴한 머신은 이제 2GB RAM이었던 이전에 더 이상 구매할 수 없었던 가장 저렴한 머신과 동일한 가격에 4GB RAM을 제공합니다. 제 사이트 중 하나는 여전히 구형 2GB 사양으로 실행 중입니다.)

기록을 위해, 주요 사이트의 사용량을 추적해 왔으며, 최근에 마이그레이션이 이루어져 서버가 새로고침된 상태이므로 몇 가지 조사 결과를 포함하겠습니다. 데이터 양이 꽤 많습니다 - 굳이 자세히 보지 않으셔도 됩니다!

현재 머신의 상태는 다음과 같습니다.

# uptime
 13:55:23 up 4 days, 21:10,  1 user,  load average: 0.07, 0.08, 0.02
# free
               total        used        free      shared  buff/cache   available
Mem:         3905344     1638012       98492      481864     2168840     1595004
Swap:        4194288      252928     3941360

로그인 시 머신이 Memory usage: 45%라고 보고하는 것을 확인했습니다. 이는 ‘free’ 컬럼보다는 ‘used’ 컬럼과 가장 밀접하게 관련되어 있습니다.

저는 다음 명령어에서 주기적으로 읽기를 수행해 왔습니다.

   date
   uptime
   free
   ps aux|sort -n +5|tail
   vmstat 5 5

그리고 제가 본 것은 ‘free’ 메모리가 프로세스의 RAM 사용량(RSS)이 증가하지 않는 상태에서 ‘buffer’ 및 ‘cache’ 메모리로 전환되고 있다는 것입니다. 이는 일부 호스팅 제공업체가 이를 쉽게 추적할 수 있게 해주더라도 ‘free’ 메모리를 추적하는 것이 좋지 않은 이유를 보여주는 것 같습니다. 또한 이 경우 메모리 누수가 없다는 것도 보여줍니다.

재부팅 직후에는 다음과 같은 모습을 보입니다:

# free
               total        used        free      shared  buff/cache   available
Mem:         3905344     1560508      996400      179712     1348436     1974692
Swap:        4194288           0     4194288

그리고 얼마 후

# ps aux|sort -n +5|tail
...
1000        1688  0.1  6.5 1006548 256428 ?      Sl   16:44   0:10 unicorn master -E production -c config/unicorn.conf.rb
1000        2189  0.1  8.5 5657760 333248 ?      Sl   16:45   0:06 unicorn worker[3] -E production -c config/unicorn.conf.rb
1000        2113  0.1  8.5 5656608 334352 ?      Sl   16:45   0:07 unicorn worker[2] -E production -c config/unicorn.conf.rb
1000        2044  0.4  8.7 6052196 342380 ?      Sl   16:44   0:23 unicorn worker[1] -E production -c config/unicorn.conf.rb
1000        2006  1.7  9.0 5628640 352492 ?      Sl   16:44   1:33 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  3.1 11.1 6033652 435388 ?      SNl  16:44   2:54 sidekiq 6.5.12 discourse [0 of 5 busy]
# 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
...
 0  0      0 866112 314288 1083816    0    0    32    28  484  621  4  1 95  0  0

sidekiq(435 MByte)과 unicorn(각각 330-350)가 가장 큰 프로세스임을 알 수 있습니다.

시간이 지남에 따라 free RAM과 그 다음 sidekiq RAM(RSS) 사용량이 감소합니다. 이는 페이지 아웃(paged out) 때문으로 추정되며, 과도한 영향은 없습니다 - 머신은 페이지ング 활동을 보이지 않습니다. 대신 버퍼 및 캐시 공간이 증가하는 것으로 보입니다.

# 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
...
 0  0      0 679764 326988 1190840    0    0     0    11  285  396  1  1 98  0  0

약 14시간 후:

# uptime
 10:12:06 up 17:27,  1 user,  load average: 0.04, 0.02, 0.00
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.6 5647908 377424 ?      Sl   Sep05  12:42 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.8 11.3 6431988 444184 ?      SNl  Sep05  18:51 sidekiq 6.5.12 discourse [0 of 5 busy]
# 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
...
 0  0   2048 199972 342480 1576156    0    0     0    17  361  511  2  2 96  0  0

나중에…

# uptime
 19:52:00 up 1 day,  3:07,  1 user,  load average: 0.02, 0.06, 0.01
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.8 5654308 382944 ?      Sl   Sep05  20:44 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.5 11.1 6431668 436340 ?      SNl  Sep05  25:04 sidekiq 6.5.12 discourse [0 of 5 busy]
# 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
...
 0  0   2304 103356 301632 1690136    0    0     0    10  360  511  1  1 98  0  0

나중에…

# uptime
 12:13:09 up 1 day, 19:28,  2 users,  load average: 0.05, 0.06, 0.01
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.1 5654820 358612 ?      Sl   Sep05  31:47 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.3 10.0 6431668 393584 ?      SNl  Sep05  35:08 sidekiq 6.5.12 discourse [0 of 5 busy]
# 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
...
 0  0 284416 281596  77904 1908528    0    0     0    38  315  450  1  1 98  0  0

나중에

# uptime
 13:26:42 up 2 days, 20:42,  1 user,  load average: 0.20, 0.06, 0.02
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.3 5789072 365720 ?      Sl   Sep05  51:54 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.2 10.0 6433332 393472 ?      SNl  Sep05  50:44 sidekiq 6.5.12 discourse [0 of 5 busy]
# 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
...
 0  0 242944  82016  95188 2082180    0    0     0   131  332  488  1  1 98  0  0

나중에

# uptime
 09:21:33 up 3 days, 16:36,  1 user,  load average: 0.13, 0.10, 0.03
# free
               total        used        free      shared  buff/cache   available
Mem:         3905344     1618936      323032      476664     1963376     1619208
Swap:        4194288      250112     3944176
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.3 5789200 363572 ?      Sl   Sep05  67:02 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.1  9.6 6433652 377472 ?      SNl  Sep05  63:14 sidekiq 6.5.12 discourse [0 of 5 busy]
# 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
...
 0  0 250112 321888  56052 1906672    0    0     2    13  293  420  1  0 99  0  0

나중에

# uptime
 13:55:23 up 4 days, 21:10,  1 user,  load average: 0.07, 0.08, 0.02
# free
               total        used        free      shared  buff/cache   available
Mem:         3905344     1638012       98492      481864     2168840     1595004
Swap:        4194288      252928     3941360
# ps aux|sort -n +5|tail
...
1000        1971  1.1  9.5 6434676 371648 ?      SNl  Sep05  80:49 sidekiq 6.5.12 discourse [0 of 5 busy]
1000        2006  1.2  9.5 5658468 373404 ?      Sl   Sep05  88:44 unicorn worker[0] -E production -c config/unicorn.conf.rb
# 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
...
 1  0 252928 101040  86736 2082372    0    0     0    10  333  482  1  0 99  0  0

관찰 내용을 공유해 주셔서 감사합니다. 저도 비슷한 현상을 겪고 있는데, 저희는 2GB 인스턴스를 사용 중이라 여유 메모리가 더 적은 편입니다. 또한 ‘가용’ 메모리와 ‘사용 중’ 메모리의 측정 방식이 항상 유용하지는 않다는 점을 지적해 주셔서 감사합니다.

며칠 전 인스턴스를 재부팅했을 때 초기 메모리 사용량은 1.23GB였습니다. 이후 점차 증가하여 현재는 1.8GB에 도달했습니다. 현재로서는 사이트가 비교적 원활하게 작동하고 있습니다.

사이트의 실제 사용자 수는 많지 않으며, 최근 사용자 가입이나 활동량에 큰 증가도 없었습니다. 지난 한 달 동안 약 20개의 새 토픽, 약 100개의 게시글, 그리고 일일 활성 사용자 약 4명이 있었습니다.

계속해서 상황을 모니터링할 것이며, 인스턴스의 메모리가 다시 한계에 도달하거나 사이트가 다시 느려지거나, 두 가지가 모두 발생하면 여기에 게시하겠습니다.

메모리 문제로 인해 Discourse 업그레이드가 번거로워졌고, 결국 가상 머신을 2GB에서 4GB로 업그레이드했습니다. 이후로 메모리 사용량이 안정되었습니다.