Size the worker pool from the CPU allocation - #110
Merged
Conversation
- Read the cgroup CPU quota at start and set ServerLimit, ThreadsPerChild, and MaxRequestWorkers, so a larger container scales without a change. - Recycle a child after DIMS_MAX_CONNECTIONS_PER_CHILD connections, so its memory returns to the system.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The container sizes the httpd worker pool from its CPU allocation at start. An entrypoint reads the cgroup CPU quota and sets ServerLimit, ThreadsPerChild, and MaxRequestWorkers, so a larger container scales without a configuration change. A child is recycled after a number of connections, so its memory returns to the system. A soak test under a fixed CPU and memory limit sets the rule and the numbers, and ships as a tool under
test/soak/.Why
The image ran with the unconfigured httpd worker defaults, which allow hundreds of concurrent workers. Image work is CPU-bound and memory-heavy, so a large pool lowers throughput and raises memory. A soak test on 2, 4, and 6 vCPU containers found that throughput peaks near one worker per vCPU, and drops with more. Two threads per child, split across processes, give the lowest tail latency, because two processes share less ImageMagick lock state than one process with more threads. So
autosets ThreadsPerChild to 2 and ServerLimit to half the vCPU count, at least 2.Verify
Auto-size: run the image at
--cpus=2,4,6, and8. The startup log readsServerLimit=2/2/3/4. SetDIMS_SERVER_LIMITto a number to pin it.Soak:
bash test/soak/run.sh. It runs the production image under a hard CPU and memory limit, drives a mixed resize, crop, format, and watermark load, and reports throughput, tail latency, errors, peak memory, and the OOM-kill count for each configuration.CPUS,MEM, andSOAK_GRIDchange the envelope and the sweep.make testis unchanged. No C changed, and the test harness uses its own configuration.