How to see where cycles are being spent? which methods etc

Developers
1

I have a DIP20 token that’s burning > 0.1 T Cycles a day with next to no additional transaction being made…

Has there been any progress getting a dashboard for tracking cycles?

Right now this cycles issue is why I spend my dev time elsewhere so would really like a resolution to this please :pleading_face:

here’s my token info
https://info.icpswap.com/token/details/6ohjj-4qaaa-aaaai-aapua-cai

1 Like
2

I have just checked your canister and it looks like you are not using heartbeat, global_timer, or compute_allocation. Also, your memory usage is not large enough to justify the cost. But I have checked the rounds in which your canister is executed and it seems that it is executed not that rarely. The current execution round is 56646234 and the last executed round for your canister is 56646230, and I checked it multiple times in the last few hours, each time the last executed round for your canister was incremented. Since there’s no heartbeat or timer and the canister gets executed, it means that it must be processing some message.

Can you please specify what you meant by “no additional transaction being made”? Are you referring that your canister did not call any other canister or that it was not been called by another canister nor it had ingress messages?

We are working on a dashboard for tracking cycle consumption by use_case (Memory, Instructions, IngressInduction …), but now we are finalizing such a dashboard for subnets. The next step should be to make such tracking on per canister level. We have this on our list, but other projects are a higher priority and I cannot give an ETA on when this one will be done.

3 Likes
3

Thank you @dragoljub_duric :grinning: for looking into this.
Its based on DIP20 token standard GitHub - Psychedelic/DIP20: DIP20: A fungible token standard for the DFINITY Internet Computer.
So I mean token transactions.

I’m surprised that canister level cycle tracking isn’t a higher priority, especially in such a new dev environment. :thinking:

haven’t been able to upgrade dfx version for the project because of this

tried removing the website asset canister from the project in the dfx.json config and removing the version lock “dfx”: “0.10.1” and then re deployed the token canister with latest “0.13.1” and it deployed the canister with out the usual error on any version past “0.10.1”
so hoping this might somehow help reduce the cycle bleed :crossed_fingers:

4

Hey @AVOlight,

note that you can track the cycle consumption of your canisters yourself. Have a look at the links here for example.

2 Likes
5

@domwoe Thank you :grinning: yes that how I got here.

Hopefully :pray: soon there will be a way to track which messages use the most cycles.

Unfortunately for me the upgrade hasn’t reduced the cycle bleed… :sweat_smile: