numa分布奇葩引发的性能问题

2023-01-17

字数统计: 1.5k字 | 阅读时长≈ 6分

某些特定机器会有numa分布奇怪的问题，首次遇到，记录一波

写在前面

松鼠哥的ceph专业课程上线啦！
面向新手同学，从0实战，全面入门ceph安装部署与运维，有需要的同学赶紧扫码订购吧：

咳咳，开始之前，照例还是要打一波招聘广告，我们这边是天翼云科技的媒体存储组，目前我们仍在招聘存储研发、存储运维及相关组件开发的人才，有意向换工作的老铁可以试试，简历发一发，我们这边还是很不错的，千万不要错过

本篇的问题比较奇特，不容易发现，查了大半天，有一定的参考价值

问题排查

我们有一个准生产集群，进行性能测试的时候，cosbench显示测试性能只有我们预期的三分之一。即使性能相对较差也不能差到这样，因而要重点排查一下

基本现象就是写入4M的对象，带宽大概是21GiB/s，没什么问题，跟预期差不多，但是16K的测试显示性能差，处理单个写入延迟达到了600ms，这是一个非常糟糕的值，这就是说网络应该是没有问题的，小块处理慢，那么接下来就要进行定位了

打开rgw日志20/20，看下处理流程

2022-09-20 10:24:39.759 7f9a21ce9700 20 CONTENT_LENGTH=16000
2022-09-20 10:24:39.759 7f9a21ce9700 20 CONTENT_TYPE=application/octet-stream
....
2022-09-20 10:24:39.772 7f9a21ce9700 10 cache get: name=zone1.rgw.log++pubsub.user.test-pool1.bucket.cosbench-test-pool11/40419
d64-3ce0-4032-9094-da8bc366fd3e.84617.1 : type miss (requested=0x6, cached=0x0)
2022-09-20 10:24:40.399 7f9a21ce9700 10 cache put: name=zone1.rgw.log++pubsub.user.test-pool1.bucket.cosbench-test-pool11/40419
d64-3ce0-4032-9094-da8bc366fd3e.84617.1 info.flags=0x0
2022-09-20 10:24:40.399 7f9a21ce9700 10 moving zone1.rgw.log++pubsub.user.test-pool1.bucket.cosbench-test-pool11/40419d64-3ce0-
4032-9094-da8bc366fd3e.84617.1 to cache LRU end
2022-09-20 10:24:40.399 7f9a21ce9700  2 req 1083190 0.640s s3:put_obj completing
2022-09-20 10:24:40.400 7f9a21ce9700  2 req 1083190 0.641s s3:put_obj op status=0
2022-09-20 10:24:40.400 7f9a21ce9700  2 req 1083190 0.641s s3:put_obj http status=200
2022-09-20 10:24:40.400 7f9a21ce9700  1 ====== req done req=0x7f9a21ce2970 op status=0 http_status=200 latency=0.641s ======

可以看到，这个op处理时间是641ms，而在cache get到cache put之间花费了627ms！

这个操作看起来，是访问了元数据池，可是我们的元数据pool用的是ssd，按理说不该这么慢。

看了一眼，bucket的shard是正常的
看了一眼，网卡没有丢包的情况
看了一眼，iostat显示磁盘读写延迟没有问题
看了一眼，集群状态没有long heartbeat之类的告警
看了一眼，优化配置都跑上的了，集群配置也没有问题

那就奇了怪了。常见的排查手段都用了，没发现什么问题，关键它不报错，没有入手的点。em……

还是重点再看看rgw，rgw配置看了下是没有问题的，但是跑测试的时候，rgw的cpu使用率一直不超过200%，这个值有点小了。正常来说应该是400%以上的。

看了一眼，rgw的service文件有问题

[Unit]
Description=Ceph rados gateway
After=network-online.target local-fs.target time-sync.target
Wants=network-online.target local-fs.target time-sync.target
PartOf=ceph-radosgw.target

[Service]
LimitNOFILE=1048576
LimitNPROC=1048576
EnvironmentFile=-/etc/sysconfig/ceph
Environment=CLUSTER=ceph
ExecStart=/usr/bin/radosgw -f --cluster ${CLUSTER} --name client.%i --setuser ceph --setgroup ceph
...
CPUAffinity=0 1 2 

[Install]
WantedBy=ceph-radosgw.target

cpu只给了3个？难怪了，まさか。。。

[twj@fgw-001 ~]$ lscpu
Architecture:          x86_64
....
NUMA node0 CPU(s):     0-2,5,6,10-12,15,16,40-42,45,46,50-52,55,56
NUMA node1 CPU(s):     3,4,7-9,13,14,17-19,43,44,47-49,53,54,57-59
NUMA node2 CPU(s):     20-22,25,26,30-32,35,36,60-62,65,66,70-72,75,76
NUMA node3 CPU(s):     23,24,27-29,33,34,37-39,63,64,67-69,73,74,77-79

不得不说，第一次见到这种奇葩的numa分布。。。我们的rgw是用脚本做的cpu绑定，但是遇到这种奇怪的分布时，脚本处理不了，导致其分配的cpu过少！

那就是了，改一下绑定！重新跑，问题解决…..了吗？没有=.=

性能还是没有提升

关键点还是在元数据池的osd，读写元数据池还是很慢！那是不是元数据池的osd所在机器的cpu也是这种奇葩？

果…果不其然，真的是，一样的搞笑！

默认情况下，osd我们是不绑定cpu的，但是，正是因为没有绑定，导致osd进程跑到了各种不同的node上，导致性能的低下！关于numa架构访问不同node可能存在的问题及优化，我博客早期文章中有讲到，感兴趣的朋友可以去找找

看下影响

[twj@mon-004 ~]$ numastat
                           node0           node1           node2           node3
numa_hit                43852725        29810671        63563728        47177819
numa_miss                      0               0               0               0
numa_foreign                   0               0               0               0
interleave_hit             56487           56267           56486           56274
local_node              31335480        29733004        63490590        35078430
other_node              12517245           77667           73138        12099389

なるほど，node0和node3的other_node居然占到了30%，这个问题很大！正常的话应该像node1这种，极少的other_node

那么，就改一波

#!/bin/bash
osds=`/usr/bin/df -h|/usr/bin/grep 'ceph-'|awk -F '-' '{print $NF}'`
node0=`/usr/bin/numactl -H|/usr/bin/grep 'node 0 cpus'|/usr/bin/awk -F ':' '{print $NF}'|/usr/bin/sed 's/^.//'`

for aosd in $osds;
do
    /usr/bin/cp /usr/lib/systemd/system/ceph-osd@.service /etc/systemd/system/ceph-osd@${aosd}.service
    /usr/bin/sed -i "22a\\CPUAffinity=${node0}" /etc/systemd/system/ceph-osd@${aosd}.service
done

systemctl daemon-reload之后重启一波osd，重新测试，哇，性能超棒！

后记

numa架构访问不同node带来的性能问题是第一次遇到，此前是为了调优，没想到奇葩的numa cpu分布会产生较严重的性能问题，嗯，学到了，实际上，不仅仅对osd，对任何进程也是一样，如果进程访问了不属于自己的node的内存，都会有明显的性能问题。

希望对大家有所帮助

本文作者： 奋斗的松鼠
本文链接： http://www.strugglesquirrel.com/2023/01/17/numa分布奇葩引发的性能问题/
版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！