Tuning a Discourse server for performance

제품 지원 자체 호스팅
1

Are there any guides (or Topics here on the forum) that provide tips on tuning a server that hosts Discourse sites for performance?

I ran the ./Discourse-set and it set a quarter of the ram (to 4096mb) and added 8 unicorns workers - but is there anything else we can do, or tweak these?

The server has 64GB ECC Ram and two 512GB NVMe SSDs (in a raid array). Looking at top, only around 5GB of memory us being used, with 57392484 avail Mem. It does run other non-Docker sites, but they don’t use up much of the resources and MySQL is already tuned for a large 2GB db. Load averages are generally below 1.0 (usually around 0.50 up to 1.0 with occasionally going over). No problems have been reported, but I am hoping to utilise as much of the server as possible.

I’m wondering whether to start by doubling db_shared_buffers… and what about #db_work_mem: "40MB" which is currently commented out.

All info/tips appreciated :smiley:

2

저도 이 문제를 위해 포럼을 검색해 봤습니다.

3

튜닝에 관한 몇 가지 주제(또는 과거 주제)가 있습니다. 성공적인 주제들은 (이 주제 제외) 대부분 사용 가능한 리소스, db_shared_buffers 및 기타 설정, 그리고 발생하는 문제점에 대해 구체적인 세부 정보를 제공하고 있으며, htop이나 기타 도구에서 가져온 출력 결과를 포함하는 경우도 있습니다. 데이터베이스 크기는 얼마인가요? 어떤 문제를 겪고 계신가요? (새로운 주제를 시작하는 것이 더 좋을 수 있습니다)

4

감사합니다! 아직까지는 문제가 없습니다. 다만 메모리 사용량이 높은 편인데, 포럼 트래픽은 많지 않은 상태입니다. 저는 평소 선제적으로 생각하고 어떤 리소스가 가장 많이 사용되고 있는지 확인하는 습관이 있습니다. 이 서버는 3GB VPS로, 6코어 @ 3.5 GHz 사양입니다. 속도는 느리지 않고 오히려 매우 빠릅니다. 다만 메모리 사용량이 앞으로 문제가 될 수 있을 것 같아 어떤 부분을 조정할 수 있을지 궁금해서요.

Ruby on Rails 애플리케이션 일반 및 최적화에 대해 좀 더 찾아보겠습니다. 다시 한번 감사합니다.

5

말씀하신 '사용량’이 어떤 기준을 의미하는지에 따라 정상적인 경우일 수 있습니다. 하지만 3GB라면 ./discourse-setup을 실행했을 때의 추측값이 충분히 좋아서(Good Enough) 추가로 튜닝할 부분이 많지 않을 가능성이 큽니다.

6 
free -h
              total        used        free      shared  buff/cache   available
Mem:          2.9Gi       1.8Gi       167Mi       100Mi       1.0Gi       895Mi
Swap:         1.0Gi       587Mi       436Mi

가용 메모리는 약 900M입니다. 아직은 문제가 되지 않습니다. 하지만 문제를 해결하기 위해 여기에 온 것이 아닙니다. 향후 가용 메모리가 부족해지면 어떻게 해야 하는지 알고 싶습니다. 물론 메모리를 더 추가하는 방법도 있지만요.

image
image1469×365 105 KB

7

이 단계에서는 실제로 할 수 있는 일은 RAM을 더 추가하는 것뿐입니다. 8GB 또는 16GB를 갖추고 있다면 몇 가지 조치를 취할 수 있습니다. 굳이 무언가를 해야 한다면 스왑 공간을 1GB 더 추가하는 것을 고려해 볼 수 있지만, 아마도 큰 문제가 없을 것입니다.

./discourse-setup을 실행했다면 2GB의 스왑파일이 생성되었을 것입니다. 재빌드(rebuild)를 수행할 때 문제가 발생할 수 있습니다.

8

네, 설치 기본값을 UNICORN_WORKERS: 8에서 UNICORN_WORKERS: 4로 변경하니 사용 가능한 메모리 용량이 거의 두 배로 늘었습니다.

그 후: sudo ./launcher rebuild app

이제 PostgreSQL 모니터링을 설정하고 어떤 일이 일어나고 있는지 확인해 보겠습니다.

9

어떤 자원이든 병목 현상이 발생하는 시점이 항상 있습니다. 하지만 현재 서버는 제 눈에 보기엔 상당히 과하게 과대 규격화(overdimensioned)되어 있습니다.

Unicorn 프로세스가 더 많으면 더 많은 메모리를 사용하게 됩니다.
사이트의 트래픽이 더 많으면 더 많은 Unicorn 프로세스가 필요합니다.

모든 Unicorn 프로세스가 CPU 사용률 0.0%를 보이고 있고, 실제로 무언가를 수행하는 것처럼 보이는 것은 worker[0]뿐인 것 같습니다.

Unicorn의 수를 줄여 메모리를 절약했습니다. 이건 좋은 일입니다. 어차피 그들을 사용하지 않았기 때문입니다. 하지만 사용 가능한 메모리(available memory)가 많다는 것은 실제로는 나쁜 일입니다. 잘못된 변수를 최적화하고 있는 것입니다.

사용되지 않는 메모리는 아무것도 산출하지 못합니다. 이는 사용하지 않는 것에 대해 비용을 지불하고 있다는 뜻입니다. 항상 2GB의 사용 가능한 메모리가 있다면*, 서버를 다운사이징하여 비용을 절약할 수 있습니다.

*) Discourse를 다시 빌드할 때는 더 많은 메모리가 소비되므로, 재빌드 중에 사용 가능한 메모리가 얼마나 되는지 확인해야 합니다. 실무적으로는 총 메모리가 2GB 미만으로 내려가지 않도록 하거나, Pfaffman이 이미 말했듯이 충분한 스왑(swap) 공간이 있는지 확인하세요.

10

그렇지 않습니다. 아무 일도 하지 않는 “자유(Free)” 메모리가 나쁜 것입니다. 하지만 “사용 가능한(Available)” 메모리는 시스템이 사용하고 있다가 쉽게 해제할 수 있는 메모리이며, 이는 좋은 것입니다. :slight_smile:

공식적인 정의는 다음과 같습니다:

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

출처: man free

아래 스크린샷과 같이, 자유 메모리는 거의 변하지 않았습니다. 따라서 시스템 메모리의 거의 모든 부분이 사용되고 있습니다. 그러나 필요할 때 해제할 수 있는 사용 가능한 메모리가 더 많기 때문에, 시스템이 스왑을 덜 수행하게 됩니다.

image
image1423×405 125 KB

…네, 트래픽이 변경을 요구할 때까지, 사용되지 않는 메모리는 해제해 두는 것을 선호합니다.

다시 한번 감사합니다.

11

여기서 나쁘다는 비용을 들이지만 아무것도 얻지 못한다는 의미인 것 같습니다. 이는 꽤 일반적인 생각인데, 더 많은 리소스가 필요하면 비용도 더 들기 때문이며 RAM은 해당 식에서 비용이 많이 드는 부분이니까요.

또한 낭비할 돈이 많지 않다면, 너무 많이 지불하는 것은 다소 멍청한 일입니다 (핀란드식 표현이니 오해 마세요 :rofl: )

12

네, 맞아요, 가용 메모리에 관해서요. 그런데 "가용 메모리가 실제로는 나쁜 일"이라는 말… 제가 진짜 지적하고 싶었던 바로 그 부분이었습니다. :slight_smile: