New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
~431 MB total RAM on 512 MB VPS?
I've got a KVM VPS with 512 MB RAM, however /proc/meminfo only shows ~431 MB total:
daniel@vps10:~$ cat /proc/meminfo
MemTotal: 442264 kB
MemFree: 295916 kB
...
Which matches what free -m shows:
daniel@vps10:~$ free -m
total used free shared buff/cache available
Mem: 431 42 290 3 99 368
Swap: 509 4 505
I asked the provider about it and they said "Yes, there are overheads to a virtual machine that will reduce the usable memory available to the guest operating system"
Is it normal to have ~15.8% overhead like that? It seems a bit misleading to include invisible overheads in the amount of RAM they advertise. I just checked a box at DigitalOcean (who apparently also use KVM) and the value is much closer to the full amount (for a 1 GB VPS, it shows 1031824 kB as MemTotal).
Comments
name and shame and help the community.
on ovh 2Gb you only get 1.71Gb
Yes, it's normal.
If you don't like it, continue switching hosts.
475.70 MB on my 512 kvm node
This is on a BudgetNode storage VPS. Other than the memory discrepancy, I'm really happy with it.
I just noticed something similar on my "main" VPS (BuyVM Slice 4096) - it's advertised as 4096 MB RAM but actually only has 3948 MB accessible:
I haven't actually switched hosts in a while, I'm just getting more servers for other projects with different requirements
It is normal. You can switch to an OpenVZ provider and you will likely get a full 512 MB RAM.
I tried that, but OpenVZ tends to use a ridiculously old kernel (2.6 series, which is nearly ten years old now) and Debian buster/testing refuses to run on anything older than 3.10.
So I'll just deal with the memory difference
this is actually not normal to me. 15% is too much
proxmox: 768mb
free -m
total used free shared buff/cache available
Mem: 751 148 77 23 525 447
Swap: 764 0 764
vmware: 1gb
free -m
total used free shared buff/cache available
Mem: 991 290 168 55 533 466
Swap: 1023 16 1007
solusvm: 1gb
free -m
total used free shared buffers cached
Mem: 992 437 555 0 260 121
-/+ buffers/cache: 56 936
Swap: 1987 0 1987
The VGA shared RAM eats some of the RAM.
If the host wants to steal, they would just steal by silent overprovisioning, not by garnishing the offered numbers which are as big as possible and used to bait customers.
Anyhow, i am not rejecting your claim 100%. It could be anything.
Someone actually read the OP and responded appropriately to the 15% in question.
It would be good to understand where this overhead goes so it can be appropriately configured, like swap space.
Could try,
For example for a KVM based VM which has 1 GB allocated to it,
root@local:~# free -m total used free shared buff/cache available Mem: 985 376 75 2 533 465 Swap: 1023 26 997While dmidecode shows a "1024 MB" stick present,
root@local:~# dmidecode -t memory # dmidecode 3.1 Getting SMBIOS data from sysfs. SMBIOS 2.4 present. Handle 0x1000, DMI type 16, 15 bytes Physical Memory Array Location: Other Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 1 GB Error Information Handle: Not Provided Number Of Devices: 1 Handle 0x1100, DMI type 17, 21 bytes Memory Device Array Handle: 0x1000 Error Information Handle: 0x0000 Total Width: 64 bits Data Width: 64 bits Size: 1024 MB Form Factor: DIMM Set: None Locator: DIMM 0 Bank Locator: Not Specified Type: RAM Type Detail: NoneInteresting, thanks @SpeedBus.
dmidecodedoes indeed show 512 MB:crashkernel might take some memory. Not sure if it's enabled on your servers.
It is the same as if you rent a dedicated server with 2 GB RAM, or if you purchase a desktop computer with 2 GB RAM. After you install your OS you'll see there's not quite 2 GB RAM available for use by applications since some memory is reserved for the kernel and stuff.
So it isn't really an invisible overhead because the memory is available to your software, it's just taken up by your OS and not available for your applications. If you installed a different OS you might see a bit less RAM used by the OS and more available for application. But ultimately it is your OS that is using the RAM, not the provider's infrastructure.
But I agree with what other people said, 81 MB is a bit high, what distribution are you using, and are you running the default kernel?
As far as I know, the full amount should still be reported to the OS, though? Or does the system reserved memory not even appear in
/proc/meminfoortop?... and drivers.
I did a bit of Googling and according to https://stackoverflow.com/questions/20348007/how-can-i-find-out-the-total-physical-memory-ram-of-my-linux-box-suitable-to-b you can check it from /proc/meminfo:
Edit:
dmesg | grep Memorymight also give some clues as to where your RAM is going.Interesting! On my 512 MB system:
which adds up to 511.98 MB.
@Daniel15 run
dmesg | grep Memoryit should print something like this:Memory: 2039116K/2096632K available (7502K kernel code, 1163K rwdata, 3440K rodata, 1376K init, 1448K bss, 57516K reserved)
So at least then you'll know if most of it is kernel code, reserved, or what.
Thanks you! That's useful
Still don't know why so much RAM is reserved, but at least I know it is reserved now. Will try other kernels when I get some free time, and see if that makes a difference.
If your running Centos, its probably being used by crashkernel
If you have less, make sure crashkernel is off...
That last bit of ram is reserved for the Kernel..
@IonSwitch_Stan I'm using Debian buster. I don't see anything relating to crashkernel in
/etc/default/grub.Windows and unix report ram differently.
Windows artificially limits RAM.
@IonSwitch_Stan - Is that a 32-bit or 64-bit VPS?
I figured this out!
I was using a PAE kernel (as that's what 32-bit Debian uses by default). PAE lets you use more than ~3 GB RAM on 32-bit systems. I guess it requires allocation of a mapping table to allow addressing the larger amount of RAM. I installed a non-PAE kernel (since I have no use for PAE) and now I have my RAM back:
Maybe I should use 64-bit, but I don't think 64-bit really has any advantages for systems with small amounts of RAM, and it can consume more RAM due to the larger pointer size.
Anyways, in the end this was my fault, not the provider's fault
no that's not it.
proxmox:
Linux suckit 4.9.0-8-686-pae #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) i686 GNU/Linux
768mb-
free -m
total used free shared buff/cache available
Mem: 751 148 98 23 504 447
Swap: 764 0 764
Hmm. I can consistently repro on my VPS. I have both
linux-image-4.18.0-3-686andlinux-image-4.18.0-3-686-paeinstalled. Identical version, only difference is PAE vs non-PAE. If I boot with the PAE one, I have ~431 MB RAM available. If I boot with the non-PAE one, I have ~496 MB RAM available.There's probably other factors that affect it, like SeaBIOS version, virtualization system (KVM vs Proxmox), etc.