In fact, if you install 2G of memory, the total: 1876 can already prove that it is 2G of memory. . If there is a problem with the memory, is it because 3G has shrunk to 1876?
It can be seen that the questioner is still dissatisfied with the algorithm of 1024. How can he calculate 1876?
Please run the 2 commands and post the results
1.cat /proc/meminfo |grep MemTotal
2.free -b
I am using 4G as an example (there is really no 2G machine)
1.free -m
total:3852 MB
1.free -b(This unit is bytes!)
total:4039471104 bytes
2.cat /proc/meminfo |grep MemTotal
3944796 kB
3944796 kB*1024=4039471104bytes, the result is the same as free -b
You are not fooled, it is 2G memory.
The manufacturer says 2GB, the unit is Gigabyte, 1GB is equal to 1000^3 Byte
When we usually talk about GB, the unit is Gibibyte. The standard abbreviation should be GiB, which is equal to 1024^3 Byte
Therefore, the data on both sides will be inconsistent.
The accurate method is:
dmidecode -t memory | grep 'Installed Size'
(The content of grep varies depending on the release version. I am CentOS 6. If you are not sure, you can skip grep and just look at it. There is a lot of content)
Why is free -m inaccurate: The free command takes the value from /proc/meminfo for display, and the MemTotal in /proc/meminfo is actually the physical memory minus some reserved bits and the binary code size of the kernel, so it is Lowercase than physical memory.
The above is one of my Alibaba Cloud hosts, which is also missing. Now service providers generally say that it is caused by the difference between the 1024 and 1000 algorithms, which is generally considered normal. The same goes for buying hard drive hardware.
In fact, if you install 2G of memory, the total: 1876 can already prove that it is 2G of memory. . If there is a problem with the memory, is it because 3G has shrunk to 1876?
It can be seen that the questioner is still dissatisfied with the algorithm of 1024. How can he calculate 1876?
Please run the 2 commands and post the results
1.
cat /proc/meminfo |grep MemTotal
2.
free -b
I am using 4G as an example (there is really no 2G machine)
1.
free -m
total:3852 MB
1.
free -b
(This unit is bytes!)total:4039471104 bytes
2.
cat /proc/meminfo |grep MemTotal
3944796 kB
3944796 kB*1024=4039471104bytes, the result is the same as free -b
4039471104bytes / 1024=3944796 kB / 1024=3852.33984375MB
As you can see. . do you understand? Or you can run these 3 commands and post them, and you’ll know after some math
You are not fooled, it is 2G memory.
The manufacturer says 2GB, the unit is Gigabyte, 1GB is equal to 1000^3 Byte
When we usually talk about GB, the unit is Gibibyte. The standard abbreviation should be GiB, which is equal to 1024^3 Byte
Therefore, the data on both sides will be inconsistent.
The accurate method is:
(The content of grep varies depending on the release version. I am CentOS 6. If you are not sure, you can skip grep and just look at it. There is a lot of content)
Why is free -m inaccurate: The free command takes the value from /proc/meminfo for display, and the MemTotal in /proc/meminfo is actually the physical memory minus some reserved bits and the binary code size of the kernel, so it is Lowercase than physical memory.
free-m
total used free shared buffers cached
Mem: 488 424 64 54 22 205
-/+ buffers/cache: 196 292
Swap: 1999 0 1999
The above is one of my Alibaba Cloud hosts, which is also missing. Now service providers generally say that it is caused by the difference between the 1024 and 1000 algorithms, which is generally considered normal. The same goes for buying hard drive hardware.
This is the normal value of 2G