Puma спит важный поток при загрузке приложения rails

Из вашего кода я думаю, что у вас есть более серьезная проблема, чем спящий поток ... что, я думаю, может быть вызвано тем фактом, что некоторые вещи неправильно названы, а другие просто не часто учитываются при использовании веб-фреймворка.

В мире серверов «воркеры» относятся к forked процессам, которые выполняют задачи, связанные с сервером, часто принимая новые соединения и обрабатывая веб-запросы.

НО - fork не дублирует темы! - новый процесс (рабочий) начинается только с одного единственного потока, который является копией потока, вызвавшего fork.

Это связано с тем, что процессы не используют общую память (обычно). Любые глобальные данные, которые у вас есть в процессе, являются частными для этого процесса (т. Е. Если вы сохраняете подключенные клиенты веб-сокетов в массиве, этот массив различен для каждого «работника»).

Ничего не поделаешь, это часть того, как спроектированы ОС и fork.

Таким образом, предупреждение нельзя обойти — это указание на конструктивный недостаток приложения (!).

Например, в вашем текущем дизайне (при условии, что поток не находится в спящем режиме) метод handle_tweet будет вызываться только для исходного серверного процесса и не будет вызываться для какого-либо рабочего процесса.

Если вы используете pub/sub, вам нужно только одно соединение twitter_stream для всего приложения (независимо от того, сколько серверов или рабочих есть у вашего приложения) — возможно, процесс twitter_stream (или фоновое приложение) будет лучше, чем поток.

Но если вы реализуете handle_tweet специфическим для процесса способом, т. е. отправляя сообщение каждому подключенному клиенту, сохраненному в массиве, вам необходимо убедиться, что каждый «работник» инициирует поток twitter_stream (!).

Когда я писал Iodine (отличный от Puma сервер), я обрабатывал эти варианты использования с помощью Iodine.runметод, который откладывает выполнение задач на потом. «Сохраненная» задача должна выполняться только после инициализации рабочих процессов и запуска цикла обработки событий, поэтому она выполняется в каждом процессе (что позволяет запускать новый поток в каждом процессе).

i.e.

Iodine.run do
   Thread.start do
    twitter_stream.user do |object|
    # ...
    end
   end
end

Я предполагаю, что у Puma есть похожее решение. Насколько я понимаю из документации Puma Clustered-Mode, добавление следующего блока в ваш config/puma.rb может помочь:

# config/puma.rb
on_worker_boot do
  Thread.start do
   twitter_stream.user do |object|
   # ...
   end
  end
end

Удачи!

EDIT: относительно комментария о twitter_stream с использованием ActiveRecord

Из комментариев я понял, что обратные вызовы twitter_stream хранят данные в базе данных, а также обрабатывают события или уведомления «push».

Хотя эти две проблемы связаны, они очень отличаются друг от друга.

Например, обратные вызовы twitter_stream должны сохранять данные в базе данных только один раз. Даже если ваше приложение разрастется до миллиарда пользователей, вам нужно будет сохранить данные в базе данных один раз.

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

Сначала, пока вы ограничиваете свое приложение одним (работает только один сервер/приложение), вы можете использовать fork вместе со сценарием initializer/twitter.rb... т.е.:

### START TWITTER PROCESS ### if production
if Rails.env.production?
  puts 'Starting Twitter Stream...'
  Process.fork do
    twitter_stream.user do |object|
      # ...
    end
  end
end

С другой стороны, уведомления должны быть адресованы конкретному пользователю по определенному соединению, принадлежащему определенному процессу.

Следовательно, уведомления должны быть отдельной задачей от twitter_stream обновления базы данных, и они должны выполняться в фоновом режиме каждого процесса, используя on_worker_boot (или Iodine.run), описанный выше.

Для этого вы можете on_worker_boot запустить фоновый поток, который будет прослушивать службу публикации/подписки, такую ​​как Redis, в то время как twitter_stream обратные вызовы «публикуют» обновления для службы публикации/подписки.

Это позволит каждому процессу просмотреть обновление и проверить, принадлежит ли какое-либо из соединений, которыми он «владеет», клиенту, который должен быть уведомлен об обновлении.

Как я читаю ваш вопрос, это не похоже на проблему. спящий поток отличается от мертвого потока. Сон просто означает, что поток ожидает бездействия, не потребляя никакого процессора. Если все остальное подключено правильно, то, как только API-интерфейс Twitter обнаружит событие, он должен разбудить поток, запустить любой определенный вами обработчик, а затем снова вернуться в спящий режим. Сон — это не «работа в фоновом режиме», а «ожидание того, что что-то произойдет (например, кто-то твитнет @me.), чтобы я мог работать в фоновом режиме».

Быстрый пример, чтобы продемонстрировать это:

2.4.0 :001 > t = Thread.new { TCPServer.new(1234).accept ; puts "Got a connection! Dying..." }
 => #<Thread:0x007fa3941fed90@(irb):1 sleep> 
2.4.0 :002 > t
 => #<Thread:0x007fa3941fed90@(irb):1 sleep> 
2.4.0 :003 > t
 => #<Thread:0x007fa3941fed90@(irb):1 sleep> 
2.4.0 :004 > TCPSocket.new 'localhost', 1234
 => #<TCPSocket:fd 35> 
2.4.0 :005 > Got a connection! Dying...
t
 => #<Thread:0x007fa3941fed90@(irb):1 dead> 

Сон просто означает «ожидание действия».

Как бы то ни было, довольно странно иметь поток, прослушивающий обновления от такого API на веб-сервере. Может быть, вам следует подумать о том, чтобы рабочий процесс обрабатывал события твиттера, используя что-то вроде Resque? Или, может быть, для вашего варианта использования подходит ActionCable?