저는 작은 서버(1GB RAM)와 작은 사이트(공식 Discourse 설치로 거의 8년째 운영 중)를 운영하고 있습니다. 디스크 스왑이 기대했던 것보다 많이 일어나서 메모리 사용량을 확인해 보았습니다.
메모리 사용량을 제한하고(스왑을 줄이고)자 언젠가 유니콘(unicorn) 수를 2로 설정해 두었다는 것을 발견했습니다. 현재 Discourse 버전은 3.1.0입니다.
하지만 htop을 실행하면 20개의 유니콘이 실행 중임을 확인했습니다(워커 0이 10개, 워커 1이 10개).
제가 무엇을 놓치고 있는 걸까요? app.yml에는 2로 명시되어 있는데 왜 20개의 유니콘이 실행되고 있는 것일까요?
또한 메모리 사용량을 줄이는 다른 방법이 있을까요(예를 들어 db_shared_buffers를 128MB로 줄이면 어떤 부작용이 있을까요)? Sidekiq의 메모리 사용량도 줄일 수 있을까요?
아래는 vmstat 5 5 결과입니다.
free -h 결과입니다.
htop이 프로세스가 아니라 스레드를 표시하고 있는 것 같습니다. 어쨌든, htop에서 보이는 내용은 당신과 동일하지만, 아래 명령을 실행하면 unicorn worker가 두 개만 보입니다.
ps uaxf|egrep unicorn.?worker
또한 제 free 출력도 당신과 비슷합니다:
# free -h
total used free shared buff/cache available
Mem: 985M 782M 61M 60M 141M 32M
Swap: 2.0G 992M 1.0G
참고로, swap 사용량이 있는 것 자체는 문제가 아닙니다. 실제로 중요한 것은 스와핑(페이징)이 일어나는 것입니다. vmstat 5 5를 실행하고 si와 so 열을 확인해 보세요.
# 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 1041832 63176 5716 127408 367 325 601 393 8 10 2 1 95 2 0
0 0 1041576 60976 5724 127408 399 0 399 21 212 653 1 1 96 2 0
0 0 1043544 77036 2296 120688 807 803 807 837 404 1144 1 2 94 3 0
0 0 1043288 65040 3704 129476 254 0 2292 5 255 780 1 1 96 2 0
0 0 1048736 81936 2916 119016 762 1499 919 1565 470 1171 3 2 90 5 0
1000을 넘는 값은 보고 싶지 않지만, 너무 걱정하지는 않습니다. 두 번째 실행에서는 훨씬 안정적인 모습을 보였습니다:
# 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 1048452 82712 2532 120848 367 325 601 393 8 10 2 1 95 2 0
0 0 1047684 74552 2548 124816 285 0 1049 10 230 655 2 1 95 2 0
0 0 1046660 66556 3692 129008 196 0 1261 16 219 672 1 1 96 2 0
1 0 1046404 65812 3700 129284 54 0 97 13 137 364 1 0 98 0 0
0 0 1046148 65280 3700 129288 50 0 50 3 132 344 1 0 98 0 0
수정: htop에서 H 키를 누르면 스레드에서 프로세스로 전환됩니다:
CPU[ 0.0%] Tasks: 66; 1 running
Mem[||||||||||||||||||||||||||||||||||||||||||||||||||824M/985M] Load average: 0.19 0.12 0.05
Swp[|||||||||||||||||||||||||||||| 1015M/2.00G] Uptime: 52 days, 00:50:42
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
13246 1000 20 0 966M 362M 6448 S 0.0 36.8 51:01.52 unicorn worker[0] -E production -c config/unicorn.conf.rb
13237 1000 25 5 1004M 194M 3780 S 0.0 19.8 22:38.19 sidekiq 6.5.9 discourse [0 of 5 busy]
13258 1000 20 0 919M 70176 3632 S 0.0 7.0 5:02.87 unicorn worker[1] -E production -c config/unicorn.conf.rb
12412 systemd-r 20 0 212M 60928 56916 S 0.0 6.0 0:00.23 postgres: 13/main: discourse discourse [local] idle
12818 systemd-r 20 0 212M 39228 34868 S 0.0 3.9 0:00.07 postgres: 13/main: discourse discourse [local] idle
12719 systemd-r 20 0 211M 28400 25336 S 0.0 2.8 0:00.03 postgres: 13/main: discourse discourse [local] idle
13117 1000 20 0 541M 13768 2048 S 0.0 1.4 1:08.11 unicorn master -E production -c config/unicorn.conf.rb
수정: 저는 초기에 db_shared_buffers: "128MB"를 설정했으며, 이로 인해 어떤 문제도 겪지 않았습니다.
감사합니다, 매우 도움이 되었습니다. 유니콘 워커를 하나만 사용하는 것의 단점은 무엇인가요? 응답 시간이 개선될까요, 아니면 악화될까요 (유니콘 워커 1개는 수신 연결 1개만 처리할 수 있나요, 즉 워커 2개라면 단일 수신 연결을 더 빠르게 처리할 수 있나요?)? 분당 연결 수가 몇 개뿐인 경우를 가정할 때입니다.
웹사이트를 둘러볼 때 vmstat 5 5의 출력은 다음과 같습니다. 스와핑을 줄이는 방법에 대한 제안이 있을까요 (swappiness를 10으로 설정했습니다)?
수정: 성능에 영향을 주지 않으면서 sidekiq의 메모리 사용량을 줄이는 방법이 있을까요?
RAM을 더 늘린다면 사이트가 더 빨라질 것 같습니다. 하지만 응답 시간이 문제가 되지 않는다면 큰 문제가 아닙니다. 본인의 비용 대비 효과(cost/benefit)를 따져보시면 됩니다.
MKJ’s Opinionated Discourse Deployment Configuration을 읽어보시는 것도 좋습니다. 좋은 아이디어인 시스템 레벨 커널 튜닝 항목이 몇 가지 있습니다. 실제로 차이가 날지는 모르겠습니다.
확실하지는 않지만, 각 유니콘(unicorn) 프로세스가 하나의 요청을 처리한다고 생각합니다. 따라서 유니콘이 하나뿐이고, 첫 번째 요청이 완료되기 전에 두 번째 요청이 들어오는 트래픽이 있다면 두 번째 요청은 기다려야 합니다. htop 출력 결과에서 하나의 유니콘이 다른 유니콘보다 CPU 사용 시간이 10배 더 높게 나타나고 있습니다. 이는 제 포럼이 90%의 시간은 유니콘 하나면 충분하고, 10%의 시간에는 두 번째 유니콘이 도움이 된다는 것을 의미한다고 봅니다. 세 번째 유니콘을 추가할 필요성을 느끼지 못하며, 하나만 남기는 것이 포럼 멤버들에게 큰 문제가 되지 않을 수도 있습니다. 하지만 그럴 이유도 없습니다. 메모리를 사용하긴 하지만, 유휴 상태라면 스왑 아웃(swapped out)되므로 큰 문제가 아닙니다. 가상 메모리 시스템이 처리하게 두면 됩니다.
수정: swappiness 값을 튜닝해 본 적이 없습니다. 현재 60으로 설정되어 있습니다. I/O 버퍼를 위해 더 많은 RAM을 확보할 수 있다면 더 공격적인 스왑이 유용할 수도 있습니다. 확실하지는 않습니다.
db_shared_buffers와 UNICORN_WORKERS를 변경한 경우, ./launcher rebuild app로 다시 빌드하지 않고 재시작만 할 수 있는 방법이 있나요?
