Problem running hardware resources or installing applications on your virtual server? The best and quickest way to find issue or failcnt is to use the special file called /proc/user_beancounters which shows the resource control information and how to use it within virtual container.
To view /proc/user_beancounters on your VPS, login to your VPS via SSH.
In the SSH Terminal you will type:
cat /proc/user_beancounters
Then hit Enter.
After you hit Enter, you should see something that looks similar to the following:
Version: 2.5
uid resource held maxheld barrier limit failcnt
10045182: kmemsize 45607650 85962752 202133143 222346456 0
lockedpages 0 16 2670 2670 0
privvmpages 711811 1054181 4718592 4718592 0
shmpages 190715 239867 327680 327680 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numproc 133 216 1600 1600 0
physpages 369453 491566 4718592 4718592 0
vmguarpages 0 0 3145728 2147483647 0
oomguarpages 303416 356857 3145728 2147483647 0
numtcpsock 209 360 3000 3000 0
numflock 15 32 2000 2000 0
numpty 5 22 512 512 0
numsiginfo 9 60 1024 1024 0
tcpsndbuf 1831448 4083744 9582922 13674826 0
tcprcvbuf 1190136 2702272 9582922 13674826 0
othersockbuf 274864 1152216 3194307 5922243 0
dgramrcvbuf 0 18496 3194307 3194307 0
numothersock 195 245 3000 3000 0
dcachesize 9461297 9461760 8515584 9461760 0
numfile 5858 6830 30000 30000 0
dummy 0 0 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numiptent 24 24 384 384 0
OR Picture:
On top line where you see uid to the left of it, that line is the field that displays the numeric identifier for your VPS.
The field held shows the current counter for the Private Virtual servers (resource “usage”).
The field maxheld shows the counter’s maximum for the lifetime of the Virtual server. The lifetime of the Virtual server/Node/Vserver is usually just the time between the start and stop of your VPS.
The barrier and limit fields are resource control settings. Few parameters only one of them may be used, for others, both. These fields may display resource limits or guarantees, and the exact meaning of them is parameter-specific.
The field failcnt shows the number of refused “resource allocations” for the lifetime of the VPS. Failcnt counter is increased only for accounting parameters.The best way to check the errors is to check failcnt
If there is numbers mentioned below of Failcnt like: 111 etc. the VPS did not have enough memory available to install an application or give equal hardware resources. That is the reason why failcnt will show you numbers and memory failures, next to the parameter kmemsize in it’s /proc/user_beancounters file. We know the problem was memory since the failcnt next to kmemsize increased after trying to install the application. source
More information below.
UBC auxiliary parameters
Configuration of primary and secondary resource control parameters is important for security and stability of the whole system. Auxiliary parameters differ much from primary and secondary parameters in this respect.
The primary functions of auxiliary parameters are the following.
- These parameters improve application’s handling of errors and resource consumption limitations. Without these auxiliary parameters, possible bugs in applications (such as forgetting to unlock locked files or forgetting to collect signals) will cause slowdown and, after some time, killing of the applications because of memory exhaustion. In presence of these parameters, applications will notice the problem (because, for example, attempts to create new file locks start to fail) and show an appropriate message helping to debug the problem. Another example. Each object such as opened file or established network connection consume certain resources. When the container is close to exhaustion of the resources allowed to him, it is usually better to refuse creation of new object than to allow it but deny memory allocation or terminate (in case of complete exhaustion of the resources) an already running application.
- These parameters improve fault isolation between applications in the same container. Failures or misbehavior of one application inside a container is more likely to cause hitting a limit on some auxiliary parameter and normal termination of this mis- behaving application, rather than abnormal termination of some other long-running application inside the same container.
- These parameters may be used to impose some administrative limits on the container (for example, to not allow the user to run database servers by limiting the amount of shmpages, or limiting the number of simultaneous shell sessions through numpty).
So, auxiliary parameters play a role similar to limits imposed by setrlimit(2) interface and limits configurable by sysctl(8) in standard Linux installations.
Because of this helper role in resource control, system management software may show auxiliary parameters only in advanced mode for experienced administrators and hide them in “basic” management modes.
lockedpages Process pages not allowed to be swapped out (pages locked by mlock(2)). The size of these pages is also accounted into kmemsize. The barrier may be set equal to the limit or may allow some gap between the barrier and the limit, depending on the nature of applications using memory locking features. Note that typical server applications like Web, FTP, mail servers do not use memory locking features. The configuration of this parameter doesn't affect security and stability of the whole system or isolation between containers. Its configuration affects functionality and resource shortage reaction of applications in the given container only.
shmpages: The total size of shared memory (IPC, shared anonymous mappings and tmpfs objects). These pages are also accounted into privvmpages. The barrier should be set equal to the limit. The configuration of this parameter doesn't affect security and stability of the whole system or isolation between containers. Its configuration affects functionality and resource shortage reaction of applications in the given container only.
physpages Total number of RAM pages used by processes in a container. For memory pages used by several different containers (mappings of shared libraries, for example), only a fraction of a page is charged to each container. The sum of the physpages usage for all containers corresponds to the total number of pages used in the system by all containers. For VSwap-enabled kernels, the barrier should be set to 0, and the limit limits the total size of RAM used by a container. For older kernels, physpages is an accounting-only parameter. The barrier should be set to 0 and the limit to 'unlimited' (LONG_MAX).
numfile Number of open files. The barrier should be set equal to the limit. The configuration of this parameter doesn't affect security and stability of the whole system or isolation between containers. Its configuration affects functionality and resource shortage reaction of applications in the given container only. Note: actually currently adjusting the barrier will change the kernel behaviour on "pre-charging" the numfile resource. If you change one you will most likely not notice any changes in container behaviour at all. This ability was added for researching purposes purely.
numflock Number of file locks. The configuration of this parameter should have a gap between the barrier and the limit, as illustrated in UBC configuration examples. Very high limits on numflock parameters and the big number of file locks in the system may cause certain slowdown of the whole system (but not fatal). So, the limits on this parameter should be reasonable, depending on the real requirements of the applications.
numpty Number of pseudo-terminals. This parameter is usually used to limit the number of simultaneous shell sessions. The barrier should be set equal to the limit. The configuration of this parameter doesn't affect security and stability of the whole system or isolation between containers. Its configuration affects functionality and resource shortage reaction of applications in the given container only. However, in OpenVZ systems, the actual number of pseudo-terminals allowed for one container is limited to 256.
numsiginfo Number of siginfo structures. The size of the structure is also accounted into kmemsize. The default installations of stand-alone Linux systems limit this number to 1024 for the whole system. In OpenVZ installations, numsiginfo limit applies to each container individually. The barrier should be set equal to the limit. Very high settings of the limit of this parameter may reduce responsiveness of the system. It is unlikely that any container will need the limit greater than the Linux default — 1024.
dcachesize The total size of dentry and inode structures locked in memory. Dcachesize parameter controls filesystem-related caches, such as directory entry (dentry) and inode caches. The value accounted into dcachesize is also included into kmemsize. Dcachesize exists as a separate parameter to impose a limit causing file operations to sense memory shortage and return an error to applications, protecting from memory shortages during critical operations that shouldn't fail. The configuration of this parameter should have a gap between the barrier and the limit, as illustrated in UBC configuration examples. The configuration of this parameter doesn't affect security and stability of the whole system or isolation between containers. Its configuration affects functionality and resource shortage reaction of applications in the given container only.
numiptent The number of NETFILTER (IP packet filtering) entries. The barrier should be set equal to the limit. There is a restriction on the total number of numiptent. It depends on the amount of other allocations in so called “vmalloc” memory area and constitutes about 250000 entries. Violation of this restriction may cause failures of operations with IP packet filter tables (execution of iptables(8)) in any container or the host system, or failures of container starts. Also, large numiptent cause considerable slowdown of processing of network packets. It is not recommended to allow containers to create more than 200–300 numiptent.
swappages The amount of swap space to show in container. Yellowpin.svg Note: this parameter is only available in RHEL5-based kernel since version 028stab060.2, in 2.6.27 since kiprensky. The configuration of this parameter doesn't affect security and stability of the whole system or isolation between containers. Its configuration only affects the way OpenVZ kernel reports about available swap in a container. This is needed for some applications which refuse to run inside a container unless the kernel report that no less than some specific amount of swap is available. If limit is set, its value is reported as the amount of total swap space in a container. If the limit is set to LONG_MAX (which is the in-kernel default for this parameter), all the swap space values parameters (total, used, free) are reported as 0. The value of barrier for this beancounter is ignored. The value of held shows how much swap space is currently being used for this container.
For more reference please visit: UBC auxiliary parameters