동의합니다. 아무도 읽지 않는 콘텐츠의 가치는 무엇인가요? 그리고 누가 10,000개의 게시글을 처음부터 끝까지 정성 들여 읽겠습니까? 
일부 주제들은 시간이 지나면 완전히 사라지는 일시적인 대화일 수 있습니다. 과거에 우리가 '빠른 차선(fast lane)'과 ‘느린 차선(slow lane)’ 트래픽이라고 부른 것과 같은 개념이죠.
소규모 업데이트:
마킹된 항목 이상을 모두 닫기로 보고 및 합의한 후 (한계를 재설정), 성능이 훨씬 좋아졌습니다. 여전히 "극심한 부하로 인해, 일시적으로 로그아웃된 사용자가 보는 것처럼 표시되고 있습니다"라는 메시지가 나타나지만, 이전보다 상당히 줄었습니다.
이와 관련하여:
- 그 거대한 테이블을 줄이는 방법에 대해 조사해 주신 수고에 진심으로 감사드립니다.
- 우리가 놓치고 있을 수 있는 다른 "성능 팁"이나 "설정"이 있을까요? “고급” 설정이더라도 도움이 되시면 감사하겠습니다.
다시 한번, 도움과 피드백을 주신 모든 분들께 깊은 감사를 드립니다.
Postgres 12는 @falco의 테스트에서 테이블과 인덱스 크기를 20% 줄여주므로 도움이 될 것입니다.
그것에 대해 아직 목표 일정이 있나요?
오늘 벤치마크를 시작했습니다.
Meta에서 잠시 실행을 지켜봐야 합니다. 전체 배포 전에 성능 저하가 없는지 확인하기 위해서입니다.
다시 이 문제를 언급하게 되어 죄송합니다. 하지만 이것은 PostgreSQL 마이그레이션과는 별개의 문제입니다. (저는 아직 데이터베이스 크기로 인해 마이그레이션을 진행할 수 없습니다.)
마지막 재구축 이후로 데이터베이스 크기가 계속 증가하고 있습니다:
마지막 재구축은 5월 17일에 이루어졌으며, 그 이후로 DB 크기가 멈추지 않고 증가하여 57.3GB에 달했습니다. 큰 용량을 차지하는 부분은 post_timings 테이블입니다.
제 주요 문제는 PostgreSQL 업데이트(인덱스 크기를 20% 줄여주지만 장기적으로는 이 문제를 해결하지는 못함)를 시도하고 있다는 점입니다. 여기 스태프의 댓글에 따르면 이 정도 크기는 정상적인 범위가 아니라고 하므로, 크기는 계속 증가하여 유지 관리 비용이 악몽처럼 비싸질 것입니다. 시간이 지날수록 더 증가하여 유지 관리가 지옥이 되는 악순환이 만들어집니다. 따라서 제 주요 문제는 여전히 유효하며, 이 post_timings 문제를 해결할 방법이 있을까요? 삭제해야 할 것이 있나요?
테이블 압축 같은 것이 가능한가요?
도움 주신 모든 분들께 감사드립니다.
그 시점에서는 어쩔 수 없는 부분이 있습니다. 포럼이 정말로 크다면, timings 테이블도 덩달아 커질 수밖에 없습니다.
Meta는 정말 오래된 인스턴스이지만, 중간 규모이며 post_timings 테이블이 4GB로 비교적 작습니다. 반면, 2년 미만인 다른 인스턴스를 호스팅하고 있는데, 해당 인스턴스의 post_timings 테이블은 이미 100GB를 넘었을 것입니다.
큰 포럼을 호스팅하는 것은 반드시 더 많은 비용이 들며, 오늘날에는 이를 피할 방법이 없습니다.
데이터베이스를 20달러짜리 독립형 드롭렛(80GB 디스크)으로 옮기고, 웹 서버를 10달러짜리 드롭렛에 두는 것은 어떨까요? 상당히 큰 커뮤니티로 보이는 곳에 대해 월 30달러의 비용은 합리적인 금액으로 보입니다.
도와주셔서 정말 감사합니다, @Falco.
음, 네, 말씀드렸듯이 공간(공간 절약)에 마법은 없기 때문에 물어본 겁니다. 파티션 분할을 알아보고 있는데, 그렇게 하면 성능 문제(긴 이야기인데, 테스트 내용을 기록하고 있으니 나중에 여기서 공유해서 다른 분들도 유용하게 쓰실 수 있게 하려 합니다) 때문에 앱 쪽이 너무 느려질 것 같습니다.
제가 요청드린 백업 복구 관련 테스트를 해봤는데, 생각컨대 이 상황을 활용할 수 있을 것 같습니다. 바로 확인할 수 있는 것은 디스크 사용량이 30% 줄었다는 점인데(누락된 부분이 없는지 확인하기 위해 아직 몇 가지 테스트를 진행 중입니다), 하지만 이 접근 방식에는 작은 문제가 있습니다. 즉, 즉각적인 이점이 크긴 하지만 일부 문제가 발생할 수 있습니다(저장된 이미지 관련해서 캐시되는지 아예 작동하지 않는지 확실하지 않아서 더 그렇습니다. 그리고 네, 백업에는 이미지가 포함됩니다).
OP(원글)를 업데이트할 수 있도록 메모를 하고 있습니다. 여기서는 성능을 걱정하시는 분들을 위해 제가 지금까지 수정한 내용들과 관련된 짧은 노트 시리즈를 추가하는 것이 제 계획입니다.
기술적인 관점에서 볼 때, 이 문제를 해결하기 위해 “자동 삭제” 타이머를 적용하는 것이 좋은 해결책일까요?
사실 꽤 좋은 아이디어이고, 사용성 문제를 해결해 줍니다(앞서 말했듯이, 아무도 1만 개의 메시지를 읽지 않으니까요). 따라서 가장 큰 질문은 이것이 서버와 데이터베이스에 과부하를 주지 않는다는 것입니다.
9000개의 답변이 있는 토픽에서 약 8600개가 삭제된 상태가 성능에 좋은지 확신이 서지 않습니다. 하지만 어딘가에서는 그렇게 보일 것 같네요. @eviltrout님은 어떻게 생각하시나요?
처음에는 "숨김"된 게시글이 일정 시간이 지나면 데이터베이스에서 완전히 삭제된다고 생각했지만, 이제 보니 그런 것 같지 않네요.
따라서 성능 측면에서 제 아이디어로는 문제를 해결할 수 없겠습니다.
이 데이터를 "정리"할 수 있는 방법이 있을까요?
삭제된 게시글은 소프트 삭제됩니다. 그러나 이러한 게시글은 여전히 인덱싱되므로, 여러 개를 한꺼번에 삭제하면 일부 개선 효과를 볼 수 있습니다. 다만, 저는 이를 권장하지 않습니다. 게시글이 너무 길어질 경우 새 주제로 이동할 수 있는 방법이 있다면, 그것이 더 나은 해결책이 될 수 있습니다.
이게 무슨 뜻인가요? 데이터베이스와 웹 앱을 별도의 서버에 배치하면 오히려 성능이 향상되어야 합니다. 서버 간에 일부 지연(latency)은 발생하지만, Unicorn과 Postmaster가 CPU와 RAM을 두고 경쟁하지 않아도 되거든요.
서버들이 같은 DO 리전에 있는지 꼭 확인하세요 
죄송합니다, 말씀이 맞습니다. 그렇게 하면 둘 다 자유롭게 사용할 수 있고, 단일 머신에 모두 올리는 것보다 더 나은 성능을 낼 수 있겠네요. (저는 단일 머신에서 사용하는 리소스와 지금까지 적용해 온 튜닝을 기준으로 비교하고 있었습니다.)
사실 아주 좋은 아이디어네요. 제가 겪고 있는 “데이터 컨테이너를 다시 빌드할 수 없음” 문제를 해결해 보고, 그걸로 이 여정에서 다음 단계로 넘어가 보겠습니다.
이 주제에 대해 머리가 지끈거릴 정도로 검색해 보았지만, 이를 이상적으로 수행하는 방법에 대한 문서를 찾지 못했습니다. 그런 가이드가 존재합니까?
우리는 표준 단일 VPS 설치 환경에서도 한계에 부딪히기 시작하고 있습니다. 우리의 다소 독특한 딜레마는 하키 경기 중 발생하는 게임 채팅입니다. 이 채팅은 활동/부하에 급격한 스파이크를 유발하며, 경기 중 특별한 일이 발생하면 그 정도가 더욱 심해집니다.
가장 바쁜 순간을 견딜 수 있을 만큼 충분히 강력한 것이 필요할 것 같습니다. 아니면 이러한 시간대에 성능을 높이는 방법을 찾아야 합니다. 시간당 과금되는 VPS를 찾아보는 것도 좋은 방법입니다. 이전 팁을 이어가자면, 게임이 있을 때 몇 시간만 과금하는 매우 강력한 VPS로 웹 컨테이너를 이동하는 것이 하나의 해결책이 될 수 있습니다.
다음과 같이 진행해야 합니다:
-
PostgreSQL을 다른 곳에 실행하세요 (드롭렛을 사용하거나 Worry-Free Managed Database Hosting | DigitalOcean 같은 호스팅 서비스를 이용), 그리고 데이터를 그곳으로 이동하세요.
-
별도의 PostgreSQL 서버와 함께 Discourse 실행하기 문서를 따르세요.
그리고 이걸 Discourse의 컨테이너화된 제품, 즉 Web_only와 data를 사용해서도 달성할 수 있겠죠?
제 경험상 현재 어떤 방식으로도 이 문제를 직접적으로 해결할 수 없거나 선형적인 해결책이 존재하지 않습니다. 실제로 이 문제를 해결하기 위해 각 요소를 다른 머신으로 분리하는 것만으로는 즉각적인 해결책이 되지 못합니다.
저희도 큰 이벤트(예: @ljpp 님이 말씀하신 게임 등)가 발생하면 심각한 트래픽 급증과 함께 "사이트가 매우 혼잡하여 로그인하지 않은 사용자처럼 표시됩니다"라는 메시지를 경험하고 있습니다. 이는 해당 토픽에 있는 사용자들뿐만 아니라 사이트 전체의 성능을 저하시킵니다.
그래서 저는 분리된 구성과 “대형 머신” 구성 두 가지를 시도해 보았으나, 두 경우 모두 이러한 유형의 문제가 발생했습니다. 제 인스턴스는 Prometheus로 모니터링되고 로그는 Grafana 등을 통해 확인 가능하므로 하드웨어/컨테이너 성능에 대해 매우 세밀하게 파악할 수 있으며, 어떤 조치를 취하든 결국 문제가 발생한다는 것을 확인할 수 있습니다.
뒤에 대형 머신을 배치하면 문제를 약간 지연시킬 수는 있지만, 결국 오류와 세션 끊김 현상이 발생하며, 디스크, CPU, RAM을 막론하고 머신의 사용률은 거의 0%에 가까울 것입니다. 이는 "기본 설치"와 “2컨테이너” 설치 모두에서 발생하는 현상입니다.
서로 다른 머신을 사용하는 경우에도 문제는 동일합니다. 머신 유형이 동일하거나, 하나가 “CPU 최적화”, 다른 하나가 "디스크 최적화"인 등 어떤 조합이든 마찬가지입니다. 여기에 두 머신 간 연결의 추가적인 장애 요인까지 더해야 합니다. 이 연결은 반드시 지연이 발생하며, 지연의 양은 연결 설정 방식과 두 머신 간의 물리적 거리에 따라 달라질 수 있지만, 결국 동일한 동작을 보일 것입니다.
참고로, Babel 플러그인 같은 경우에도 이러한 유형의 동작이 발생하지만, Babel 플러그인은 "채팅"이 실제로는 숨겨진 토픽임에도 불구하고 훨씬 더 많은 “동시” 쓰기를 처리할 수 있는 것으로 보입니다. 그 차이는 토픽이 어떻게 표시되고 “새로 고침”/"검색"되는지에 있습니다. 이러한 동작상의 차이는 제가 이 문제를 FrontEnd 측면의 문제(제 전문 분야는 BackEnd이므로 FrontEnd는 전문 영역이 아닙니다)로 인해 앱이 "크래시"하는 것과 관련된 애플리케이션 레벨의 상관관계로 결론 내리게 했습니다. 1분 안에 수십 개의 메시지가 쌓이는 상황에서 게시물을 작성하고 토픽이 "자동 업데이트"되기를 기다리는 사용자들의 작업이 그 원인이 되는 것입니다.
여기에 인간적인 요인도 추가해야 합니다. 사람들이 사이트가 "느리다"고 느끼거나 토픽이 "적당히 빨리 업데이트되지 않는다"고 생각하면 F5 키를 무차별적으로 눌러 더 많은 부하를 가합니다. 그런 부분까지 "교육"시키기는 정말 어렵습니다.