Fix a rabbitmq issue (by quqi99)

问题
rabbitmq cluster的3个节点挂了. 3个节点是lxd容器:
11-lxd-8
69-lxd-2
9-lxd-9
初步sosreport分析
11-lxd-8上看到system_limit错误

=ERROR REPORT==== 17-Apr-2020::13:19:44 ===
Too many processes
=ERROR REPORT==== 17-Apr-2020::13:19:44 ===
Ranch listener {acceptor,{0,0,0,0,0,0,0,0},5672} connection process start failure; rabbit_connection_sup:start_link/4 crashed with reason: error:system_limit

但是已经设置了LimitNOFILE

$ grep -r 'Limit' lib/systemd/system/rabbitmq-server.service
LimitNOFILE=65536

不过LimitNOFILE似乎是管file_descriptors的, 而不是erlang processes的.

{file_descriptors,     [{total_limit,65436},      {total_used,6415},      {sockets_limit,58890},      {sockets_used,6413}]},
16:28:22  {processes,[{limit,1048576},{used,118304}]},

上面的输出显示似乎用了118304个erlang processes还未超出limit. 不过, 这可能是重启机器之后抓的sosreport. 并且limit已经很大, 单纯增加limit似乎也并不是正道. 所以继续寻找线索.

在69-lxd-2里也看到了’Error while waiting for Mnesia tables’这种错误, 似乎是Mnesia数据库未同步.

var/log/rabbitmq/[email protected]
=INFO REPORT==== 17-Apr-2020::13:27:26 ===
Waiting for Mnesia tables for 30000 ms, 9 retries left
=WARNING REPORT==== 17-Apr-2020::13:27:56 ===
Error while waiting for Mnesia tables: {timeout_waiting_for_tables,
[rabbit_user,rabbit_user_permission,
rabbit_vhost,rabbit_durable_route,
rabbit_durable_exchange,
rabbit_runtime_parameters,
rabbit_durable_queue]}

3个units上用’netstat -s’看到大量的reset tcp

sos_commands/networking/netstat_-s |head -n2
7154216 connection resets received
34025359 resets sent

深入分析

9-lxd-9上 通过下列命令看到各个openstack组件上都有到9-lxd-9的rabbitmq tcp连接, 一个组件就有约四五百个连接, 是不是多了一点? 其他两个units没这么多.

cat sos_commands/networking/netstat_-W_-neopa| awk '/:5672/ { print $5 }' | awk -F: '{ a[$1]++ }; END { for (i in a) print i, a[i] }' |sort -n -k 2 -r |more |head -n 80

但一个组件就有四五百个连接, 每个组件都这么多, 不可能每个组件都有问题吧. 除了大量tcp连接可以造成容器cpu升高, host机器的cpu升高也可以造成容器cpu升高的吧. 所以接着检查host机器的cpu占用率:

$ cat sos_commands/process/ps_auxwww |head -n 1
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
$ cat sos_commands/process/ps_auxwww |head -n1 && cat sos_commands/process/ps_auxwww |sort -n -k3 -r | head -n 3
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
nova 1936435 130 0.0 347704 126140 ? Rs 11:40 0:01 /usr/bin/python2 /usr/bin/nova-api-metadata --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api-metadata.log
libvirt+ 1809025 100 0.0 51373088 236744 ? Sl Mar09 56456:32 qemu-system-x86_64 -enable-kvm -name guest=instance-000099e0,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-26-instance-000099e0/master-key.aes -machine pc-i440fx-

ok, 虚机占用cpu就是100%. 看样子是控制服务(rabbitmq)与计算服务(nova-compute)安装到同一台物理机了, 虚机占用的cpu或者内存大页什么的直接导致rabbitmq cluster挂掉.
注:
ps命令中第三列相加的cpu大于100%也不一定就意味着cpu一定高, 因为可以这些进程全跑在一个cpu核的, 它可能计算的是一个核的, 要想准确还得使用mpstat来查看

解决办法

调整架构是不可能了, 可以暂时使用isolcpu隔离一些cpu单独通过taskset给rabbitmq使用

mpstat -P ALL 能看到所有cpu核的负载情况
cat /proc/cpuinfo| grep "cpu cores"| uniq
grub中添加isolcpus=1,3来隔离1和3的cpu待用, 然后运行update-grub后重启, 验证:
1, cat /proc/cmdline |grep isolcpu
2, ps -To 'pid,lwp,psr,cmd' -p 310597
3, ps -eo pid,cmd,psr |awk '{if($3=3) print $0}'
taskset -p0x8 绑定到cpu3
taskset -c 1 /etc/init.d/mysql start
systemd manages the affinity for you. See "man systemd.exec" and CPUAffinity= option.