Sidekiq продолжает перезагрузку Cloud66

Question

Sidekiq продолжает перезагрузку Cloud66

Я боролся с этой проблемой некоторое время и просто не могу понять это. Я пытаюсь заставить Redis и Sidekiq выполнять фоновые задания для моего проекта Rails, размещенного на Cloud66 с Digital Ocean. Все необходимые драгоценные камни, кажется, присутствуют, и установка работает отлично локально.

Моя первая попытка была использовать эти настройки:

Это мой файл config/sidekiq.yaml:

---
:concurrency: 25
:pidfile: ./tmp/pids/sidekiq.pid
:logfile: ./log/sidekiq.log
:queues:
  - default
  - [high_priority, 2]
:daemon: true

Согласно этому уроку https://mikecoutermarsh.com/setting-up-redis-on-cloud66-for-sidekiq/ это мой контент Procfile:

worker: env RAILS_ENV=$RAILS_ENV REDIS_URL=$REDIS_URL_INT bundle exec sidekiq -C config/sidekiq.yml

$ REDIT_URL_INT является переменной ENV для: redis://104.236.131.187:6379, Эта переменная ENV отличается от переменной в руководстве (включает порт) согласно предложению в комментариях к посту.

После развертывания с этими настройками мой журнал Sidekiq выдает мне следующее:

2015-05-16T16:19:44.732Z 14636 TID-1g96vc INFO: Booting Sidekiq 3.3.2 with redis options {:url=>"redis://104.236.131.187:6379"}
2015-05-16T16:20:13.801Z 14701 TID-3trg0 INFO: Running in ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-linux]
2015-05-16T16:20:13.823Z 14701 TID-3trg0 INFO: See LICENSE and the LGPL-3.0 for licensing details.
2015-05-16T16:20:13.823Z 14701 TID-3trg0 INFO: Upgrade to Sidekiq Pro for more features and support: http://sidekiq.org/pro
2015-05-16T16:20:15.167Z 14701 TID-18nsv4 INFO: Booting Sidekiq 3.3.2 with redis options {:url=>"redis://104.236.131.187:6379"}
2015-05-16T16:20:15.180Z 14701 TID-7791g INFO: Booting Sidekiq 3.3.2 with redis options {:url=>"redis://104.236.131.187:6379"}
2015-05-16T16:20:32.065Z 14753 TID-6uz3g INFO: Running in ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-linux]
2015-05-16T16:20:32.066Z 14753 TID-6uz3g INFO: See LICENSE and the LGPL-3.0 for licensing details.
2015-05-16T16:20:32.066Z 14753 TID-6uz3g INFO: Upgrade to Sidekiq Pro for more features and support: http://sidekiq.org/pro
2015-05-16T16:20:32.129Z 14753 TID-1bl0r0 INFO: Booting Sidekiq 3.3.2 with redis options {:url=>"redis://104.236.131.187:6379"}
2015-05-16T16:20:54.584Z 14852 TID-5t1rs INFO: Running in ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-linux]
2015-05-16T16:20:54.585Z 14852 TID-5t1rs INFO: See LICENSE and the LGPL-3.0 for licensing details.
2015-05-16T16:20:54.585Z 14852 TID-5t1rs INFO: Upgrade to Sidekiq Pro for more features and support: http://sidekiq.org/pro
2015-05-16T16:20:54.665Z 14852 TID-1aj3m0 INFO: Booting Sidekiq 3.3.2 with redis options {:url=>"redis://104.236.131.187:6379"}

У меня создается впечатление, что Sidekiq постоянно перезагружается. Итак, я проверил процессы Sidekiq:

