bida/Mastodon-documentation
5
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

explaining DB_POOL better

Browse source
This commit is contained in:
jeroenpraat 2017-05-10 16:29:26 +02:00 committed by GitHub
parent 7380ab5b49
commit 1c5e3bce14
1 changed files with 9 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
Running-Mastodon/Tuning.md
View file

@ -38,7 +38,7 @@ The amount of threads is not controlled by an environment variable in this case,
bundle exec sidekiq -c 15 -q default -q mailers -q push
Would start the sidekiq process with 15 threads. Please mind that each threads needs to be able to connect to the database, which means that the database pool needs to be large enough to support all the threads. The database pool size is controlled with the `DB_POOL` environment variable, and defaults to the value of `MAX_THREADS` (therefore, is 5 by default).
Would start the sidekiq process with 15 threads. Please mind that each threads needs to be able to connect to the database, which means that the database pool needs to be large enough to support all the threads. The database pool size is controlled with the `DB_POOL` environment variable, and defaults to the value of `MAX_THREADS` (therefore, is 5 by default). So when the amount of Sidekiq threads (-c) is different than the amount of Puma threads (MAX_THREADS) than you have to set DB_POOL as an environment variable for Sidekiq.
You might notice that the above command specifies three queues to be processed:
@ -78,6 +78,14 @@ Edit `docker-compose.yml`:
environment:
- WEB_CONCURRENCY=1
- MAX_THREADS=5
...
sidekiq:
restart: always
build: .
env_file: .env.production
environment:
- DB_POOL=10
command: bundle exec sidekiq -c 10 -q default -q mailers -q pull -q push
...
```