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:
parent
61c6213fba
commit
f0dffd4d78
2 changed files with 7 additions and 5 deletions
|
@ -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).
|
||||||
|
|
||||||
|
|
|
@ -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.
|
||||||
|
|
Loading…
Reference in a new issue