12747 ?        Sl     0:10 sidekiq 3.3.2 web_head [0 of 25 busy]
13540 ?        Sl     0:07 sidekiq 3.3.2 web_head [0 of 25 busy]
13596 ?        Sl     0:08 sidekiq 3.3.2 web_head [0 of 25 busy]
13650 ?        Sl     0:06 sidekiq 3.3.2 web_head [0 of 25 busy]
13702 ?        Sl     0:06 sidekiq 3.3.2 web_head [0 of 25 busy]
13758 ?        Sl     0:07 sidekiq 3.3.2 web_head [0 of 25 busy]
13818 ?        Sl     0:07 sidekiq 3.3.2 web_head [0 of 25 busy]
13869 ?        Sl     0:07 sidekiq 3.3.2 web_head [0 of 25 busy]
13934 ?        Sl     0:07 sidekiq 3.3.2 web_head [0 of 25 busy]
13986 ?        Sl     0:07 sidekiq 3.3.2 web_head [0 of 25 busy]
14089 ?        Sl     0:06 sidekiq 3.3.2 web_head [0 of 25 busy]
14144 ?        Sl     0:06 sidekiq 3.3.2 web_head [0 of 25 busy]
14196 ?        Sl     0:06 sidekiq 3.3.2 web_head [0 of 25 busy]
14259 ?        Sl     0:06 sidekiq 3.3.2 web_head [0 of 25 busy]
14311 ?        Sl     0:06 sidekiq 3.3.2 web_head [0 of 25 busy]
14363 ?        Sl     0:05 sidekiq 3.3.2 web_head [0 of 25 busy]
14421 ?        Sl     0:05 sidekiq 3.3.2 web_head [0 of 25 busy]
14474 ?        Sl     0:07 sidekiq 3.3.2 web_head [0 of 25 busy]
14530 ?        Sl     0:05 sidekiq 3.3.2 web_head [0 of 25 busy]
14585 ?        Sl     0:05 sidekiq 3.3.2 web_head [0 of 25 busy]
14636 ?        Sl     0:05 sidekiq 3.3.2 web_head [0 of 25 busy]
14701 ?        Sl     0:05 sidekiq 3.3.2 web_head [0 of 25 busy]
14753 ?        Sl     0:05 sidekiq 3.3.2 web_head [0 of 25 busy]
14852 ?        Sl     0:05 sidekiq 3.3.2 web_head [0 of 25 busy]
14913 ?        Sl     0:04 sidekiq 3.3.2 web_head [0 of 25 busy]
14966 ?        Sl     0:04 sidekiq 3.3.2 web_head [0 of 25 busy]
15023 ?        Sl     0:04 sidekiq 3.3.2 web_head [0 of 25 busy]

Это много действий Sidekiq! Я не просил об этом. Мне нужен только один.

Моя текущая теория заключается в том, что мне не хватает связи между настройками Rails / Sidekiq / Redis. Поэтому я добавил Redis config/redis/production.conf:

daemonize yes
port 6379
logfile ./log/redis_production.log
dbfilename ./db/production.rdb

Это не имеет значения. Также не создается ни redis_production.log, ни production.rbd. Так что я думаю, что cloud66 позаботится о Redis. Если я извлекаю веб-консоль, сервер Redis работает на правильном порту.

Я считаю, что Cloud66 использует Bluepil для управления своими процессами. Существует следующий файл журнала с именем user_worker_pill.log:

