System Information > System > Real Memory --- Incorrect

Submitted by twm on Tue, 07/16/2013 - 09:34

We just deployed a new virtualmin box and I just realized that under System Information > System > Real Memory the displayed amount of RAM is 512 and our server actually has 1024.

System Specs via Webmin: Operating system- CentOS Linux 6.4 Webmin version-1.630 Virtualmin version- 4.01.gpl GPL Theme version- 8.7 Time on server- 16/Jul/2013 07:09 , Up 15 hours, 53 minutes Kernel and CPU- Linux 2.6.18-028stab107.1 on x86_64 CPU load averages- 0.08 (1 min) 0.04 (5 mins) 0.01 (15 mins) Running processes- 50 Real memory- 512 MB total, 265.37 MB used Local disk space- 40 GB total, 1.29 GB used Package updates- All Virtualmin packages are up to date.

System Specs via SSH:

cat meminfo

MemTotal: 1048576 kB

cat version

Linux version 2.6.18-028stab107.1 (root@rhel5-build-x64) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Wed Apr 17 19:10:55 MSD 2013

cat cpuinfo

processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2630L 0 @ 2.00GHz stepping : 7 cpu MHz : 2000.078 cache size : 15360 KB

Any idea why this information is displaying incorrectly???

Status: 
Closed (fixed)

Comments

Submitted by andreychek on Tue, 07/16/2013 - 09:44

Howdy -- we're glad you were able to correct that.

That fix will be part of the next Webmin version.

Submitted by twm on Mon, 08/12/2013 - 16:10

I was mistaken to close this ticket. Real memory within Webmin states 4 GB total, 2.56 GB used. However the server only has 2GB of RAM.

# free -m
             total       used       free     shared    buffers     cached
Mem:          2048       2048          0          0          0          0
-/+ buffers/cache:       2048          0
Swap:            0          0          0

As you can see I am at 100% utilization for my RAM. Services keep locking up on a regular basis. I believe that Webmin/Virtualmin is allocating resources incorrectly because of this as the server was not locking up before when it incorrectly read 512MB of ram.

Thanks, Dustin Harrell

Submitted by andreychek on Mon, 08/12/2013 - 16:16

Webmin/Virtualmin doesn't actually allocate resources, it just reports what it sees in /proc.

It's up to the Linux kernel to properly allocate resources based on the available RAM.

We frequently see issues related to resource problems in OpenVZ, based on how it handles guaranteed vs burst RAM.

You may want to review your /proc/user_beancounters file -- when looking at that, are any of the "failcnt" fields non-zero?

If so, that means the Linux kernel is trying to allocate resources, but is being denied those resources by the OpenVZ container.

Submitted by twm on Tue, 08/13/2013 - 14:45

Here is what i am seeing... many many 0's

root@rhinonetworks:/home/rhinonetworks/public_html> cat /proc/user_beancounters
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
10091776:  kmemsize                  9280039              9410540  9223372036854775807  9223372036854775807                    0
            lockedpages                     0                    0  9223372036854775807  9223372036854775807                    0
            privvmpages                261569               272557              1048576              1048576              2736682
            shmpages                      879                  879  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numproc                        91                   93                32567                32567                    0
            physpages                   56182                58973  9223372036854775807  9223372036854775807                    0
            vmguarpages                     0                    0               524288  9223372036854775807                    0
            oomguarpages                56182                58973  9223372036854775807  9223372036854775807                    0
            numtcpsock                     22                   25  9223372036854775807  9223372036854775807                    0
            numflock                        7                    7  9223372036854775807  9223372036854775807                    0
            numpty                          1                    1                  255                  255                    0
            numsiginfo                      0                    1                 1024                 1024                    0
            tcpsndbuf                  910112              1010944  9223372036854775807  9223372036854775807                    0
            tcprcvbuf                  360448               409600  9223372036854775807  9223372036854775807                    0
            othersockbuf               225792              1331680  9223372036854775807  9223372036854775807                    0
            dgramrcvbuf                     0                 1312  9223372036854775807  9223372036854775807                    0
            numothersock                  133                  137  9223372036854775807  9223372036854775807                    0
            dcachesize                1135251              1153092  9223372036854775807  9223372036854775807                    0
            numfile                      3623                 3625  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            numiptent                      45                   45  9223372036854775807  9223372036854775807                    0

Submitted by twm on Tue, 08/13/2013 - 14:46

This is a GoDaddy VPS server with 2GB of RAM. Do you have any recommendations for me?

Submitted by andreychek on Tue, 08/13/2013 - 15:00

Yeah, it looks like the "failcnt" field for "privvmpages" (a type of RAM) is very high -- it's showing 2,736,682 failures.

That means processes requested RAM 2,736,682 times, but were denied that RAM by the OpenVZ container.

You may want to free up RAM on your system, or request more guaranteed RAM.

There's information here about freeing up RAM:

https://www.virtualmin.com/documentation/system/low-memory

We don't have recommendations of providers to use, though you may have less problems on a system not running OpenVZ. You may want to ask in the Forums for suggestions regarding providers.