Difference between revisions of "UBC failcnt reset"
m |
(Grammar, misc cleanup) |
||
| Line 7: | Line 7: | ||
You do not need to, and this would be an incorrect thing to do. | You do not need to, and this would be an incorrect thing to do. | ||
| − | There can be many | + | There can be many applications that read <code>/proc/user_beancounters</code>, 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! == | == OK, I understand, but I still want to clear failcnt! == | ||
| − | + | UBC failcnts are stored for the duration of the uptime of your VE. Thus, restarting the VE resets the counts. | |
The problem here is tcp time wait buckets can still there after a VE is stopped. You can check that by seeing the <code>held</code> column for <code>kmemsize</code> 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. | The problem here is tcp time wait buckets can still there after a VE is stopped. You can check that by seeing the <code>held</code> column for <code>kmemsize</code> 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. | ||
Revision as of 10:40, 21 December 2007
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 VE. 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 VE. Thus, restarting the VE resets the counts.
The problem here is tcp time wait buckets can still there after a VE 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 VE 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 VE 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