I, [2015-05-16T16:28:27.157623 #11066]  INFO -- : [user_worker:worker:user_worker_1] Going from down => starting
E, [2015-05-16T16:28:47.183939 #11066] ERROR -- : [user_worker:worker:user_worker_1] Failed to signal process 16244 with code 0: No such process
E, [2015-05-16T16:28:47.185674 #11066] ERROR -- : [user_worker:worker:user_worker_1] Failed to signal process 16244 with code 0: No such process
I, [2015-05-16T16:28:47.618515 #11066]  INFO -- : [user_worker:worker:user_worker_1] Going from starting => down
E, [2015-05-16T16:28:48.627548 #11066] ERROR -- : [user_worker:worker:user_worker_1] Failed to signal process 16244 with code 0: No such process
E, [2015-05-16T16:28:48.629944 #11066] ERROR -- : [user_worker:worker:user_worker_1] Failed to signal process 16244 with code 0: No such process
D, [2015-05-16T16:28:48.991312 #11066] DEBUG -- : [user_worker] pid journal file: /var/run/bluepill/journals/.bluepill_pids_journal.user_worker_1
D, [2015-05-16T16:28:48.993154 #11066] DEBUG -- : [user_worker] pid journal = 16244
D, [2015-05-16T16:28:48.993257 #11066] DEBUG -- : [user_worker] Acquired lock /var/run/bluepill/journals/.bluepill_pids_journal.user_worker_1.lock
D, [2015-05-16T16:28:48.993396 #11066] DEBUG -- : [user_worker] Unable to term missing process 16244
D, [2015-05-16T16:28:48.993535 #11066] DEBUG -- : [user_worker] Journal cleanup completed
D, [2015-05-16T16:28:48.993595 #11066] DEBUG -- : [user_worker] Cleared lock /var/run/bluepill/journals/.bluepill_pids_journal.user_worker_1.lock
D, [2015-05-16T16:28:48.993654 #11066] DEBUG -- : [user_worker] pgid journal file: /var/run/bluepill/journals/.bluepill_pgids_journal.user_worker_1
D, [2015-05-16T16:28:48.993829 #11066] DEBUG -- : [user_worker] pgid journal = 16241
D, [2015-05-16T16:28:48.993901 #11066] DEBUG -- : [user_worker] Acquired lock /var/run/bluepill/journals/.bluepill_pgids_journal.user_worker_1.lock
D, [2015-05-16T16:28:48.993994 #11066] DEBUG -- : [user_worker] Unable to term missing process group 16241
D, [2015-05-16T16:28:48.995031 #11066] DEBUG -- : [user_worker] Journal cleanup completed
D, [2015-05-16T16:28:48.995180 #11066] DEBUG -- : [user_worker] Cleared lock /var/run/bluepill/journals/.bluepill_pgids_journal.user_worker_1.lock
W, [2015-05-16T16:28:48.995344 #11066]  WARN -- : [user_worker:worker:user_worker_1] Executing start command: env RAILS_ENV=production REDIS_URL=redis://104.236.131.187:6379 bundle exec sidekiq -C config/sidekiq.yml
D, [2015-05-16T16:28:49.457935 #11066] DEBUG -- : [user_worker] Acquired lock /var/run/bluepill/journals/.bluepill_pgids_journal.user_worker_1.lock
D, [2015-05-16T16:28:49.458693 #11066] DEBUG -- : [user_worker] pgid journal file: /var/run/bluepill/journals/.bluepill_pgids_journal.user_worker_1
D, [2015-05-16T16:28:49.459430 #11066] DEBUG -- : [user_worker] Saving pgid 16296 to process journal user_worker_1
I, [2015-05-16T16:28:49.459854 #11066]  INFO -- : [user_worker] Saved pgid 16296 to journal user_worker_1
D, [2015-05-16T16:28:49.460220 #11066] DEBUG -- : [user_worker] Journal now = 16296

D, [2015-05-16T16:28:49.460454 #11066] DEBUG -- : [user_worker] Cleared lock /var/run/bluepill/journals/.bluepill_pgids_journal.user_worker_1.lock
D, [2015-05-16T16:28:49.460656 #11066] DEBUG -- : [user_worker] Acquired lock /var/run/bluepill/journals/.bluepill_pids_journal.user_worker_1.lock
D, [2015-05-16T16:28:49.460901 #11066] DEBUG -- : [user_worker] pid journal file: /var/run/bluepill/journals/.bluepill_pids_journal.user_worker_1
D, [2015-05-16T16:28:49.461174 #11066] DEBUG -- : [user_worker] Saving pid 16299 to process journal user_worker_1
I, [2015-05-16T16:28:49.462289 #11066]  INFO -- : [user_worker] Saved pid 16299 to journal user_worker_1
D, [2015-05-16T16:28:49.462563 #11066] DEBUG -- : [user_worker] Journal now = 16299

D, [2015-05-16T16:28:49.462916 #11066] DEBUG -- : [user_worker] Cleared lock /var/run/bluepill/journals/.bluepill_pids_journal.user_worker_1.lock

Это за пределами моего ограниченного опыта в этом вопросе, но мне кажется, что он пытается восстановить аварийный процесс несколько раз с помощью команды в Procfile.

Это вся информация, которую я смог собрать, я не знаю, как поступить. Я очень, очень ценю любые идеи, комментарии или предложения.

СПАСИБО!

/РЕДАКТИРОВАТЬ

После комментария от Филиппа я изменил $REDIS_URL_INT на $REDIT_ADDRESS (IP без порта), и это sidekiq.log:

2015-05-18T14:00:05.683Z 15878 TID-1dm310 ERROR: heartbeat: Waited 1 sec
2015-05-18T14:00:07.769Z 15878 TID-boxzc ERROR: Waited 1 sec
2015-05-18T14:00:07.769Z 15878 TID-boxzc ERROR: /var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/connection_pool-2.1.1/lib/connection_pool/timed_stack.rb:85:in `block (2 levels) in pop'
2015-05-18T14:00:08.770Z 15878 TID-boxzc WARN: {:context=>"scheduling poller thread died!"}
2015-05-18T14:00:08.771Z 15878 TID-boxzc WARN: Waited 1 sec
2015-05-18T14:00:08.771Z 15878 TID-boxzc WARN: /var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/connection_pool-2.1.1/lib/connection_pool/timed_stack.rb:85:in `block (2 levels) in pop'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/connection_pool-2.1.1/lib/connection_pool/timed_stack.rb:77:in `loop'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/connection_pool-2.1.1/lib/connection_pool/timed_stack.rb:77:in `block in pop'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/connection_pool-2.1.1/lib/connection_pool/timed_stack.rb:76:in `synchronize'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/connection_pool-2.1.1/lib/connection_pool/timed_stack.rb:76:in `pop'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/connection_pool-2.1.1/lib/connection_pool.rb:78:in `checkout'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/connection_pool-2.1.1/lib/connection_pool.rb:60:in `with'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/sidekiq-3.3.2/lib/sidekiq.rb:74:in `redis'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/sidekiq-3.3.2/lib/sidekiq/api.rb:634:in `cleanup'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/sidekiq-3.3.2/lib/sidekiq/api.rb:627:in `initialize'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/sidekiq-3.3.2/lib/sidekiq/scheduled.rb:87:in `new'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/sidekiq-3.3.2/lib/sidekiq/scheduled.rb:87:in `poll_interval'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/sidekiq-3.3.2/lib/sidekiq/scheduled.rb:66:in `block in poll'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/sidekiq-3.3.2/lib/sidekiq/util.rb:16:in `watchdog'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/sidekiq-3.3.2/lib/sidekiq/scheduled.rb:51:in `poll'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/celluloid-0.16.0/lib/celluloid/calls.rb:26:in `public_send'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/celluloid-0.16.0/lib/celluloid/calls.rb:26:in `dispatch'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/celluloid-0.16.0/lib/celluloid/calls.rb:122:in `dispatch'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/celluloid-0.16.0/lib/celluloid/cell.rb:60:in `block in invoke'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/celluloid-0.16.0/lib/celluloid/cell.rb:71:in `block in task'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/celluloid-0.16.0/lib/celluloid/actor.rb:357:in `block in task'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/celluloid-0.16.0/lib/celluloid/tasks.rb:57:in `block in initialize'
/var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/celluloid-0.16.0/lib/celluloid/tasks/task_fiber.rb:15:in `block in create'
2015-05-18T14:00:08.774Z 15878 TID-1dm5j0 WARN: Sidekiq died due to the following error, cannot recover, process exiting
2015-05-18T14:00:08.775Z 15878 TID-1dm5j0 WARN: Waited 1 sec
2015-05-18T14:00:08.776Z 15878 TID-1dm5j0 WARN: /var/deploy/gemconn/web_head/shared/bundle/ruby/2.1.0/gems/connection_pool-2.1.1/lib/connection_pool/timed_stack.rb:85:in `block (2 levels) in pop'

0

ruby-on-rails redis sidekiq bluepill cloud66

Источник

user1321002 16 май '15 в 16:32

3 ответа

Решение

Повторные сообщения, вероятно, потому что sidekiq не может подключиться к Redis. Вы уверены, что должны использовать публичный IP-адрес в $REDIS_URL_INT? Если да, разрешен ли вам доступ к нужному порту? Если они находятся в одном окне, возможно, используйте 0.0.0.0 или аналогичный.

0

Источник

user2155313 16 май '15 в 17:56

Не должно быть проблем с подключением к вашему серверу Redis по внешнему IP-адресу (учитывая настройку брандмауэра), но если вы используете SSH для своего сервера, можете ли вы запустить эту команду вручную, чтобы увидеть, что она выводит? Вы также можете установить параметры подключения непосредственно в этом случае, что облегчит поиск и устранение неисправностей. Я не вижу ничего явно неправильного в вашей настройке.

В сторону, причина вашего REDIS_URL_INT для внешнего IP-адреса установлено, что DigitalOcean SF не поддерживает частные сети. Они делают сейчас (хотя они не объявили об этом изменении), поэтому мы сделаем это обновление и на нашей стороне.

0

Источник

user2609969 18 май '15 в 09:45

Другие вопросы по тегам ruby-on-rails redis sidekiq bluepill cloud66

user2609969 20 май '15 в 11:24 2015-05-20 11:24 · Accepted Answer · 2015-05-20 11:24

Я добавляю еще один ответ, чтобы сделать это решение более понятным. Я посмотрел поближе, и ваша конфигурация Sidekiq фактически демонизирует процесс, в то время как процессы должны выполняться на переднем плане, чтобы мы могли их контролировать. Вот почему вы видели так много запущенных процессов Sidekiq - наш bluepill запустил бы один, думаю, что он не подошел, поэтому начните больше.

Если вы удалите :daemon: true из вашего sidekiq.yml и повторно разверните, это должно решить проблему.