由于RHEL/CentOS7在2024年6月30日将EOL(End Of Life，结束生命周期)，最近陆续在将生产上的服务的OS升级迁移到RHEL/AlmaLinux8，但是陆续发现原本用相同的资源的服务器经常出现SWAP不足、杀毒软件ClamAV进程因内存而被Kill等告警。
今天迁移一个测试环境的Web应用，参考原来服务申请了一个1C1G(1024M)的服务器，安装AlmaLinux8.7后，由于同步大量数据等待发现实际内存竟然只有790M。
# more /proc/meminfo |grep MemTotal
MemTotal: 796008 kB
# free -m
total used free shared buff/cache available
Mem: 777 306 231 6 239 339
Swap: 2047 0 2047
一度怀疑是云提供商提供的资源是虚的1G，但是对比旧服务器、登录云提供商官网确认。都没有问题，开始怀疑是AlmaLinux 8系统的问题；将近期部署的一些服务器都看了下，内存资源都未达到实际物理内存的值。
1）查看硬件内存资源，确实是1024M。
# dmidecode -t Memory|more
Handle 0x0085, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: RAM socket #0
Bank Connections: None
Current Speed: Unknown
Type: EDO DIMM
Installed Size: 1024 MB (Single-bank Connection)
Enabled Size: 1024 MB (Single-bank Connection)
Error Status: OK
2）1G/2G/4G被占用情况
1G内存，实际仅800M-
# more /proc/meminfo |grep MemTotal
MemTotal: 796008 kB
2G内存，实际1800M-
# more /proc/meminfo |grep MemTotal
MemTotal: 1828236 kB
4G内存，实际3800M-
more /proc/meminfo |grep MemTotal
MemTotal: 3793476 kB
1.调查分析
由于系统显示少了200M的内存，怀疑系统启动前的一些机制占用的该部分内存；
1）查看启动过程内核中内存相关加载信息
# dmesg | grep -i memory
[ 0.000000] ACPI: Reserving FACP table memory at [mem 0x3fefee73-0x3fefef66]
[ 0.000000] ACPI: Reserving DSDT table memory at [mem 0x3feeaa08-0x3fefee72]
[ 0.000000] ACPI: Reserving FACS table memory at [mem 0x3fefffc0-0x3fefffff]
[ 0.000000] ACPI: Reserving FACS table memory at [mem 0x3fefffc0-0x3fefffff]
[ 0.000000] ACPI: Reserving BOOT table memory at [mem 0x3feea9e0-0x3feeaa07]
[ 0.000000] ACPI: Reserving APIC table memory at [mem 0x3feea29e-0x3feea9df]
[ 0.000000] ACPI: Reserving MCFG table memory at [mem 0x3feea262-0x3feea29d]
[ 0.000000] ACPI: Reserving SRAT table memory at [mem 0x3fee9757-0x3fee9ffe]
[ 0.000000] ACPI: Reserving HPET table memory at [mem 0x3fee971f-0x3fee9756]
[ 0.000000] ACPI: Reserving WAET table memory at [mem 0x3fee96f7-0x3fee971e]
[ 0.000000] Reserving 160MB of memory at 672MB for crashkernel (System RAM: 1023MB)
为crashkernel预留160MB内存(系统RAM: 1023MB)
...
原来是为crashkernel保留了160MB的内存，属于kdump服务。kdump服务是在系统奔溃时生成内核转储文件。
2）检查crashkernel配置及kdump服务
查看kdump服务状态。
# systemctl status kdump.service
查看crashkernel配置
# cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
3）查看官方文档关于kdump服务的配置。
在系统引导过程中为 kdump 保留内存。内存大小在系统 Grand Unified Bootloader (GRUB)配置中设置。内存大小取决于配置文件中指定的 crashkernel= 选项的值以及系统物理内存的大小。
crashkernel= 选项可以通过多种方式定义。您可以指定 crashkernel= 值或配置 auto 选项。crashkernel=auto 参数根据系统中的物理内存总量自动保留内存。配置后，内核将自动为捕获内核保留适当数量的所需内存。这有助于防止内存不足(OOM)错误。
注意：
kdump 的自动内存分配因系统硬件架构和可用内存大小而异。
例如，在 AMD64 和 Intel 64 上，crashkernel=auto 参数仅在可用内存超过 1GB 时才起作用。64 位 ARM 架构和 IBM Power Systems 需要超过 2GB 的可用内存。
如果系统自动分配低于最小内存阈值，您可以手动配置保留内存量。
2.解决问题
1)）停止kdump服务
# systemctl stop kdump
# systemctl disable kdump
2）修改grub文件
将crashkernel=auto改为crashkernel=0
# cp -p /etc/default/grub /etc/default/grub.org
# vi /etc/default/grub
变更以下内容：
变更前：GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap"
变更后：GRUB_CMDLINE_LINUX="crashkernel=0 resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap"
3）更新grub配置文件、重启系统
# grub2-mkconfig -o /boot/grub2/grub.cfg
# reboot
4）确认内存增加了160MB
# more /proc/meminfo |grep MemTotal
MemTotal: 959852 kB
虽然内存空间提升160M，但是离1024M还差一些，后续再分析。
网友评论