최근 몇 주 동안 내 디스코urs 설치 환경이 점점 더 느려지고 있습니다. 과거에도 이런 상황이 발생했을 때 앱을 다시 구축하면 도움이 되었습니다. 하지만 지금은 효과가 없는 것 같습니다.
이 포럼에서 조언을 찾아보고, 데이터베이스 최적화(vacuum full verbose, rebuild index, vacuum analyze verbose)도 시도해 보았습니다.
하지만 아무것도 효과가 없으며, 컨테이너를 시작하면 실제로 포럼에 연결할 수 있기까지 정말로 오랜 시간이 걸립니다.
이러한 상황이 계속되면 결국 포럼이 완전히 사용할 수 없게 될 것입니다. 어디서부터 살펴봐야 할지 아이디어가 있으신가요?
데이터베이스 크기는 얼마나 되나요? RAM 용량은 어느 정도인가요?
다음 명령의 출력이 도움이 될 수 있습니다.
vmstat 5 5
(문제가 발생하고 있는 시간에 실행하세요!)
사용 가능한 메모리: (top 출력)
iB Mem : 4041756 total, 108980 free, 3834244 used, 98532 buff/cache
KiB Swap: 1949692 total, 972196 free, 977496 used. 31140 avail Mem
Vmstat 출력: (매우 느리게 로딩되는 동안)
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
9 2 1011424 108300 15308 122392 37 32 145 101 0 0 2 3 93 1 0
5 2 1028312 114696 9976 101252 2104 3904 2176 3915 340 1939 41 38 1 19 0
2 4 1054116 115892 10196 102260 1378 6803 4171 6826 870 1812 23 28 1 48 0
0 4 1011420 257496 10860 108464 3427 3937 6223 3969 829 2788 15 28 2 55 0
6 2 1001844 154328 12988 120800 4366 124 7166 161 742 2947 14 26 2 58 0
hubbe@tymin:~$ 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 4 1004748 85768 13948 114648 37 32 145 101 0 0 2 3 93 1 0
0 6 1033260 108584 10212 101668 1566 6661 4368 6807 497 1990 11 27 0 61 0
12 7 1050808 99524 10708 94852 1932 4551 4854 4625 660 2263 24 32 2 42 0
5 8 1078776 125060 9136 92948 2079 6963 5541 7030 771 2040 17 32 0 51 0
4 3 1004784 168216 10164 103420 2631 1457 4970 1467 617 2136 34 38 1 27 0
참고: 도움이 된다면 제 사이트는 여기서 확인하실 수 있습니다: https://crucible.hubbe.net/
어떻게 확인하나요?
그 서버에 Discourse만 실행되고 있나요? app.yml 파일에서 유니콘(unicorn)을 몇 개로 설정했나요?
유일한 원인은 아니지만, 분명 가장 큰 원인입니다.
메모리 사용량 기준 상위 프로세스 목록입니다:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1818 hubbe 20 0 910068 159724 10272 S 0.0 4.0 0:31.17 ruby
6141 hubbe 25 5 1195492 140180 10080 S 4.2 3.5 11:31.61 ruby
1845 hubbe 20 0 908732 124036 9388 S 2.8 3.1 0:29.94 ruby
1780 hubbe 20 0 910076 82072 3796 S 0.0 2.0 0:28.40 ruby
1937 systemd+ 20 0 360060 25632 21076 S 0.0 0.6 0:00.86 postmaster
2134 systemd+ 20 0 356020 23608 19760 S 0.0 0.6 0:00.13 postmaster
1797 systemd+ 20 0 355840 22620 19404 S 1.4 0.6 0:00.75 postmaster
2092 systemd+ 20 0 356288 21644 17584 S 0.0 0.5 0:00.17 postmaster
2063 systemd+ 20 0 355984 18364 16504 S 0.0 0.5 0:00.20 postmaster
1939 systemd+ 20 0 355904 15668 15232 S 0.0 0.4 0:00.25 postmaster
2131 systemd+ 20 0 353948 14804 13000 S 0.0 0.4 0:00.02 postmaster
38770 root 20 0 689760 12940 0 S 0.0 0.3 434:00.34 dockerd
43876 root 20 0 16492 9428 1608 S 0.0 0.2 3:34.89 roxen
5728 hubbe 20 0 574796 8136 2064 S 0.0 0.2 0:58.94 ruby
37533 root 20 0 593420 5848 1020 S 2.8 0.1 539:40.11 containerd
5689 systemd+ 20 0 96432 5832 1672 S 0.0 0.1 3:54.43 redis-server
2196 www-data 20 0 166248 4924 2580 S 0.0 0.1 1:18.03 nginx
2197 www-data 20 0 165972 4484 3168 S 0.0 0.1 1:29.32 nginx
이 목록의 거의 모든 항목은 roxen을 제외하고 discourse와 관련이 있습니다.
UNICORN_WORKERS가 내 app.yml에서 주석 처리되어 있습니다.
게시글 저장은 특히 타임아웃이 발생하여 실패할 가능성이 높은 것 같습니다.
이것이 문제의 원인을 파악하는 데 어떤 단서가 될지는 확실하지 않습니다.
해당 vmstat 출력 결과는 현재 상태에서 RAM이 충분하지 않음을 보여줍니다.
Discourse가 정상적으로 작동하고 모든 것이 정상일 수도 있지만, 데이터가 4GB의 RAM으로는 부족할 정도로 성장했을 가능성도 있습니다.
또는 어떤 문제가 발생하여 사용되지 말아야 할 RAM이 많이 사용되고 있을 수도 있습니다.
크기를 파악하는 한 가지 방법은 첨부 파일 없이 백업을 수행하여 그 크기를 확인하는 것입니다.
미니 프로파일러(mini-profiler)가 어떤 데이터베이스 작업이 이렇게 오래 걸리는지 단서를 제공해 줄 수 있습니다.
예산이 충분하다면 RAM을 2배로 늘리십시오. (제공 업체에서 RAM만 늘리고 스토리지 용량은 그대로 유지하는 옵션이 있다면, 이를 선택하면 되돌릴 수 있거나 일시적인 변경이 될 수 있습니다.)
정확한 지적입니다.
RAM을 더 늘릴 수 없다면, db_shared_buffers 값을 더 낮게 설정(예: 128MB 이하)하고, UNICORN_WORKERS를 당분간 2로 제한해 보세요. 스왑을 최대한 빨리 멈춰야 하기 때문입니다.
62.5 MB
제 호스팅 제공업체에서 추가 RAM은 가격이 꽤 비싸기 때문에, 먼저 다른 옵션들을 검토해 보겠습니다. (또한, 설정을 변경하면 기존에 적용받던 할인가가 깨질까 봐 걱정되기도 합니다…)
db_shared_buffers를 128Mb로, UNICORN_WORKERS를 2로 변경했습니다.
이 설정들이 적용되려면 launcher app stop / start만 실행하면 충분한가요?
미니 프로파일러란 무엇이며, 어떻게 사용하나요?
키보드에서 Alt+P를 누르면, 이후의 포럼 동작 시 포럼 배너 바로 아래(제 경우에는 오른쪽에) 타이밍 문자열이 표시됩니다. 이 타이밍을 클릭하면 몇 가지 통계가 포함된 팝업 창이 나타납니다.
저는 1GB의 RAM으로 실행 중인데, 제 환경과 거의 비슷합니다. 저는 2천 개의 주제, 1만 5천 개의 게시물, 500명 이상의 가입자를 보유하고 있습니다.
귀하의 Discourse 환경의 이력은 어떻게 되나요? 과거에 성능을 위해 특정 테이블에 인덱스를 생성해야 한다는 이야기를 희미하게 기억합니다.
플러그인은 어떻게 되나요? 더 빠르게 실행되는지 확인하기 위해 안전 모드(safe mode)에서 동작을 실행해 볼 수 있을까요?
또한 전체 프로세스 트리를 붙여넣는 것도 유용할 수 있습니다:
ps auxf
제 프로세스 트리는 여기에 게시했습니다.
Seeking help for discourse installation
이런 통계를 쉽게 확인할 수 있는 곳이 있을까요?
보통 제가 보는 통계는 지난 1일 또는 1주일 동안의 활동 내용만 보여주는데, 전체 합계는 표시되지 않더라고요.
'이력’이라는 표현이 정확히 무엇을 의미하는지 잘 모르겠습니다. 하지만 제 서버는 2021년 3월에 시작했습니다.
첫인상은 안전 모드가 더 빠르다는 느낌이 들지 않는다는 것입니다. 미니 프로파일러와 함께 조금 더 실험해 보겠습니다. 이 인상이 유지되는지 확인해 보겠습니다.
ps auxf 출력을 첨부했습니다.
auxf.txt (20.1 KB)
/about 페이지에 전체 기간(all-time)에 대한 열이 있습니다.
컴퓨터를 1년 넘게 재부팅하지 않은 것 같네요. 보안 업데이트와 함께 재부팅을 하는 것이 좋을 것 같습니다. 재부팅이 문제를 해결해 줄 수도 있습니다.
서버가 하이퍼바이저로 설정되어 있는 것 같고, 제 서버는 LXC로 설정되어 있습니다. 이게 중요한지 모르겠어요. (제 시스템에는 /usr/bin/lxcfs 프로세스가 보이지만, 그쪽에는 없고, 그쪽에는 hv_vss_daemon 프로세스가 보이지만, 제 시스템에는 없거든요.)
그리고 df -T와 swapon의 출력을 공유해 주실 수 있을까요?
1.3k 주제, 24.7k 게시물, 631 가입자, 7.1k 좋아요
리눅스 머신을 재부팅하는 것이 보통 큰 도움이 되지는 않지만, 시도해 볼 수는 있겠네요.
이 부분에 대해서는 회의적인 태도에 동의합니다! 하지만 무심코 제안한 것은 아닙니다. 장기간 운영되던 시스템이 재부팅으로 실제로 개선된 사례를 본 적이 있습니다. (수정: 여기, 다만 그건 별개의 상황이었습니다.)
미니 프로파일러가 게시글 저장에 대해 이렇게 보고했습니다:
약 30초가 걸렸습니다.