在GCP e2-micro实例上运行DNF升级时避免内存耗尽(OOM)的方法及相关疑问

我完全理解你在e2-micro上跑DNF升级遇到内存耗尽、SSH会话被终止的糟心情况——毕竟1GB内存+1GB swap的配置确实相当紧凑，而DNF在处理升级时，会占用不少内存来缓存包元数据、解析依赖关系，很容易触发OOM killer。下面我来逐一解答你的问题，同时给出实用的解决办法：

一、Fedora Cloud Base能不能在2GB总内存（含swap）上正常管理？ #

完全可以，但需要做一些针对性的内存优化。e2-micro的1GB物理内存+1GB swap刚好处于临界值，默认配置下可能会出现资源紧张的情况，但只要调整好系统和DNF的参数，日常的包管理、系统运维都能顺利进行。

二、如何升级内核和包时避免内存耗尽？ #

这里有几个实用的技巧，你可以按顺序尝试：

• 临时关停非必需服务：升级前先关掉一些暂时用不上的后台服务，释放内存。比如可以先执行：

  sudo systemctl stop firewalld
  

  升级完成后再用sudo systemctl start firewalld恢复。你也可以用sudo systemctl list-units --type=service --state=running查看当前运行的服务，挑那些占用内存较多且非必需的临时关停。
• 调整DNF的内存友好配置：编辑/etc/dnf/dnf.conf，添加或修改以下参数：

  max_parallel_downloads=2  # 减少并行下载数，默认值可能更高，会占用更多内存
  keepcache=0               # 关闭包缓存，节省磁盘空间和内存占用
  metadata_expire=86400     # 缩短元数据过期时间，避免缓存过多旧元数据
  installonly_limit=2       # 只保留2个旧内核，减少磁盘和内存占用
  

  保存后退出，再执行升级会明显降低内存消耗。
• 使用DNF的内存优化参数：执行升级时加上这些参数，进一步减少内存压力：

  sudo dnf upgrade --setopt=install_weak_deps=False
  

  install_weak_deps=False会跳过那些非必需的依赖包，减少需要处理的包数量，从而降低内存占用。你也可以分两步操作：先下载所有包，再单独安装：

  sudo dnf upgrade --downloadonly
  sudo dnf upgrade
  

  这样分开处理，下载阶段和安装阶段的内存压力都会小很多。
• 临时启用zram交换：zram是基于内存的压缩交换空间，比普通磁盘swap更高效，能临时增加可用内存。执行以下命令启用：

  sudo modprobe zram
  sudo zramctl /dev/zram0 --size 512M --algorithm zstd
  sudo mkswap /dev/zram0
  sudo swapon /dev/zram0
  

  升级完成后，如果不需要可以用sudo swapoff /dev/zram0关掉。
• 分批升级：不要一次性升级所有包，先单独升级内核相关组件，重启后再升级剩余包：

  sudo dnf upgrade kernel
  sudo reboot
  sudo dnf upgrade
  

  每次处理的包数量更少，内存占用自然更低。

三、Fedora Cloud Base大版本升级时会不会遇到问题？ #

大版本升级（比如从36升级到后续版本）确实会比普通升级占用更多内存，因为要处理大量包的替换、依赖重新解析。但只要提前做好准备，也能顺利完成：

• 提前清理系统：先清理DNF缓存和无用包，释放资源：

  sudo dnf clean all
  sudo dnf autoremove
  

• 优化大版本升级的参数：使用dnf system-upgrade时，加上内存友好的参数：

  sudo dnf system-upgrade download --releasever=37 --setopt=max_parallel_downloads=1 --setopt=install_weak_deps=False
  

  减少并行任务、跳过弱依赖，能有效降低内存占用。
• 临时增加swap空间：如果上面的方法还不够，可以挂载一个临时的磁盘swap（比如创建一个1GB的临时文件作为swap），升级完成后再删除，进一步缓解内存压力。

备注：内容来源于stack exchange，提问作者jrefior