服务器内存和实际不符问题

1、系统启动时会初始化相关设备，该过程会占用内存，内核启动时，也会占用一部分的内存
2、free -t 命令查询的是云服务器的可用内存，dmidecode -t memory 命令查询的是实际硬件内存大小，因此，使用 free -m 命令查询到的内存大小比实际的要小一些，属于正常情况。

【分析示例】举例说明：

1.先通过free命令核实当前系统中内存大小

2.通过 kernel log 查看内存初始化信息，核实内存预留情况：

可以看到在内核加载过程中，系统分配的可供用户使用内存为 1860324k【1882192-1860324=21868k】
加载过程中仍有21868k内存不知去向。继续分析：
kernel code ：表示kernel的代码，属于reserved memory
absent：表示不可用的物理内存大小。如有一部分物理内存被BIOS保留，且kernel也是不可用的
reserved：包括【initrd】和【内核代码及数据】以及【kdump】等，其中内核代码和部分数据包含在下列统计值【kernel code、data】中
（查看kdump在grub.cfg配置crashkernel为auto的前提下，2G内存服务器默认预留了160M左右）

data ：表示kernel的可读可写的数据和只读数据大小，属于reserved memory
init ：表示init code和init data，属于reserved memory，但引导完成之后会释放给 free memory
PS：这里 reserved 中已经包含了内核初始化完成后会被释放出来的内存

3.接下来通过 kernel log 核实下内核初始化完成后被释放的内存

初始化后释放给用户的内存总和为：
28+18892+1980+416+552=21868k
21868+1860324=1882192k【最终系统完全启动后分配给用户的内存就为free查到的值】

【如何最大限度增加系统内存】举例操作如下：

减小kdump预留内存（kdump是在系统崩溃、死锁或者死机的时候用来转储内存运行参数的一个工具和服务，在系统崩溃时，可进入capture当前运行信息的内核，提取其中的dump core文件，主要功能类似于windows dmp文件，用于分析系统崩溃原因，如无特殊需求不建议人为调整，可能导致kdump无法启动，系统崩溃无法准确确认原因）
调整方法如下：
vim /boot/grub2/grub.cfg

将 kdump 预留内存改为 0（即不为kdump预留内存。注：关闭kdump服务，取消其开机自启，系统仍然会按照grub.cfg设置为其分配内存）

查看系统内存增大【已达到2000M左右】