linux系统出现“out of memory”错误的根本解决方法包括：1.查明原因，使用top命令查看内存占用高的进程，或用pmap -x
先说个实在的，OOM killer是linux内核的最后一道防线。它会选择性地杀死一些进程，释放内存，保证系统核心功能还能运行。但这肯定不是我们想要的，程序无故被杀，数据丢失是小，系统崩溃是大。所以，得从根本上解决问题。
解决方案
-
查明原因：谁在疯狂吃内存？
最直接的办法，用top命令。看看哪个进程的%MEM占用率高得离谱。如果是你写的程序，那赶紧回去debug吧。如果是一些系统服务，那就要具体问题具体分析了。
再高级一点，可以用pmap -x
查看进程的内存映射情况，看看哪些内存区域占用最多。pid是进程ID，top命令里能找到。 -
增加Swap空间：应急措施
Swap空间相当于硬盘上的虚拟内存。当物理内存不够用时，系统会把一部分不常用的内存数据放到Swap空间里。这能缓解燃眉之急，但速度肯定比物理内存慢很多，所以只能算是应急措施。
怎么增加Swap空间？简单说几步：
- 创建一个文件作为Swap空间：sudo fallocate -l 2G /swapfile (这里创建了一个2GB的Swap文件)
- 设置正确的权限：sudo chmod 600 /swapfile
- 格式化为Swap文件系统：sudo mkswap /swapfile
- 启用Swap空间：sudo swapon /swapfile
- 添加到/etc/fstab，让系统启动时自动启用：echo ‘/swapfile swap swap defaults 0 0’ | sudo tee -a /etc/fstab
别忘了，Swap空间不是万能的。频繁的Swap操作（thrashing）会导致系统性能急剧下降。
-
优化程序：釜底抽薪
如果内存占用是程序造成的，那就要优化代码了。常见的优化手段包括：
- 减少内存泄漏： 检查代码中是否有内存分配后没有释放的情况。Valgrind是个好工具。
- 使用更高效的数据结构： 比如，用哈希表代替线性查找，用压缩数据结构减少内存占用。
- 优化算法： 避免不必要的内存复制，减少临时变量的创建。
- 使用内存池： 减少频繁的内存分配和释放操作。
-
限制进程内存使用：治标之策
可以使用ulimit命令限制进程的内存使用量。例如，ulimit -v 2000000限制进程的虚拟内存使用量为2GB。但这只是治标之策，不能解决根本问题。
-
升级硬件：终极方案
如果以上方法都无效，那就只能升级硬件了。加内存条是最直接有效的办法。
如何监控Linux系统内存使用情况？
监控内存使用情况是预防OOM错误的有效手段。除了top命令，还可以使用free -m命令查看内存使用情况。free -m会以MB为单位显示内存使用情况，包括总内存、已用内存、空闲内存、Swap空间等。
更高级的监控工具包括：
- vmstat： 报告虚拟内存统计信息。
- sar： 收集、报告和保存系统活动信息，包括内存使用情况。
- Grafana + Prometheus： 搭建一套完整的监控系统，可以实时监控内存使用情况，并设置告警。
OOM Killer是如何工作的？如何避免被它杀死？
OOM Killer会根据一个叫做oom_score的参数来选择要杀死的进程。oom_score越高，被杀死的可能性越大。这个分数会考虑进程的内存占用、运行时间、用户权限等因素。
如何避免被OOM Killer杀死？
- 降低oom_score： 可以通过调整/proc/
/oom_adj或/proc/ /oom_score_adj文件来降低进程的oom_score。例如，echo -17 > /proc/ /oom_score_adj可以将进程的oom_score降到最低，使其几乎不可能被OOM Killer杀死。但是，这样做有风险，如果该进程真的导致了OOM，可能会导致系统崩溃。 - 合理分配内存： 尽量避免程序占用过多的内存。
- 使用cgroups： cgroups可以限制进程的资源使用量，包括内存。
如何分析OOM日志？
OOM Killer杀死进程后，会在系统日志中留下记录。这些日志通常包含被杀死的进程ID、进程名、内存占用情况等信息。分析这些日志可以帮助我们找到导致OOM的原因。
日志通常位于/var/log/syslog或/var/log/kern.log文件中。可以使用grep命令过滤出OOM相关的日志。例如，grep “Out of memory” /var/log/syslog。
分析OOM日志需要一定的经验，但只要耐心分析，就能找到问题的根源。
