오류가 몇 가지 발생하고 있는데, 이 오류를 본 적이 있고 해결 방법을 아시는 분 계신가요? 윈도우 메모리 문제인 줄 알았는데, 윈도우에 6GB의 여유 공간이 있어도 여전히 발생합니다.
토픽에서 돌아올 때
토픽으로 이동할 때:
이 오류들은 간헐적으로 발생하지만 꽤 자주 나타납니다 
도움 주시면 감사하겠습니다. 다시 시도하면 보통 성공하긴 합니다… 또한 /logs에 이 문제에 대한 내용은 없습니다.
Featured Tiles를 추가했는데, Right Sidebar Blocks를 비활성화하면 문제가 사라집니다. 메모리는 11GB의 여유 공간이 있고 디스크 공간도 충분합니다.
Featured Tiles를 비활성화하고 Right Sidebar Blocks를 활성화하면 문제가 계속됩니다.
여러분과 같은 오류가 발생했는데, 여기에 올렸지만 어떻게 수정해야 할지 모르겠어요 
누군가 아이디어를 가지고 있기를 바랍니다 
브라우저 콘솔에서 오류를 검색해 보겠습니다.
1100줄의 응답을 받았고, 그 중 일부는 다음과 같습니다:
2 deprecation-identify-source.js:15 DEPRECATION: 템플릿이 별도로 해석되는 컴포넌트는 비추천되었습니다. co-located js/ts + hbs 파일 또는 gjs/gts로 마이그레이션하세요. ‘template:components/top-contributors’ 조회를 시도했습니다. [deprecation id: component-template-resolving] 이 기능은 ember-source 6.0.0에서 제거될 예정입니다. https://deprecations.emberjs.com/id/component-template-resolving 를 참조하세요.
post.js:561 
새로운 ‘glimmer’ 게시 메뉴 사용 중!
2deprecation-identify-source.js:15 DEPRECATION: 템플릿이 별도로 해석되는 컴포넌트는 비추천되었습니다. co-located js/ts + hbs 파일 또는 gjs/gts로 마이그레이션하세요. ‘template:components/top-contributors’ 조회를 시도했습니다. [deprecation id: component-template-resolving] 이 기능은 ember-source 6.0.0에서 제거될 예정입니다. https://deprecations.emberjs.com/id/component-template-resolving 를 참조하세요
POST https://discourse.xxxxxx.xxx/mini-profiler-resources/results 429 (Too Many Requests)
Discourse v3.4.0.beta4-dev — https://github.com/discourse/discourse/commits/380910aedd — Ember v5.12.0
deprecation-identify-source.js:15 DEPRECATION: 템플릿이 별도로 해석되는 컴포넌트는 비추천되었습니다. co-located js/ts + hbs 파일 또는 gjs/gts로 마이그레이션하세요. ‘template:components/whos-online’ 조회를 시도했습니다. [deprecation id: component-template-resolving] 이 기능은 ember-source 6.0.0에서 제거될 예정입니다. 자세한 내용은 https://deprecations.emberjs.com/id/component-template-resolving 를 참조하세요.
이것이 원인이 될 수 있습니다. 이 경우, 요청 제한(rate limiting)이 적용되고 있을 가능성이 높습니다.
우측 사이드바 블록이 활성화된 상태에서 더 많은 요청이 발생하는지 개발자 콘솔의 네트워크 탭을 확인해 보세요.
혹시 아시는 분이 계시면 여쭤볼 것이 있습니다:
(1) 저는 관리자(신뢰 수준 4)인데, 왜 “DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL” 설정이 제 IP 기반 속도 제한을 우회하지 않나요?
전역 IP별 속도 제한
이 제한은 Discourse 애플리케이션에 접근하는 모든 고유 IP 주소에 적용됩니다. (파일 시스템이나 CDN에서 직접 제공되는 파일은 제외됩니다)
기본적으로 이 속도 제한은 활성화되어 있으며, 비활성화하거나 보고 모드(reporting mode)로 설정할 수 있습니다.
DISCOURSE_MAX_REQS_PER_IP_MODE: 기본값은 block이며, 이 속도 제한은 기본적으로 적용됩니다. (다른 옵션으로는 warn, warn+block, none이 있습니다)
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: 분당 IP당 요청 수 (기본값 200)
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: 10초당 IP당 요청 수 (기본값 50)
DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: 10초당 IP당 에셋(아바타/CSS) 요청 수 (기본값 200)
DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: Discourse에 접근하는 사설 IP에도 속도 제한을 적용할까요? 기본값은 false입니다.
DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: 이 신뢰 수준 이상의 사용자에게는 IP 기반 속도 제한 대신 사용자별 속도 제한을 사용 (기본값 1)
제한 값을 수정하려면 app.yml 파일의 env 섹션에 원하는 변경 사항을 추가하세요.
아래와 같이 시도해 볼 수 있습니다:
DISCOURSE_MAX_REQS_PER_IP_MODE: warn
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: 600
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: 200
DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: 400
DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: false
DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: 2
또한 nginx 액세스 로그를 확인해 보니 사용자별로 서로 다른 IP 주소가 표시되고 있습니다. (훨씬 이전 주제에서 이것이 문제가 되었던 것을 본 적이 있는데, 당시에는 모든 사용자가 동일한 IP 주소로 접근하고 있었습니다)
위에서 설명한 변경 사항을 적용하고 앱을 다시 빌드해도, 우측 사이드바 블록을 활성화하면 브라우저 콘솔에 속도 제한 경고가 표시됩니다.
예를 들어, DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL의 실제 값을 어떻게 출력하거나 다른 방법으로 확인할 수 있을까요?
또한, 우측 사이드바 블록을 비활성화하면 우측 사이드바 블록이 활성화되어 있을 때와 동일한 속도로 토픽을 탐색해도 브라우저 콘솔에 속도 제한 경고가 표시되지 않습니다.
레이트 리미팅에 대한 이전 토론을 검색해 보시길 권합니다.
이 주제에 대해 깊이 있는 지식을 가지고 있지는 않지만, 제 이해에 따르면 레이트 리미팅은 두 단계로 적용됩니다. 먼저 nginx가 레이트 리미팅을 수행하며(신뢰 수준을 알지 못함), 그 후 rails 앱이 또 다른 보호 계층을 적용합니다.
nginx 레이어에서 레이트 리미트에 도달하고 있다는 가설을 테스트해 보려면 app.yml의 다음 줄을 주석 처리할 수 있습니다.
- templates/web.ratelimited.template.yml
리버스 프록시로 사용하는 nginx에 레이트 리미트를 설정해 두지 않았습니다. 컨테이너가 어떤 일을 하고 있는지 확인하기 위해 제안해 주신 방법을 시도해 보겠습니다.
우측 사이드바 블록에 리더보드(Leaderboard), 상위 생산자(Top Producers), 이벤트(Events)를 로드하고 있습니다.
결과를 보고하겠습니다. 감사합니다.
말씀하신 내용이 맞을 것 같은데요, /var/discourse/templates/web.ratelimited.template.yml 파일에서 이 설정값들을 더 느슨하게 설정하는 좋은 값은 무엇일까요? 단순히 시행착오를 반복해야 하나요?
params:
reqs_per_second: 12
burst_per_second: 12
reqs_per_minute: 200
burst_per_minute: 100
conn_per_ip: 20
run:
다음 값으로 높여 보았습니다:
reqs_per_second: 18
burst_per_second: 18
reqs_per_minute: 400
burst_per_minute: 200
conn_per_ip: 20
여전히 “429 Too Many Requests” 오류가 발생합니다.
리더보드를 제거했는데도 여전히 문제가 발생합니다.
우측 사이드바 블록을 제거하니 더 이상 문제가 발생하지 않습니다 정말 짜증나네요!
상위 기여자(Top Contributors) 사이드바에는 이 문제가 없다는 뜻입니다.
고정된 IP에서 작업하는 경우, IP를 레이트 리미팅에서 제외할 수 있습니다:
첫 번째 테스트를 위해 레이트 리미팅을 완전히 건너뛰는 것을 권장합니다(단, web.ratelimited.template.yml 파일을 사용하지 않으면 됩니다).
nginx 로그를 통해 요청의 출처를 파악할 수 있습니다:
./launcher enter app
less /var/log/nginx/access.log