bizotto
6월 9, 2023, 9:54오전
1
안녕하세요,
저는 3개의 OpenShift 배포 환경(각각 Redis(7.0.10), Postgres(13.10), discourse(stable 3.0.3)용)를 구축해 두었습니다. 배포 직후에는 모든 것이 정상적으로 작동하지만, 몇 시간 또는 며칠이 지나면 sidekiq 프로세스(UNICORN_SIDEKIQS=3)가 멈추게 됩니다. 몇 가지 관찰한 사항이 있는데, /shared/log/rails目录下에 sidekiq.log 파일이 생성되지 않고 있으며, 이것이 sidekiq가 자동으로 재시작되지 않는 원인이라고 생각합니다:
root@discourse-b9f766dcf-52zjq:/var/www/discourse# ls -laF /shared/log/rails/
total 32
drwxr-xr-x. 2 nobody www-data 4096 Jun 9 08:57 ./
drwxr-xr-x. 3 root root 4096 May 30 06:16 ../
-rw-r--r--. 1 nobody www-data 16082 Jun 9 09:28 production.log
-rw-r--r--. 1 nobody www-data 1345 Jun 9 09:02 unicorn.stderr.log
-rw-r--r--. 1 nobody www-data 204 Jun 9 09:02 unicorn.stdout.log```
sidekiq가 멈추면 host/logs에서 다음과 같은 메시지를 볼 수 있습니다:
Info:
Sidekiq is consuming too much memory (using: 530.35M) for 'discourse.internal.odencluster.com', restarting
backtrace:
config/unicorn.conf.rb:163:in `check_sidekiq_heartbeat'
config/unicorn.conf.rb:243:in `master_sleep'
unicorn-6.1.0/lib/unicorn/http_server.rb:295:in `join'
unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
/var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'
그 후 discourse pod 로그에서 다음과 같은 메시지를 확인할 수 있습니다:
(48) Reopening logs
(48) Reopening logs
(48) Reopening logs
그러나 /shared/log/rails/ 아래에 sidekiq.log가 없기 때문에 재시작이 이루어지지 않습니다.
저는 Rails에 대한 지식이 거의 없어서 문제 해결이 어렵습니다. 하지만 sidekiq가 일시 정지 상태는 아니라는 것을 확인했습니다:
[1] pry(main)> Sidekiq.paused?
=> false
수동으로 시작하면 정상적으로 작동합니다:
2023-06-09T09:47:15.556Z pid=195386 tid=449q INFO: Booting Sidekiq 6.5.8 with Sidekiq::RedisConnection::RedisAdapter options {:host=>"redis", :port=>6379, :namespace=>"sidekiq"}
2023-06-09T09:47:20.528Z pid=195386 tid=449q INFO: Booted Rails 7.0.4.3 application in production environment
2023-06-09T09:47:20.528Z pid=195386 tid=449q INFO: Running in ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]
2023-06-09T09:47:20.528Z pid=195386 tid=449q INFO: See LICENSE and the LGPL-3.0 for licensing details.
2023-06-09T09:47:20.528Z pid=195386 tid=449q INFO: Upgrade to Sidekiq Pro for more features and support: https://sidekiq.org
이 문제를 해결하는 데 도움이 될 것이라고 생각하는 몇 가지 사항이 있습니다:
/shared/log/rails/sidekiq.log 파일을 생성하도록 하는 방법은 무엇인가요?sidekiq가 530M 이상의 메모리를 사용하도록 허용하는 방법은 무엇인가요?
해결 방법을 알고 계신 분이 있다면 알려주시면 감사하겠습니다. 시간 내어 도움을 주셔서 미리 감사드립니다!
좋은 하루 되세요!
trobiyo
6월 9, 2023, 3:52오후
2
Denis님,
Sidekiq의 RSS를 증가시키는 방법에 대한 정보를 제공해 드리겠습니다.
이를 위해 UNICORN_SIDEKIQ_MAX_RSS 환경 변수를 확인해 주세요 (ffi: https://github.com/discourse/discourse/blob/89d7b18161d1625352e82e82c19f93e7272c965ef/config/unicorn.conf.rb#L134 ) (예: UNICORN_SIDEKIQ_MAX_RSS: 1000). 이렇게 하면 더 많은 메모리를 할당할 수 있습니다. 다만, 작업이 오랫동안 대기열에 쌓여 있지 않는 한 UNICORN_SIDEKIQS 값을 1 또는 2로 약간 낮추는 것을 권장합니다.
Sidekiq가 재시작되는 원인은 정확히 알 수 없지만, 보통 OOM(메모리 부족) 발생 후 백그라운드에서 재시작됩니다 (https://github.com/discourse/discourse/blob/89d7b18161d1625352e82e82c19f93e7272c965ef/config/unicorn.conf.rb#L163-L168 참고). 자세한 내용은 your-forum.com/logs를 확인해 보시길 바랍니다. 도움이 되길 바랍니다.
감사합니다,
bizotto
6월 12, 2023, 7:28오전
3
안녕하세요 @trobiyo , 빠르고 명확한 지원에 진심으로 감사드립니다!
네, 제 sidekiq가 OOM(메모리 부족)으로 인해 재시작되고 있지만, 이제 조언하신 대로 UNICORN_SIDEKIQS=1을 줄이고, UNICORN_SIDEKIQ_MAX_RSS 환경 변수를 사용하여 RSS에 할당된 메모리를 늘렸습니다.
이것이 도움이 되어 sidekiq 재시작을 방지할 수 있기를 바랍니다.
sidekiq가 /shared/log/rails/sidekiq.log에 로그를 생성하지 않는 이유가 혹시 있으신가요?
다시 한번 감사드리며, 좋은 하루 보내세요!
감사합니다,
trobiyo
6월 12, 2023, 4:34오후
4
bizotto
6월 13, 2023, 5:31오전
5
안녕하세요,
네, DISCOURSE_LOG_SIDEKIQ=1이 도움이 되었고 /shared/log/rails/sidekiq.log 파일을 확인할 수 있습니다. 정말 좋습니다!
또한 메모리 할당량을 늘리고 프로세스를 1개로 줄인 이후, sidekiq가 OOM으로 인해 재시작되지 않고 꽤 오랫동안 실행되고 있는 것을 확인했습니다.
이것이 제 sidekiq 문제의 해결책인 것 같습니다. 계속 모니터링할 것이며, sidekiq 관련 문제가 여전히 발생하면 여기에 업데이트를 남기겠습니다.
그동안 정말 도움을 주셔서 감사합니다 @trobiyo , 훌륭한 지원이었어요!
좋은 하루 보내세요!
trobiyo
6월 13, 2023, 6:27오전
6
정말 좋은 소식입니다
감사합니다,
bizotto
6월 14, 2023, 8:36오전
7
다시 한 번 인사드립니다, @trobiyo님 ,
불행히도 제 sidekiq가 여전히 멈추고 있으며, 변경 사항이 충분하지 않은 것 같습니다. =/
로그에서 다음과 같은 오류를 확인했습니다:
info:
Job exception: FinalDestination: all resolved IPs were disallowed
backtrace:
/var/www/discourse/lib/final_destination/ssrf_detector.rb:104:in `lookup_and_filter_ips'
/var/www/discourse/lib/final_destination/http.rb:13:in `connect'
/usr/local/lib/ruby/3.2.0/net/http.rb:1248:in `do_start'
/usr/local/lib/ruby/3.2.0/net/http.rb:1237:in `start'
/usr/local/lib/ruby/3.2.0/net/http.rb:687:in `start'
/var/www/discourse/lib/final_destination.rb:511:in `safe_session'
/var/www/discourse/lib/final_destination.rb:450:in `safe_get'
/var/www/discourse/lib/final_destination.rb:161:in `get'
/var/www/discourse/lib/retrieve_title.rb:81:in `fetch_title'
/var/www/discourse/lib/retrieve_title.rb:7:in `crawl'
/var/www/discourse/lib/inline_oneboxer.rb:76:in `lookup'
/var/www/discourse/lib/cooked_processor_mixin.rb:310:in `process_inline_onebox'
/var/www/discourse/lib/cooked_processor_mixin.rb:39:in `block in post_process_oneboxes'
/var/www/discourse/lib/oneboxer.rb:213:in `block in apply'
/var/www/discourse/lib/oneboxer.rb:161:in `block in each_onebox_link'
nokogiri-1.14.2-x86_64-linux/lib/nokogiri/xml/node_set.rb:235:in `block in each'
nokogiri-1.14.2-x86_64-linux/lib/nokogiri/xml/node_set.rb:234:in `upto'
nokogiri-1.14.2-x86_64-linux/lib/nokogiri/xml/node_set.rb:234:in `each'
/var/www/discourse/lib/oneboxer.rb:161:in `each_onebox_link'
/var/www/discourse/lib/oneboxer.rb:212:in `apply'
/var/www/discourse/lib/cooked_processor_mixin.rb:9:in `post_process_oneboxes'
/var/www/discourse/lib/cooked_post_processor.rb:41:in `block in post_process'
/var/www/discourse/lib/distributed_mutex.rb:53:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize'
/var/www/discourse/lib/cooked_post_processor.rb:38:in `post_process'
/var/www/discourse/app/jobs/regular/process_post.rb:28:in `block in execute'
/var/www/discourse/lib/distributed_mutex.rb:53:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize'
/var/www/discourse/app/jobs/regular/process_post.rb:8:in `execute'
/var/www/discourse/app/jobs/base.rb:249:in `block (2 levels) in perform'
rails_multisite-4.0.1/lib/rails_multisite/connection_management.rb:80:in `with_connection'
/var/www/discourse/app/jobs/base.rb:236:in `block in perform'
/var/www/discourse/app/jobs/base.rb:232:in `each'
/var/www/discourse/app/jobs/base.rb:232:in `perform'
sidekiq-6.5.8/lib/sidekiq/processor.rb:202:in `execute_job'
sidekiq-6.5.8/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
sidekiq-6.5.8/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:134:in `call'
sidekiq-6.5.8/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
sidekiq-6.5.8/lib/sidekiq/middleware/chain.rb:182:in `invoke'
sidekiq-6.5.8/lib/sidekiq/processor.rb:169:in `block in process'
sidekiq-6.5.8/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.5.8/lib/sidekiq/job_retry.rb:113:in `local'
sidekiq-6.5.8/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.5.8/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
sidekiq-6.5.8/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.5.8/lib/sidekiq/processor.rb:263:in `stats'
sidekiq-6.5.8/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.5.8/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.5.8/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.5.8/lib/sidekiq/job_retry.rb:80:in `global'
sidekiq-6.5.8/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.5.8/lib/sidekiq/job_logger.rb:39:in `prepare'
sidekiq-6.5.8/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.5.8/lib/sidekiq/processor.rb:168:in `process'
sidekiq-6.5.8/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.5.8/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.5.8/lib/sidekiq/component.rb:8:in `watchdog'
sidekiq-6.5.8/lib/sidekiq/component.rb:17:in `block in safe_thread'
이 로그를 바탕으로 무엇이 잘못되고 있는지 짐작 가는 점이 있으신가요?
지원해 주셔서 다시 한번 감사드립니다.
trobiyo
6월 14, 2023, 1:29오후
8
데니스, 안녕하세요.
이 문제는 소켓/DNS 관련 타임아웃으로 보이는데, allowed internal hosts 설정에 아무것도 지정되어 있지 않나요?
스택트레이스를 보면 IP를 조회할 때 해당 목록이 비어 있는 것 같습니다(참조: discourse/lib/final_destination/ssrf_detector.rb at main · discourse/discourse · GitHub ). 이 부분은 discourse/lib/final_destination/http.rb at tests-passed · discourse/discourse · GitHub 에서 트리거됩니다. 따라서 이 문제가 현재 설치 환경(예: 사이드킥(sidekiq) 포드에 IP로 접근할 수 없는 경우)과 관련이 있을 수 있다고 추측해 봅니다.
또는 클러스터에 NetworkPolicy가 설치되어 있는지 확인해 보세요. 이 또한 원인이 될 수 있습니다.
감사합니다.
, 문제가 해결되는 데 도움이 되어 기쁩니다!