Режим кластера с использованием вилки-работника [Экспериментальный]

Puma 5 вводит экспериментальную новую опцию конфигурации режима кластера, fork_worker (--fork-worker из командной строки). Этот режим заставляет Puma форкать дополнительные рабочие процессы от рабочего процесса 0, вместо форкирования напрямую от основного процесса:

10000   \_ puma 4.3.3 (tcp://0.0.0.0:9292) [puma]
10001       \_ puma: cluster worker 0: 10000 [puma]
10002           \_ puma: cluster worker 1: 10000 [puma]
10003           \_ puma: cluster worker 2: 10000 [puma]
10004           \_ puma: cluster worker 3: 10000 [puma]

Опция fork_worker позволяет инициализировать ваше приложение только один раз для экономии памяти с использованием технологии copy-on-write, и она имеет два дополнительных преимущества:

1. Совместимость с постепенным перезапуском. Поскольку основной процесс сам по себе не предзагружает приложение, этот режим работает с постепенным перезапуском (SIGUSR1 или pumactl phased-restart). Когда рабочий процесс 0 перезапускается как часть постепенного перезапуска, он сначала инициализирует новую копию вашего приложения, а затем другие рабочие процессы перезапускаются, форкируясь от этого нового рабочего процесса, содержащего новую предзагруженную версию приложения.

   Это позволяет постепенному перезапуску завершаться так же быстро, как горячему перезапуску (SIGUSR2 или pumactl restart), при этом все еще минимизируя время простоя, распределяя перезапуск по рабочим процессам кластера.2. 'Перефорк' для дополнительных улучшений использования памяти в работающих приложениях. Режим вилки-работника вводит новую команду refork, которая перезагружает все ненулевые рабочие процессы, перефоркивая их от рабочего процесса 0.

   Эта команда потенциально может улучшить использование памяти в больших или сложных приложениях, которые не полностью прединициализируются при запуске, поскольку перефоркнутые рабочие процессы могут использовать память с использованием технологии copy-on-write с рабочим процессом, который уже работает и обрабатывает запросы.

   Вы можете активировать перефорк, отправив кластеру сигнал SIGURG или запустив команду pumactl refork в любое время. Перефорк также автоматически активируется один раз после обработки определенного количества запросов рабочим процессом 0 (по умолчанию 1000). Для настройки количества запросов перед автоматическим перефорком передайте положительное целое число в качестве аргумента к fork_worker (например, fork_worker 1000), или 0 для отключения.### Рекомендации по использованию fork_worker вводит новые конфигурационные хуки on_refork и after_refork. Обратите внимание на следующее:

   • При первоначальном форке родительского процесса в дочерний процесс 0, before_fork будет срабатывать на родительском процессе, а on_worker_boot — на дочернем процессе 0, как обычно.
   • При форке дочернего процесса 0 в внучатые процессы, on_refork и after_refork будут срабатывать на дочернем процессе 0, а on_worker_boot — на каждом внучатом процессе.
   • Для ясности, before_fork не срабатывает на процессе 0, а after_refork не срабатывает на внучатых процессах.

• Как общее руководство по миграции:

  • Скопируйте любую логику внутри вашего существующего хука before_fork в хук on_refork.
  • Рассмотрите возможность копирования логики из вашего хука on_worker_boot в хук after_refork, если это необходимо для сброса состояния процесса 0 после форка.### Ограничения- Этот режим всё ещё очень экспериментальный, поэтому могут возникнуть ошибки или краевые случаи, особенно вокруг ожидаемого поведения существующих хуков. Пожалуйста, откройте отчёт об ошибке, если вы столкнулись с какими-либо проблемами.

• Чтобы чисто форкнуть новых рабочих процессов, рабочий процесс 0 останавливает свой сервер и прекращает обработку запросов, чтобы не было открытых дескрипторов файлов или других видов глобального состояния, общего между процессами, и чтобы максимизировать эффективность копирования при форкинге новых рабочих процессов. Это может временно уменьшить общую пропускную способность кластера во время фазированного перезапуска / перифоркинга.- В кластере с n рабочими процессами, нормальный фазированный перезапуск останавливает и перезапускает рабочие процессы по одному, в то время как приложение загружается в каждом процессе, так что n-1 рабочих процесса доступны для обработки запросов во время перезапуска. В фазированном перезапуске в режиме форка рабочих процессов, приложение сначала загружается в рабочем процессе 0, когда n-1 рабочих процесса доступны, затем рабочий процесс 0 остаётся остановленным, пока остальные рабочие процессы перезагружаются по одному, оставляя доступными только n-2 рабочих процесса на короткое время. Перезагрузка остальных рабочих процессов должна быть быстрой, так как приложение предзагружено на этом этапе, но могут быть ситуации, когда это может занять больше времени (медленные клиенты, долгое выполнение кода приложения, медленные хуки форкинга рабочих процессов и т.д.).