记一次-K3s-MySQL-启动-OOM-排查

48次阅读

共计 5001 个字符，预计需要花费 13 分钟才能阅读完成。

以前用 Docker Compose 做开发环境，MySQL 也在 Docker 里运行，一切使用正常。后来开发环境迁移到 K3s（轻量级的 K8s），但是 MySQL 一启动就被 OOM Killer 干掉，所以一直没迁移 MySQL。

重现

使用 Kubectl 直接运行一个 MySQL 即可重现：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        imagePullPolicy: IfNotPresent
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: root
        resources:
          limits:
            memory: 4G
            cpu: 500m

dmesg 可以看 mysqld 分配超过了 3.7G 内存然后被杀掉：

[839.399262] Tasks state (memory values in pages):
[839.399263] [pid]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
...
[839.399278] [34888]     0 34888  4208240   974177  7962624        0          -998 mysqld
[839.399280] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=...,mems_allowed=0,oom_memcg=/kubepods/pod..,task_memcg=/kubepods/pod../56..,task=mysqld,pid=34888,uid=0
[839.399294] Memory cgroup out of memory: Killed process 34888 (mysqld) total-vm:16832960kB, anon-rss:3895388kB, file-rss:1320kB, shmem-rss:0kB
[839.496988] oom_reaper: reaped process 34888 (mysqld), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

排查

优化 MySQL 配置

第一反应是 MySQL 配置有问题，于是修改配置减少各种 buffer 的大小:

[mysqld]
innodb_buffer_pool_size = 32M
innodb_buffer_pool_instances=1
innodb_log_file_size = 64M
innodb_log_buffer_size = 8M
key_buffer_size = 16k
myisam_sort_buffer_size = 16k
max_connections = 50
open_files_limit = 4096
max_allowed_packet = 1M
table_open_cache = 16
sort_buffer_size = 512k
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
thread_cache_size = 64
query_cache_size = 0
tmp_table_size = 12M
thread_stack=256K

然而问题依旧，改了不少配置都没有效果，看来需要跟踪或调试。

用 bpftrace 定位内存分配

这里没有使用 strace 主要是因为启动就被杀掉，需要修改镜像启动命令然后在容器内安装和执行 strace，而 bpftrace 可以系统全局跟踪，在容器外就可以完成跟踪，更加方便。

内存分配主要通过 skb 和 mmap 系统调用，用 bpftrace 跟踪这两个系统调用：

#!/usr/bin/bpftrace

tracepoint:syscalls:sys_enter_mmap / comm == "mysqld" /
{printf("%d %s addr=%ld len=%ld flags=%ld\n", pid, probe, args->addr, args->len, args->flags);
    /* printf("%s\n", ustack(perf, 10)); */
}

tracepoint:syscalls:sys_enter_brk / comm == "mysqld" /
{printf("%d %s brk %d\n", pid, probe, args->brk);
}
sudo ./mysql-oom.bt
Attaching 2 probes...
57950 tracepoint:syscalls:sys_enter_brk brk 0
57950 tracepoint:syscalls:sys_enter_mmap addr=0 len=8740 flags=2
...
...
57950 tracepoint:syscalls:sys_enter_brk brk 1699086336
57950 tracepoint:syscalls:sys_enter_mmap addr=0 len=17179869184 flags=34

可以看到最后用 mmap 一次分配了 16G 内存，然后就被杀了。

尝试获取调用堆栈（ustack），但是都拿不到有用的信息，可能 mysql 没有编译时没有开启 frame pointer：

97694 tracepoint:syscalls:sys_enter_mmap addr=0 len=12288 flags=34

    7f84c662730a 0x7f84c662730a ([unknown])

97694 tracepoint:syscalls:sys_enter_mmap addr=0 len=17179869184 flags=34

    7f84c4c4064a 0x7f84c4c4064a ([unknown])

拿不到堆栈，再尝试跟踪所有系统系统调用：

#!/usr/bin/bpftrace

tracepoint:syscalls:sys_enter_* /  comm == "mysqld" /
{printf("%d %s\n", pid, probe);
}
...

输出：

Attaching 331 probes...
...
115490 tracepoint:syscalls:sys_enter_close
115490 tracepoint:syscalls:sys_enter_brk
115490 tracepoint:syscalls:sys_enter_newstat
115490 tracepoint:syscalls:sys_enter_getrlimit
115490 tracepoint:syscalls:sys_enter_mmap addr=0 len=17179869184 flags=34

