OOM故障处理流程
阅读原文时间:2023年07月08日阅读:2

Linux 内核有个机制叫OOM killer(Out Of Memory killer),该机制会监控那些占用内存过大,尤其是瞬间占用内存很快的进程,为防止内存耗尽而自动把该进程杀掉。

进程被Linux杀掉几个可能的原因:

  • 内存泄露;
  • 你的进程所需要的内存资源太大,系统无法满足;
  • 也不一定全是你的问题,也有可能是同一主机的其他进程占用资源过多。

数据库OOM可能的故障现象:

  • 数据库切换、服务中断 ……
  • 通过数据库的log确认有进程被kill 9,然后通过同时间的系统日志确认

vm.overcommit_memory 接受三种值:

  • 0 – 这是缺省值,它允许overcommit,但过于明目张胆的overcommit会被拒绝,比如malloc一次性申请的内存大小就超过了系统总内存。
  • 1 – 允许overcommit,对内存申请来者不拒。
  • 2 – 禁止overcommit。

OOM参数影响系统的可分配内存。举例如下:操作系统内存 4G、swap 2G。以 kingbase 为例,shared_buffers 最大值:

  • vm.overcommit_memory = 0 , shared_buffers 最大值为 6G
  • vm.overcommit_memory = 1 , shared_buffers 最大值可以超过 6G,没有限制
  • vm.overcommit_memory = 2 , 根据 (物理内存 + swap)* overcommit_ratio 确定可分配的内存,相当于可用内存不超过3G(所有进程可用的总内存,包括操作系统占用)。 默认 overcommit_ratio 50%。

如果vm.overcommit_memory = 2,正常不会发生OOM,只是在执行时报错。类似如下:

ERROR: out of memory
DETAIL: Failed on request of size 16384 in memory context "ExecutorState".

1、查看操作系统日志

grep "Out of memory" /var/log/messages*
Out of memory: Kill process (checkpoint) score 9 or sacrifice child
checkpoint invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

有的系统Log里会输出kill时的全部进程和每个进程的内存使用情况,用于确认当时的情况。

dmesg -T
[Wed May 15 14:03:08 2019] Out of memory: Kill process 83446 (machine) score 250 or sacrifice child
[Wed May 15 14:03:08 2019] Killed process 83446 (machine) total-vm:1920560kB, anon-rss:1177488kB, file-rss:1600kB

2、确认问题时间点的内存使用情况

Linux 系统默认每10分钟会收集系统状态,数据保存在/var/log/sa 目录。用户可以找到对应时间点的文件,运行sar命令,如:sar -r -f sa04 ,取得当时的系统状态信息。类似结果显示如下:

从上图可以看出,10:40 左右,系统可用内存不足,接着引发oom,之后可用内存恢复。

3、操作系统内存排查

查看系统内存使用情况:查看系统内存,关注可用内存情况:

free –g

cat /proc/meminfo

查看进程占用内存情况:

ps aux | sort -nrk5 | more 查看TOP VSZ ,表示请求的共享内存段的大小。这个并不表示实际分配的内存段,如shared_buffer = 1024M,但实际启动时并没有真正分配1024M内存(除非使用大页)。

ps aux | sort –nrk6 | more  查看每个进程实际占用的物理内存大小

注:当前时间点内存占用并不能反应OOM时间点实际内存占用情况,只能查看哪些进程是可能的影响因素。

清除linux系统的cache

# echo 3 > /proc/sys/vm/drop_caches

4、排查OOM时间点的运行业务

  1. 如有可能,逐个停止、排查业务,确认最占用系统内存的业务。
  2. 如果所有业务都停止后,还未释放内存,那可能是操作系统占用,需要排查操作系统问题。如以上例子,停止所有业务应用后,操作系统还占用大量内存,需要排查操作系统问题。
  3. 查看问题时间点,是否有crontab , job 等定时任务,确认是否有长时间运行的任务。
  4. 查看数据库sys_log,确认是否有耗时的SQL、大量量临时IO的SQL。
  5. 如果是 R6 版本,可以分析问题时间点kwr , ksh 报告。

5、查看数据库内存配置参数

查看数据库内存配置参数,计算主机可承受的负荷。样例数据如下:

主机内存:                           256G

SWAP:                                   22G

shared_buffers:                 100G

max_connections:   4000

work_mem:                        100M

temp_buffers:          32M

wal_buffers:              64M

autovacuum_max_workers:   3

autovacuum_work_mem:        -1

maintenance_work_mem:      10G

current connections:        150

数据库占用内存计算公式:max_connections*work_mem + max_connections*temp_buffers +shared_buffers+wal_buffers+(autovacuum_max_workers * autovacuum_work_mem)+ maintenance_work_mem

数据库理论峰值 =4000 * 100M + 4000 * 32M + 100G + 64M + 10G = 620G

数据库当前值 = 150 * 100M + 150 * 32M + 100G + 64M + 10G = 130G

主机可承受连接数极值 = ( 250G - 100G - 10G ) / ( 100M + 32M ) = 1080

注意:这里的极限值其实是以每个连接占用132M 进行估算的,实际会话可能并不会占用这么多内存,且并不会有同时这么多并发排序操作。

手机扫一扫

移动阅读更方便

阿里云服务器
腾讯云服务器
七牛云服务器

你可能感兴趣的文章