# High CPU Usage When Running As Dockerized Container On Ubuntu 20.04 **URL:** \ **Category:** Dragonfly Technical\ **Created:** [August 6, 2024, 8:14am UTC](https://dragonfly.discourse.group/t/high-cpu-usage-when-running-as-dockerized-container-on-ubuntu-20-04/193 "2024-08-06T08:14:48Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![foxmuldersatya](https://yyz2.discourse-cdn.com/flex004/user_avatar/dragonfly.discourse.group/foxmuldersatya/32/64_2.png) [@foxmuldersatya](https://dragonfly.discourse.group/u/foxmuldersatya)\ **Post date:** [August 6, 2024, 8:14am UTC](https://dragonfly.discourse.group/t/high-cpu-usage-when-running-as-dockerized-container-on-ubuntu-20-04/193/1 "2024-08-06T08:14:48Z")
Hello everyone, I have setup Dragon Fly as a dockerized container which is accessed by a couple of spring boot services. The CPU usage of dragon fly seems to be higher when compared to Redis in idle and under load scenarios, details below: 1 - Dragon Fly container running with no load - CPU usage sitting at 25 % 2 - Dragon Fly container running with some load from spring boot services , CPU usage at 175 % These stats are from Ubuntu 20.04. When I tried swapping the Dragon Fly image with Redis image, then the same numbers are at 5% and 28% respectively. Are there any configuration changes that I can do to the dragon fly container which results in less CPU usage? ---
**Author:** ![joezhou\_df](https://yyz2.discourse-cdn.com/flex004/user_avatar/dragonfly.discourse.group/joezhou_df/32/82_2.png) [@joezhou\_df](https://dragonfly.discourse.group/u/joezhou_df)\ **Post date:** [August 7, 2024, 5:47pm UTC](https://dragonfly.discourse.group/t/high-cpu-usage-when-running-as-dockerized-container-on-ubuntu-20-04/193/2 "2024-08-07T17:47:23Z")
As suggested by Dragonfly core team member Shahar on the [Discord server](https://discord.gg/HsPjXGVH85), limiting the number of threads Dragonfly uses by setting the `--proactor_threads=X` parameter would help in this situation. ---
**Author:** ![joezhou\_df](https://yyz2.discourse-cdn.com/flex004/user_avatar/dragonfly.discourse.group/joezhou_df/32/82_2.png) [@joezhou\_df](https://dragonfly.discourse.group/u/joezhou_df)\ **Post date:** [August 7, 2024, 5:52pm UTC](https://dragonfly.discourse.group/t/high-cpu-usage-when-running-as-dockerized-container-on-ubuntu-20-04/193/3 "2024-08-07T17:52:58Z")
Personally, I would also like to share that Dragonfly performs best when running on bare metal without noisy neighbours on the same machine. It is also helpful to set the number of threads to match the number of cores on the machine. Not that Dragonfly is high maintenance, but if you think about it, it’s a platform responding to millions of ops/sec constantly within sub-millisecond latency. 😀 However, orchestrated containers definitely ease some operational work. ---
**Author:** ![foxmuldersatya](https://yyz2.discourse-cdn.com/flex004/user_avatar/dragonfly.discourse.group/foxmuldersatya/32/64_2.png) [@foxmuldersatya](https://dragonfly.discourse.group/u/foxmuldersatya)\ **Post date:** [August 8, 2024, 5:49am UTC](https://dragonfly.discourse.group/t/high-cpu-usage-when-running-as-dockerized-container-on-ubuntu-20-04/193/4 "2024-08-08T05:49:17Z")
Thank you for the suggestions, will try and update you folks. ---
**Author:** ![foxmuldersatya](https://yyz2.discourse-cdn.com/flex004/user_avatar/dragonfly.discourse.group/foxmuldersatya/32/64_2.png) [@foxmuldersatya](https://dragonfly.discourse.group/u/foxmuldersatya)\ **Post date:** [August 9, 2024, 2:53pm UTC](https://dragonfly.discourse.group/t/high-cpu-usage-when-running-as-dockerized-container-on-ubuntu-20-04/193/5 "2024-08-09T14:53:59Z")
A couple of updates: 1. Setting proactor\_threads=1 does help significantly in a local environment, however what are the repercussions of this when running in production, should this even be used in production? 2. Understand that ideally it should be running on bare metal and thats when we should really be looking at the CPU usage, thanks! 3. My code was polling dragon fly using KEYS command, which I have now refactored to use SCAN, and that helped to bring the CPU usage down by about 20% ---
**Author:** ![joezhou\_df](https://yyz2.discourse-cdn.com/flex004/user_avatar/dragonfly.discourse.group/joezhou_df/32/82_2.png) [@joezhou\_df](https://dragonfly.discourse.group/u/joezhou_df)\ **Post date:** [August 12, 2024, 5:24pm UTC](https://dragonfly.discourse.group/t/high-cpu-usage-when-running-as-dockerized-container-on-ubuntu-20-04/193/6 "2024-08-12T17:24:03Z")
Good to know! I agree that `proactor_threads=1` is not a very good choice for production. It should match the cores you have on that production machine. In terms of commands, `KEYS` is definitely discouraged for production usage because it’s very expensive. `SCAN` is much better, but it’s also not the strongest command in terms of performance. As an in-memory key-value data store, Dragonfly is the strongest if the data access patterns are by keys. 😄 Maybe you can share your use case, and we can try to find ways to reduce the `SCAN` command usage. ---
**Author:** ![foxmuldersatya](https://yyz2.discourse-cdn.com/flex004/user_avatar/dragonfly.discourse.group/foxmuldersatya/32/64_2.png) [@foxmuldersatya](https://dragonfly.discourse.group/u/foxmuldersatya)\ **Post date:** [August 13, 2024, 12:01pm UTC](https://dragonfly.discourse.group/t/high-cpu-usage-when-running-as-dockerized-container-on-ubuntu-20-04/193/7 "2024-08-13T12:01:03Z")
hey @joezhou_df , the use case at a high level is described below: So we have multiple sorted sets (which are basically like priority queues), but they are fairly large so instead maintaining in memory queues , we are maintaining on Dragon Fly. Each Sorted set is identified by a key, this key itself is dynamic based on the inputs received. We need to perform certain actions for each item on the queue stored against each key. Since we are not aware of the exact key and the number of keys, we are polling dragon fly to check 2 things: 1.Get all the keys, lets say we retrieved 5 keys. 2.Iterate on all the 5 keys and check for each sorted set stored against each key, see if the sorted set has any elements, if yes, pick the first element of the set for processing. This process keeps going on indefinitely. Have a look at the image I attached, here M1, M2 , M3 , M4 are the keys which I am finding using the scan command using the pattern M\*. Then I get 4 queues OR sorted sets as they are called in dragon fly and process each of those elements. I have been sort of thinking what would be better between polling and doing a publish subscribe, however need to keep in mind that we can have multiple instances of the spring boot service which does this process Let me know your thoughts. ![image](https://canada1.discourse-cdn.com/flex004/uploads/dragonfly/original/1X/69f4b00969a78db39140a0dcf3fa4804a733a683.png) ---
**Author:** ![joezhou\_df](https://yyz2.discourse-cdn.com/flex004/user_avatar/dragonfly.discourse.group/joezhou_df/32/82_2.png) [@joezhou\_df](https://dragonfly.discourse.group/u/joezhou_df)\ **Post date:** [August 26, 2024, 2:42pm UTC](https://dragonfly.discourse.group/t/high-cpu-usage-when-running-as-dockerized-container-on-ubuntu-20-04/193/8 "2024-08-26T14:42:14Z")
Hey, thanks for the information. > Each sorted set is identified by a key, this key itself is dynamic based on the inputs received. > Since we are not aware of the exact key and the number of keys, we are polling Dragonfly. I think this is the problem. For Dragonfly, the access pattern should ideally be from **key → value** , which means that a deterministic key is crucial. Once you have all the keys, operating on them however you like generally won’t be a problem. The bottleneck is still your access pattern. Maybe you can think of a better way in your application to deal with this logic. If `SCAN` is not avoidable, then I’d say that Dragonfly is still not used in the best way.