1
0
Fork 0
mirror of https://github.com/puma/puma.git synced 2022-11-09 13:48:40 -05:00

fork_worker does not work with preload_app! (#2468)

Related to #2466
Close #2467

[ci skip]
This commit is contained in:
Patrik Ragnarsson 2020-10-29 14:05:13 +01:00 committed by GitHub
parent 61c6213fba
commit f0dffd4d78
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 7 additions and 5 deletions

View file

@ -1,6 +1,6 @@
# Welcome to Puma 5: Spoony Bard. # Welcome to Puma 5: Spoony Bard.
![https://i1.kym-cdn.com/entries/icons/original/000/006/385/Spoony_Bard.jpg](https://i1.kym-cdn.com/entries/icons/original/000/006/385/Spoony_Bard.jpg) ![https://i1.kym-cdn.com/entries/icons/original/000/006/385/Spoony_Bard.jpg](https://i1.kym-cdn.com/entries/icons/original/000/006/385/Spoony_Bard.jpg)
>Note: Puma 5 now automatically uses `WEB_CONCURRENCY` env var if set see [this post for an explanation](https://github.com/puma/puma/issues/2393#issuecomment-702352208). If your memory use goes up after upgrading to Puma 5 it indicates you're now running with multiple workers (processes). You can decrease memory use by tuning this number to be lower. >Note: Puma 5 now automatically uses `WEB_CONCURRENCY` env var if set see [this post for an explanation](https://github.com/puma/puma/issues/2393#issuecomment-702352208). If your memory use goes up after upgrading to Puma 5 it indicates you're now running with multiple workers (processes). You can decrease memory use by tuning this number to be lower.
@ -34,9 +34,9 @@ Users of this option should see reduced request queue latency and possibly less
Add the following to your `puma.rb` to try it: Add the following to your `puma.rb` to try it:
```ruby ```ruby
wait_for_less_busy_worker wait_for_less_busy_worker
# or # or
wait_for_less_busy_worker 0.001 wait_for_less_busy_worker 0.001
``` ```
@ -52,7 +52,7 @@ Production testing at GitLab suggests values between `0.001` and `0.010` are bes
To use it, you can add this to your `puma.rb`: To use it, you can add this to your `puma.rb`:
```ruby ```ruby
nakayoshi_fork nakayoshi_fork
``` ```
@ -68,7 +68,7 @@ Puma 5 introduces an experimental new cluster-mode configuration option, `fork_w
10004 \_ puma: cluster worker 3: 10000 [puma] 10004 \_ puma: cluster worker 3: 10000 [puma]
``` ```
This allows the usage of `preload` with `phased_restart`. It also may improve memory usage because the worker process loads additional code after processing requests. It is compatible with phased restarts. It also may improve memory usage because the worker process loads additional code after processing requests.
To learn more about using `refork` and `fork_worker`, see [the documentation](https://github.com/puma/puma/blob/master/docs/fork_worker.md). To learn more about using `refork` and `fork_worker`, see [the documentation](https://github.com/puma/puma/blob/master/docs/fork_worker.md).

View file

@ -24,6 +24,8 @@ Similar to the `preload_app!` option, the `fork_worker` option allows your appli
### Limitations ### Limitations
- Not compatible with the `preload_app!` option
- This mode is still very experimental so there may be bugs or edge-cases, particularly around expected behavior of existing hooks. Please open a [bug report](https://github.com/puma/puma/issues/new?template=bug_report.md) if you encounter any issues. - This mode is still very experimental so there may be bugs or edge-cases, particularly around expected behavior of existing hooks. Please open a [bug report](https://github.com/puma/puma/issues/new?template=bug_report.md) if you encounter any issues.
- In order to fork new workers cleanly, worker 0 shuts down its server and stops serving requests so there are no open file descriptors or other kinds of shared global state between processes, and to maximize copy-on-write efficiency across the newly-forked workers. This may temporarily reduce total capacity of the cluster during a phased restart / refork. - In order to fork new workers cleanly, worker 0 shuts down its server and stops serving requests so there are no open file descriptors or other kinds of shared global state between processes, and to maximize copy-on-write efficiency across the newly-forked workers. This may temporarily reduce total capacity of the cluster during a phased restart / refork.