be crash引起的IO高的问题

最近，doris集群不定时出现be节点宕掉的情况，查看监控发现在宕掉的节点load很高，io write写很高。所以首先怀疑有大的sql执行。经过一番排查，始终找不出是什么sql会导致这么高的io。于是又怀疑是不是broker上的同步任务导致的，于是我在机器上写了个监控程序，看挂的时候到底是那个进程导致了这么高的io.

经过一番操作，过几天后又出现be挂掉的情况，于是登录上发现有个abrt-hook-ccpp的进程io很高，这时才找到了真正的问题所在。

abrt-hook-ccpp 进程

linux 上的c/c++程序，当出现一些内存越界，非法访问的问题时会导致进程直接crash，现象就是直接挂掉了，这种问题很难排查。好在Linux内核会监控这个crash的情况，会捕获到进程崩溃信息，然后将进程的coredump信息写入到文件中。

怎么生成coredump信息

• 开启生成coredump信息

• 输入命令ulimit -a

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

  core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 513562 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 10240 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 513562 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited

  其中的 -c: core file size 如果设置为0的话，当程序崩溃的时候就不会产生core文件。

  1 2	ulimit -c 1024 #设置CoreDump文件大小为1024k ulimit -c unlimited #不限制CoreDump文件大小

  注意：通常be的coredump很大，不要设置成 unlimited

• 指定生成CoreDump文件的路径

默认情况下，coreDump生成的文件名为core，默认在进程当前目前。

/proc/sys/kernel/core_pattern 可以设置格式化的 core文件保存位置或文件名，默认的是 |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e
可以使用命令修改：

1

sysctl kernel.core_pattern="/tmp/core_%t_%e_%p"

关于abrt-hook-ccpp

上面的core_pattern默认值是

1

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

这种格式的意思是：如果core_pattern 中第一个字符是 Linux管道符 |, 那么Linux 内核在捕获进程崩溃信息的时候，就会以root权限执行管道符后门的程序或者脚本，将进程崩溃信息传递给这个程序或者脚本。

abrt-hook-ccpp 是 abrt进程的一个钩子程序。abrt-hook-ccpp会收集coredump信息，把这些信息写入 /var/spool/abrt 这个目录，供abrt服务使用。

Abrt是linux一个自动化 Bug 检测和报告工具。这是红帽领导开发的一个项目

ABRT is a set of tools to help users detect and report application crashes. Its main purpose is to ease the process of reporting an issue and finding a solution.

参考：https://abrt.readthedocs.io/en/latest/