You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Wrong resource usage often reported in multiple area #8927
Multiple user account reports CPU count not released after VM stopped/expunged and inaccurate secondary storage usage reported over time. There are no error been found in management server logs.
STEPS TO REPRODUCE
Spin up vm instance, stop it and delete it.
Create volume snapshot and delete it.
EXPECTED RESULTS
Resource limit usage should be updated and reflect to actual usage, and reconciliation should perform in regular basis.
@levindecaro There is a regular task which reconciles the limits. The period for this task is controlled by resourcecount.check.interval.
There are a few PRs which were merged recently which help reduce the discrepancies and speed up the resource count calculation as well. #8302 #8903
Over multiple operations there can be some discrepancies. But the regular resource count check should resolve that. Complete solving this requires a complete refactor of the current implementation or adding more locks which can impact the scalability of ACS itself.
@levindecaro , several queries (and possible actions)
is this an intermitted issue or consequent?
if this is really an issue with usage; for those resources you can check the events in the events table to see if some events were missed. You can enter them manually.
it sounds though like it is an issue with quota only, is that correct?
do you see chance to test , in a test environment, with the PRs @vishesh92 refers?
So far, I heard it is a intermitted issue from users, when they do some excess create/start/stop/destroy VM within a short period. After hours, the resource never went down, so i need to recalculate their used resource and update db table manually to solve this problem.
For the snapshot usage from secondary storage, there are nothing listed in volume snapshot, but resource limit page shown there are consumed spaces.
I'm no idea how to sort out it is a actual used space or just a orphan record.
This issue is stale because it has been open for 120 days with no activity. It may be removed by administrators of this project at any time. Remove the stale label or comment to request for removal of it to prevent this.
Activity
vishesh92 commentedon Apr 17, 2024
@levindecaro There is a regular task which reconciles the limits. The period for this task is controlled by
resourcecount.check.interval.There are a few PRs which were merged recently which help reduce the discrepancies and speed up the resource count calculation as well.
#8302
#8903
Over multiple operations there can be some discrepancies. But the regular resource count check should resolve that. Complete solving this requires a complete refactor of the current implementation or adding more locks which can impact the scalability of ACS itself.
levindecaro commentedon Apr 17, 2024
@vishesh92 I have resourcecount.check.interval=300 inplace, but seems not help for this discrepancies problem.
rajujith commentedon Apr 22, 2024
@levindecaro have you tried updating resource count for the account after deleting the VM as a workaround?
levindecaro commentedon Apr 22, 2024
@rajujith i did, but doesn't help
DaanHoogland commentedon Apr 24, 2024
@levindecaro , several queries (and possible actions)
levindecaro commentedon Apr 24, 2024
@DaanHoogland
So far, I heard it is a intermitted issue from users, when they do some excess create/start/stop/destroy VM within a short period. After hours, the resource never went down, so i need to recalculate their used resource and update db table manually to solve this problem.
For the snapshot usage from secondary storage, there are nothing listed in volume snapshot, but resource limit page shown there are consumed spaces.
I'm no idea how to sort out it is a actual used space or just a orphan record.
github-actions commentedon Dec 29, 2025
This issue is stale because it has been open for 120 days with no activity. It may be removed by administrators of this project at any time. Remove the stale label or comment to request for removal of it to prevent this.