Feature #23237
closed
Ansible installer configures Passenger scaling options
Description
This ticket is basically "do #23202 for the Ansible installer." The job is made easier by the fact that Ansible already has a systemd override template for the RailsAPI service at source:tools/ansible/roles/arvados_api/templates/cluster.conf.j2; we just need to extend it with lines like this:
Environment=PASSENGER_MAX_POOL_SIZE={{ arvados_api_max_pool_size }}
Environment=PASSENGER_MAX_REQUEST_QUEUE_SIZE={{ arvados_api_max_request_queue_size }}
Add tools/ansible/roles/arvados_api/defaults/main.yml with defaults following the Salt installer's logic:
arvados_api_max_pool_size: "{{ [CPU Core Count] * 2 | int }}"
arvados_api_max_request_queue_size: "{{ arvados_api_max_pool_size * 2 + 1 }}"
[CPU Core Count] is a placeholder. There should be an Ansible fact that has this information built-in. Figure out where it is by running ansible -m setup localhost or a similar command and use that.
Test (manually) that this works as expected both with the default settings and a custom arvados_api_max_pool_size set as an inventory variable.
Updated by Brett Smith 5 months ago
- Related to Bug #23202: Salt installer missing standalone passenger configs added
Updated by Stephen Smith 5 months ago
Changes at arvados|81063721e3498ac9d1270b0216561bec0cfadbd6 branch 23237-ansible-configures-passenger-scaling
Workbench tests developer-run-tests-services-workbench2: #1668
(not sure if there are other appropriate tests that should be run for this)
- Added the pool size and request queue size to the passenger config template
- Added defaults to set pool size to nproc, and queue size to pool size * 2 + 1
- Notes about nproc:
- It appears to accurately reflect thread count on every system I tested, my laptop with E-cores, an intel nuc with a normal 6c12t configuration, and cloud instances
- In short, cores includes E-cores and may not be hyperthreaded so simply doubling them doesn't work
- thread_per_core doesn't seem accurate since on a CPU with E-cores it gives 1 despite the non-e-cores having 2 threads, so multiplying threads_per_core * cores doesn't work either
- I tested the playbook and verified that it sets the default value correctly, and uses the overridden value from the inventory when set, including calculating the correct new queue size
- I added another
| intconversion to the queue size calculation since the values are stored as strings, I suppose we could also remove the quotes and have them as actual integers but I'm not sure if there's a convention either way.
Updated by Lucas Di Pentima 5 months ago
Confirmed that works great, thanks! LGTM.
Updated by Stephen Smith 5 months ago
- Status changed from In Progress to Resolved