Docker环境下MariaDB因OOM被周期性终止但存在大量可用交换内存的问题排查咨询

看起来你遇到了一个挺让人头疼的问题——明明宿主机有大把交换内存可用，swappiness也拉满到100了，Docker容器里的MariaDB还是被内核OOM killer周期性干掉，而且内核日志里也没显示它占用了特别夸张的内存。我来帮你梳理下可能的原因和进一步排查的方向：

可能的核心原因分析 #

1. Docker容器的内存/swap限制未配置正确 #

虽然宿主机有充足swap，但如果给MariaDB容器设置了--memory（物理内存限制）却没配套设置--memory-swap，那容器能使用的swap量是被严格限制的。默认情况下--memory-swap是--memory的两倍，比如你设了--memory=4G，那容器总共只能用4G物理内存+4Gswap=8G资源。一旦MariaDB在容器内的内存（含swap）占用接近这个上限，哪怕宿主机还有很多剩余swap，容器也用不上，最终触发OOM。

2. 内核因内存碎片化触发OOM，而非总内存不足 #

从你提供的内核日志能看到order=3，这表示内核需要分配8个连续的4K物理页（共32K），但此时宿主机内存碎片化严重，找不到足够的连续物理页——哪怕总内存和swap加起来很充足，内核也无法满足连续页的分配需求，于是启动OOM killer回收内存。这种情况下，swap再大也帮不上忙，因为swap里的内存是离散的，不能直接提供连续物理页。

3. MariaDB的内存配置或查询行为导致突发内存占用 #

内核日志可能没捕捉到MariaDB的内存峰值：比如处理大查询（无索引排序、大表关联）时，MariaDB会临时申请大量内存（sort buffer、join buffer等），瞬间拉高内存占用；或者内存参数配置不合理（比如innodb_buffer_pool_size过大，加上max_connections设置过高，导致并发时内存累计超支）。

4. 容器cgroup的swap权限限制 #

即使宿主机swappiness设为100，容器的cgroup配置可能还是限制了swap的使用。比如memory.memsw.limit_in_bytes被设为固定值，而非-1（无限制），这会导致容器无法充分利用宿主机的swap资源。

进一步排查与解决步骤 #

1. 核实Docker容器的内存/swap配置 #

• 执行以下命令查看容器的内存限制：

  docker inspect <your-mariadb-container-id> | grep -A 6 -B 2 "Memory"
  

  重点看Memory（物理内存上限）和MemorySwap（物理+swap总上限），如果MemorySwap不是-1，说明swap被限制。
• 重新启动容器时解除swap限制：
  • 用docker run启动：

    docker run --name mariadb -e MYSQL_ROOT_PASSWORD=xxx --memory=4G --memory-swap=-1 --sysctl vm.swappiness=100 mariadb:latest
    

  • 用docker-compose则在配置文件中添加：

    services:
      mariadb:
        image: mariadb:latest
        environment:
          MYSQL_ROOT_PASSWORD: xxx
        mem_limit: 4G  # 按需设置，不需要可以删除
        memswap_limit: -1
        sysctls:
          - vm.swappiness=100
    

2. 检查宿主机内存碎片化情况 #

• 查看内存碎片化状态：

  cat /proc/buddyinfo
  

  输出中zone列后的数字对应不同order的空闲页（order=0是单页，order=3是8个连续页），如果order≥3的数值接近0，说明碎片化严重。
• 查看内存压缩统计：

  cat /proc/vmstat | grep -E "compact|defrag"
  

  若compact_fail数值很高，说明内核压缩内存整理连续页的尝试多次失败。
• 临时开启更积极的内存压缩（谨慎操作）：

  echo 50 > /proc/sys/vm/compaction_proactiveness
  

3. 深入监控MariaDB的内存与查询行为 #

• 开启慢查询日志定位高内存消耗查询：
  在MariaDB配置文件（如/etc/mysql/my.cnf）中添加：

  slow_query_log = 1
  slow_query_log_file = /var/log/mysql/slow.log
  long_query_time = 2
  log_queries_not_using_indexes = 1
  

  重启后分析慢日志，找出那些可能触发内存突增的查询。
• 实时监控容器内MariaDB的内存：

  watch -n 1 'docker stats --no-stream <your-mariadb-container-id>'
  

  关注MEM USAGE / LIMIT和SWAP USAGE列，看是否有突发峰值。
• 查看MariaDB的内存参数与实际使用：
  进入容器后执行：

  SHOW VARIABLES LIKE '%buffer%';
  SHOW VARIABLES LIKE '%cache%';
  SHOW GLOBAL STATUS LIKE '%memory%';
  

  计算内存参数总和：innodb_buffer_pool_size + key_buffer_size + (sort_buffer_size * max_connections) + (join_buffer_size * max_connections)，确保不超过容器的内存上限。

4. 分析完整的内核OOM日志 #

• 查看完整的OOM触发记录：

  dmesg | grep -A 100 "oom-killer"
  

  重点看各进程的oom_score（得分越高越容易被kill），确认MariaDB是否是得分最高的进程；同时查看其他进程的内存占用，排除其他进程偷偷消耗内存的情况。

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