可以看到在最后一次 mmap 前调用了 getrlimit，猜测是 mysql 会根据系统资源限制来分配内存。

MySQL 源码分析

MySQL 源码中直接调用 getrlimit 的地方不多，排除了 ndb、innodb_memcached、libevent 之后，只有一处直接调用：

static uint set_max_open_files(uint max_file_limit)
{
  struct rlimit rlimit;
  uint old_cur;
  DBUG_ENTER("set_max_open_files");
  DBUG_PRINT("enter",("files: %u", max_file_limit));

  if (!getrlimit(RLIMIT_NOFILE,&rlimit))
  {old_cur= (uint) rlimit.rlim_cur;
    DBUG_PRINT("info", ("rlim_cur: %u  rlim_max: %u",
                        (uint) rlimit.rlim_cur,
                        (uint) rlimit.rlim_max));
    if (rlimit.rlim_cur == (rlim_t) RLIM_INFINITY)
      rlimit.rlim_cur = max_file_limit;
    if (rlimit.rlim_cur >= max_file_limit)
      DBUG_RETURN(rlimit.rlim_cur);                /* purecov: inspected */
    rlimit.rlim_cur= rlimit.rlim_max= max_file_limit;
    if (setrlimit(RLIMIT_NOFILE, &rlimit))
      max_file_limit= old_cur;                        /* Use original value */
    else
    {
      rlimit.rlim_cur= 0;                        /* Safety if next call fails */
      (void) getrlimit(RLIMIT_NOFILE,&rlimit);
      DBUG_PRINT("info", ("rlim_cur: %u", (uint) rlimit.rlim_cur));
      if (rlimit.rlim_cur)                        /* If call didn't fail */
        max_file_limit= (uint) rlimit.rlim_cur;
    }
  }
  DBUG_PRINT("exit",("max_file_limit: %u", max_file_limit));
  DBUG_RETURN(max_file_limit);

其中逻辑是：如果系统的文件打开限制是 RLIM_INFINITY 或者比要设置的 max_file_limit 大，都返回系统的限制。

这个函数也只被直接调用一次：

uint my_set_max_open_files(uint files)
{
  struct st_my_file_info *tmp;
  DBUG_ENTER("my_set_max_open_files");
  DBUG_PRINT("enter",("files: %u  my_file_limit: %u", files, my_file_limit));

  files+= MY_FILE_MIN;
  files= set_max_open_files(MY_MIN(files, OS_FILE_LIMIT)); // 获取最大打开文件数
  if (files <= MY_NFILE)
    DBUG_RETURN(files);

  // 分配内存
  if (!(tmp= (struct st_my_file_info*) my_malloc(key_memory_my_file_info,
                                                 sizeof(*tmp) * files,
                                                 MYF(MY_WME))))
    DBUG_RETURN(MY_NFILE);

  // 初始化
  /* Copy any initialized files */
  memcpy((char*) tmp, (char*) my_file_info,
         sizeof(*tmp) * MY_MIN(my_file_limit, files));
  memset((tmp + my_file_limit), 0,
        MY_MAX((int) (files - my_file_limit), 0) * sizeof(*tmp));
  my_free_open_file_info();                        /* Free if already allocated */
  my_file_info= tmp;
  my_file_limit= files;
  DBUG_PRINT("exit",("files: %u", files));
  DBUG_RETURN(files);
}

原来 MySQL 会根据最大可打开文件数，提前为每个文件分配和初始化内存，在这个时候就可能分配过多内存，导致 OOM。

解决

启动前设置 ulimit

因为 K8s 目前不支持设置 ulimit，不少 Helm Chart 都在启动前设置 ulimit。

command: ["sh","-c", "ulimit -n 4096 && exec /usr/local/bin/docker-entrypoint.sh mysqld"]

修改 K3s 设置

K3s 通过 systemd 启动，可以修改 k3s.service，限制 K3s 打开文件数，这个限制会传给 containerd：

LimitNOFILE=1048576

正文完
kubernetes mysql
发表至： linux
2019-09-30
 0
关于linux:Linux系统中如何使用-nmcli-命令配置网络连接
如何重复执行一条命令直至运行成功
Linux环境下下安装hbase单机版
Linux下如何查看硬件信息