写在前面
喜欢ceph的话欢迎关注奋斗的cepher微信公众号阅读更多好文！
本篇的问题比较奇特，不容易发现，查了大半天，有一定的参考价值
问题排查
我们有一个准生产集群，进行性能测试的时候，cosbench显示测试性能只有我们预期的三分之一。即使性能相对较差也不能差到这样，因而要重点排查一下
基本现象就是写入4M的对象，带宽大概是21GiB/s，没什么问题，跟预期差不多，但是16K的测试显示性能差，处理单个写入延迟达到了600ms，这是一个非常糟糕的值，这就是说网络应该是没有问题的，小块处理慢，那么接下来就要进行定位了
打开rgw日志20/20，看下处理流程
bash
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文件有问题
bash
[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.targetcpu只给了3个？难怪了，まさか。。。
bash
[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可能存在的问题及优化，我博客早期文章中有讲到，感兴趣的朋友可以去找找
看下影响
bash
[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
那么，就改一波
bash
#!/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
donesystemctl daemon-reload之后重启一波osd，重新测试，哇，性能超棒！
后记
numa架构访问不同node带来的性能问题是第一次遇到，此前是为了调优，没想到奇葩的numa cpu分布会产生较严重的性能问题，嗯，学到了，实际上，不仅仅对osd，对任何进程也是一样，如果进程访问了不属于自己的node的内存，都会有明显的性能问题。
希望对大家有所帮助
喜欢ceph的话欢迎关注奋斗的cepher微信公众号阅读更多好文！