[Users] occasional high loadavg without any noticeable cpu/memory/io load

Kirill Korotaev dev at parallels.com
Tue May 22 07:05:16 EDT 2012


Looks like in your case you've hit physpages limit.
In such situations VPS behaves as a standalone machine - it starts to swap out (though "virtually") and process stuck in D state (swap in / swap out),
which contributes  to loadavg.

So either increase memory limits for your VPS or kill/tune the memory hungry workload.

Note: loadavg can also increase due to CPU limits as processes are delayed when overuse their CPU.

Thanks,
Kirill


On May 22, 2012, at 14:49 , Rene C. wrote:


Hi Esme,

> Did you check the /proc/user_beancounters of that VPS? Sometime’s a high load could be caused by buffers that are full.

Thanks for the suggestion, much appreciated!

I didn't think of checking at the time I'm afraid.  I suppose since the container has not been rebooted since, the beancounters should still show any problems encountered at the time right?

Below is the user_beancounters of the problem CT. I notice physpages and dcachesize have maxheld values very close to limits (even if failcnt is zero) could that have been the cause?


      uid  resource                     held              maxheld              barrier                limit              failcnt
    1407:  kmemsize                252703307           1124626432           1932525568           2147483648                    0
           lockedpages                     0                   15               524288               524288                    0
           privvmpages                893372              5683554  9223372036854775807  9223372036854775807                    0
           shmpages                       23                 7399  9223372036854775807  9223372036854775807                    0
           dummy                           0                    0                    0                    0                    0
           numproc                       136                  480  9223372036854775807  9223372036854775807                    0
           physpages                  733468              1048591                    0              1048576                    0
           vmguarpages                     0                    0                    0  9223372036854775807                    0
           oomguarpages               137691               676209                    0  9223372036854775807                    0
           numtcpsock                    101                  459  9223372036854775807  9223372036854775807                    0
           numflock                        7                   37  9223372036854775807  9223372036854775807                    0
           numpty                          1                    4  9223372036854775807  9223372036854775807                    0
           numsiginfo                      0                   66  9223372036854775807  9223372036854775807                    0
           tcpsndbuf                 4024896             34884168  9223372036854775807  9223372036854775807                    0
           tcprcvbuf                 1654784              7520256  9223372036854775807  9223372036854775807                    0
           othersockbuf               195136              3887232  9223372036854775807  9223372036854775807                    0
           dgramrcvbuf                     0               155848  9223372036854775807  9223372036854775807                    0
           numothersock                  130                  346  9223372036854775807  9223372036854775807                    0
           dcachesize              222868425           1073741824            965738496           1073741824                    0
           numfile                      3853                12765  9223372036854775807  9223372036854775807                    0
           dummy                           0                    0                    0                    0                    0
           dummy                           0                    0                    0                    0                    0
           dummy                           0                    0                    0                    0                    0
           numiptent                     197                  197  9223372036854775807  9223372036854775807                    0

I'm not that familiar with the nitty-gritties of the beancounters but these are the values I have in the 1407.conf file.

PHYSPAGES="0:4096M"
SWAPPAGES="0:8192M"
KMEMSIZE="1843M:2048M"
DCACHESIZE="921M:1024M"
LOCKEDPAGES="2048M"
PRIVVMPAGES="unlimited"
SHMPAGES="unlimited"
NUMPROC="unlimited"
VMGUARPAGES="0:unlimited"
OOMGUARPAGES="0:unlimited"
NUMTCPSOCK="unlimited"
NUMFLOCK="unlimited"
NUMPTY="unlimited"
NUMSIGINFO="unlimited"
TCPSNDBUF="unlimited"
TCPRCVBUF="unlimited"
OTHERSOCKBUF="unlimited"
DGRAMRCVBUF="unlimited"
NUMOTHERSOCK="unlimited"
NUMFILE="unlimited"
NUMIPTENT="unlimited"

When user_beancounters physpage limit is 1048576, with PHYSPAGES set to 4GB, then the held value of 733468 should correspond to about 3GB, right?  But top only shows about 1.5GB used at the same time - how is that possible?

dcachesize I think is filesystem stuff?  But there seems to be plenty of resources there;

# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/simfs           20000000 3046139 16953861   16% /
none                  524288     109  524179    1% /dev
# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/simfs            492G  156G  312G  34% /
none                  2.0G  4.0K  2.0G   1% /dev

Best,
Rene
<ATT00001.c>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openvz.org/pipermail/users/attachments/20120522/9a4128fc/attachment-0001.html


More information about the Users mailing list