Recommendation for aws_event_loop_group_new_default max_threads argument in container environment?

[quinnj]

I'm calling aws_event_loop_group_new_default with maxthreads = 0, but running into issues in a containerized environment, because I'm seeing event loop groups = # of node cores, not what has been allocated to my container specifically. This is an issue, I believe (not quite sure if/how to confirm), because my node has a pretty high bandwidth and I'm hooking up to a TCP socket which is set to read as fast as possible, but my actual container has limited resources to process.

I'm also aware that I probably need to adjust/utilize my socket window size/backpressure settings, but the first thing I noticed was wanting to ensure the # of event loop groups isn't more than my container can handle.

So my question: is there an official recommendation or some kind of automatic way to call aws_event_loop_group_new_default to respect cgroup cpu limits? Or do I just need to hard-code/configure that in my application initialization?

[graebm]

How are you limiting CPU? --cpuset-cpus? --cpus? --cpu-count? other?

I'm not personally familiar with this stuff. Let me do some quick research if there's a way to do this automatically...

Currently, our code calls aws_system_info_processor_count() (source), which calls sysconf(_SC_NPROCESSORS_ONLN) which returns "The number of processors currently online (available)." (docs).

Looking at Python's os.cpu_count(), it also calls sysconf(_SC_NPROCESSORS_ONLN) (source). cpython's github has a 5 year old issue (link), asking for it to respect cgroup and ... wow the conversation goes on for years. A lot of people warn about lack of standardization in how cgroups work... In the latest release python 3.13 it's still using sysconf(_SC_NPROCESSORS_ONLN), but users can override it with environment variable PYTHON_CPU_COUNT.

Java's Runtime.availableProcessors() (docs) has a much more complex implementation (source) which starts with this comment:

// Get the current number of available processors for this process.
// This value can change at any time during a process's lifetime.
// sched_getaffinity gives an accurate answer as it accounts for cpusets.
// If it appears there may be more than 1024 processors then we do a
// dynamic check - see 6515172 for details.
// If anything goes wrong we fallback to returning the number of online
// processors - which can be greater than the number available to the process.

So it seems possible we could do something smarter automatically, but it would take more research to be sure we were doing the right thing, and time would need to be carved out to work on it.

It would definitely be faster for you to set it yourself to what you need in the meantime