Open dograprabhav opened 3 weeks ago
@dograprabhav I was thinking that workloads such as databases would run on dedicated nodes. We are designing DiceDB to be running optimally on modern multi-core hardware extracting the max performance out of it. However I agree, we need a more sophisticated logic to run DiceDB that allocating all cores to it blindly. Irrespective this change may be helpful in test environments. @arpitbbhayani @AshwinKul28 @lucifercr07 wdyt?
Adding it to icebox for now.
@lucifercr07 can I take this up?
optional config for num cpu sounds like a good idea can I solve this?
Was going through the code of DiceDB, specifically this snippet:
Currently, DiceDB dynamically configures its threading model based on the
EnableMultiThreading
flag in the configuration, defaulting to the number of logical CPU cores available viaruntime.NumCPU()
when multi-threading is enabled. However, this approach can be problematic in containerized environments, such as Kubernetes, where resource constraints (e.g., CPU limits) are enforced per container.In Kubernetes, a container can be allocated a specific number of CPU cores, and using
runtime.NumCPU()
may not reflect these limits accurately. For example, if the host machine has 16 cores but a container is only allocated 4 cores, DiceDB would still use all 16 cores unlessGOMAXPROCS
is manually set. This could lead to resource contention, poor performance, or overuse of allocated resources, resulting in throttling by the container orchestrator.Issue Summary:
I can pick up these changes, can you assign this issue to me @lucifercr07 @JyotinderSingh @AshwinKul28 @arpitbbhayani