Difference between revisions of "UBC failcnt reset"
Botinki Kira (talk | contribs) m (Robot: Automated text replacement (-VE +container)) |
(added link to bug) |
||
| Line 20: | Line 20: | ||
If you're sure your kernel was NOT compiled with the above option and it's not resetting failcnt after 5 minutes, it means there is a bug in UBC code. Please file a detailed [[bug report]] to [http://bugzilla.openvz.org bugzilla.openvz.org] | If you're sure your kernel was NOT compiled with the above option and it's not resetting failcnt after 5 minutes, it means there is a bug in UBC code. Please file a detailed [[bug report]] to [http://bugzilla.openvz.org bugzilla.openvz.org] | ||
| + | |||
| + | == Tool == | ||
| + | |||
| + | See {{Bug|1298}}. | ||
== External links == | == External links == | ||
Revision as of 06:41, 12 May 2011
One of the frequently asked question is How do I reset failcnt in /proc/user_beancounters? While it's not suggested, it is possible.
Contents
What is failcnt?
There are a number of resource limits (called User Beancounters, or UBC for short) set for a container. If one of those resources hit its limit, the appropriate fail counter (last column of /proc/user_beancounters) increases. See Resource shortage for more info.
How to clear failcnt?
You do not need to, and this would be an incorrect thing to do.
There can be many applications that read /proc/user_beancounters, and thus if you will reset it, you may have problems with those other apps. Consider what happens if you reset your sent/received packets/bytes statistics on a network interface — programs which track it may not function properly.
Therefore, the proper usage of failcnt is not to check whether it is zero or not, but to check whether it is increased since the previous readout. In other words, check the difference, not the absolute value. It is easy to write a simple script to do just that.
OK, I understand, but I still want to clear failcnt!
UBC failcnts are stored for the duration of the uptime of your container. Thus, restarting the container resets the counts.
The problem here is tcp time wait buckets can still there after a container is stopped. You can check that by seeing the held column for kmemsize parameter. If it is not zero, that means you have to wait about 5 minutes in order to time wait buckets to expire, and the corresponding beancounter to be uncharged.
If you still see failcnt not reset to 0 after more than 5 minutes after container is stopped, your kernel was likely compiled with CONFIG_UBC_KEEP_UNUSED=y, and in that case you'll have to switch off this option if you want to reset beancounters when container is restarted.
If you're sure your kernel was NOT compiled with the above option and it's not resetting failcnt after 5 minutes, it means there is a bug in UBC code. Please file a detailed bug report to bugzilla.openvz.org
Tool
See OpenVZ Bug #1298.
