# Cycle Consumption for Running Canisters **URL:** \ **Category:** Rust\ **Created:** [October 2, 2024, 12:51pm UTC](https://forum.dfinity.org/t/cycle-consumption-for-running-canisters/35745 "2024-10-02T12:51:53Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![gravity\_vi](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gravity_vi/32/35810_2.png) [@gravity\_vi](https://forum.dfinity.org/u/gravity_vi)\ **Post date:** [October 2, 2024, 12:51pm UTC](https://forum.dfinity.org/t/cycle-consumption-for-running-canisters/35745/1 "2024-10-02T12:51:53Z")
At Yral, we spend a significant amount on cycles to keep our entire fleet of canisters topped up. These canisters reside in ALL the available general app subnets. In the last 1 month, we’ve topped up our entire fleet with around 120K trillion cycles. For cycle topups, we’ve implemented our own solution that monitors canister cycle balances then estimates amounts to top up canisters that are running low. Previously, we calculated the required cycles based on the `idle_cycles_burned_per_day` metric and an assumption of maximum calls to our canisters. However, with the recent proposal to maintain reserved cycles according to subnet usage, we’re finding it more difficult to estimate the required cycles for our canisters. We’re repeatedly running into this situation in subnets with high memory utilisation where the cycle reservation mechanism is kicking in and causing calls to fail with an “Out of cycles” error message, even for canisters with over 2-3T cycle balances. We need more clarity on how the reserved cycles are calculated in relation to subnet usage? We need to precisely be able to calculate to be able to estimate how much to top up our canisters with. ---
**Author:** ![dsarlis](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/dsarlis/32/689_2.png) [@dsarlis](https://forum.dfinity.org/u/dsarlis)\ **Post date:** [October 2, 2024, 3:50pm UTC](https://forum.dfinity.org/t/cycle-consumption-for-running-canisters/35745/2 "2024-10-02T15:50:30Z")
I believe a simple fix would be to offset the balance of your canister by the `reserved_cycles` (which should also be returned by `canister_status`) to account for the amount that is currently reserved due to the storage reservation mechanism. In other words, your effective cycles balance should be reduced by the reserved amount, this is what you really have available. This should allow you to safely estimate taking into account the worst case of what is used up for reservations. ---
**Author:** ![icme](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icme/32/4327_2.png) [@icme](https://forum.dfinity.org/u/icme)\ **Post date:** [October 2, 2024, 6:15pm UTC](https://forum.dfinity.org/t/cycle-consumption-for-running-canisters/35745/3 "2024-10-02T18:15:53Z")
> [@gravity\_vi](#): > > We’re repeatedly running into this situation in subnets with high memory utilisation where the cycle reservation mechanism is kicking in and causing calls to fail with an “Out of cycles” error message, even for canisters with over 2-3T cycle balances. Out of curiosity are you receiving an out of cycles error message or a freezing threshold hit error message? @dsarlis A straight out of cycles error message suggests that maybe the error message needs improving/more clarity? Now that many subnets are reaching a level of memory utilization where the storage reservation kicks in, I’d expect more developers to be hitting this issue, especially new developers when they deploy their first canister (UX hurdle). Out of curiosity for the guys at Yral that are using a signficant portion of memory on many different subnets, how much of this memory utilization is from metadata stored in the canister, and how much of it is from duplicate wasms being stored? ---
**Author:** ![gravity\_vi](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gravity_vi/32/35810_2.png) [@gravity\_vi](https://forum.dfinity.org/u/gravity_vi)\ **Post date:** [October 3, 2024, 5:51am UTC](https://forum.dfinity.org/t/cycle-consumption-for-running-canisters/35745/4 "2024-10-03T05:51:51Z")
> [@dsarlis](#): > > In other words, your effective cycles balance should be reduced by the reserved amount, this is what you really have available. > > This should allow you to safely estimate taking into account the worst case of what is used up for reservations. Thanks, @dsarlis, for the quick response. I have a follow-up question: if I calculate cycles this way, it assumes that the reserved cycles in the canister are sufficient and that it won’t need to draw from the main balance to recharge. If it does need to draw additional cycles, we risk dropping calls due to insufficient cycles. ---
**Author:** ![dsarlis](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/dsarlis/32/689_2.png) [@dsarlis](https://forum.dfinity.org/u/dsarlis)\ **Post date:** [October 3, 2024, 7:52am UTC](https://forum.dfinity.org/t/cycle-consumption-for-running-canisters/35745/5 "2024-10-03T07:52:32Z")
> [@icme](#): > > @dsarlis A straight out of cycles error message suggests that maybe the error message needs improving/more clarity? I don’t think the message is just “Out of cycles”. We typically add some extra information, like “the canister was trying to do X, Y cycles were needed but only Z available, please top up”. > Now that many subnets are reaching a level of memory utilization where the storage reservation kicks in, I’d expect more developers to be hitting this issue, especially new developers when they deploy their first canister (UX hurdle). There’s one subnet in that range and a second one that is getting close. I don’t think the rest is within range yet. Let’s wait and see how things evolve, if indeed more users start facing UX issues, we can consider our options. ---
**Author:** ![dsarlis](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/dsarlis/32/689_2.png) [@dsarlis](https://forum.dfinity.org/u/dsarlis)\ **Post date:** [October 3, 2024, 7:54am UTC](https://forum.dfinity.org/t/cycle-consumption-for-running-canisters/35745/6 "2024-10-03T07:54:16Z")
So, IIUC, you check once in a while and you attempt to top up for a long-ish period ahead of time? In that case, you can instead use `reserved_cycles_limit` which is the maximum that your canister can have reserved ever (this is a canister setting that is also readable from `canister_status`). It’s a more conservative estimate than using `reserved_cycles` and checking more frequently but that should be a correct estimate to ensure smooth canister operations.