内存或者说可用内存是一个系统最终要的一个指标之一，特别是对于内存容量较小的机器（云上4GB的虚机等）来说，每1MB的内存都非常珍贵，当内存不足时可能造成系统使用swap，造成系统运行的速度和效率急剧下降，CPU冲高甚至OS卡死等。
当前我们服务在云上使用2U4G的VM，特别是在使用ARM的VM情况下经常出现内存不足的情况。
对于大家工作中熟悉的Windows系统来说，可用内存一般接近于实际的机器配置，例如当前笔者使用的PC配置为16GB DDR4内存，任务管理器中实际可用内存显示为15.8GB，如下图所示：
那么对于Linux来说是否也是这种情况呢？
笔者所在服务使用华为云现网的VM为例，同样的VM规格（c7.large.2/2U4G），安装不同系统情况下系统启动后使用free命令查到的可用内存不同，如下所示：
Euler 2.5系统：初始可用内存：3.6GB 
Huawei Cloud EulerOS 2.0 标准版系统：初始可用内存：3.2GB
Ubuntu 20.04系统：初始可用内存：3.7GB
此处就非常奇怪了，不同系统的初始可用内存差异非常大，对于Linux的不同发行版，理论上来说不应该有如此大的差距。此处经过一顿网上搜索均未能得到想要的答案，只能自己想办法分析一下。
此处笔者首先想到的思路是：是否不同机器的配置不一样，造成实际可用内存大小不同？
我们知道系统的启动日志可以使用dmesg命令查询，查询启动信息中是否含有内存相关信息，如下图所示不同系统的启动信息中识别到的可用内存是一样的：
此处没有差别是否虚拟化出来的硬件有所差别？
使用dmidecode命令可以查询到系统的硬件配置（类似Windows的配置管理器），具体命令 dmidecode -t memory，可以看到配置确实是4GB内存，没有任何差异：
那我们的内存去哪儿了呢？陷入一顿沉思，是否有可能被系统自身占用？
经过一顿定位，突然想到系统日志，让我们再反过来查看欧拉系统的启动日志，发现一个可以的关键字（Reserving），预留内存512MB，并且是一个叫做crashkernel的东西，并且512这个数字也非常接近两个系统的差值，很可疑：
我们有必要怀疑是否这个叫crashkernel的玩意占用了内存，又经过一顿搜索，发现kdump主要是redhat的产品，用来记录linux内核crash时的dump文件，定位内核crash问题，并且kdump可以分配crashkernel的内核，参考文章：lzz5235.github.io/2014/10/25/...
并且具体的配置位置位于：/etc/default/grub中，RUB_CMDLINE_LINUX中一个叫做crashkernel=512M的参数，是最新的Euler2.0系统默认配置。
使用VIM对该配置进行修改，修改为1M之后，并且使用 grub2-mkconfig -o /boot/grub2/grub.cfg 命令之后reboot机器，可用内存恢复正常：
至此问题解决，唯一的副作用是，kdump模块启动不了（有利有弊），不建议大家生产环境直接修改~
另外这个是redhat的软件，Ubuntu默认是不安装的，Ubuntu安装Kdump可以参考：www.ebpf.top/post/ubuntu...