背景
为了快速地把存储系统的性能调到理论上限，结合最近调试记录，整理了下面的速查记录。 调试的时候，可以根据下面的顺序、先易后难地去调参。
版本
要求：release 版本；-O2编译；关闭CRC 和模块内部调试用的CRC
需要检查的版本包括：
vhost 版本： 检查方法：看日志
blockserver 版本 检查方法：./blockserver -v
data server 版本 检查方法： ./bin/dataserver -v
libucx 动态库版本 检查方法：看日志
日志级别
要求：IO路径上最少打印
vhost 检查方法： ./vhost --version (自己定制添加的--verison支持）
blockserver 检查方法: cat conf/blockserver.conf | grep level ； level 至少为3； tools/reload 或者初次启动生效；
data server 检查方法 cat conf/dataserver.conf | grep log_level ; log_level 至少为3； reload 生效；初次启动通过conf/ds_gflag.conf 里的log_level 来指定；
配置
CPU配置
要求：计算节点上CPU主频不低于2.4G； 存储节点上主频不低于2.1G
检查方法：
cat /proc/cpuinfo | grep -i mhz | uniq
磁盘配置
要求：存储节点上的所有盘没有慢盘
检查方法：
运行spdk perf 或者 user block system 工具 进行IO压测，保证指定的核不冲突的情况下，iops 单盘至少8W。
CPU绑核配置
要求：SSD 集群上存在混布，dataserver/blockserver/vhost 三个模块绑定的CPU核不能冲突（交叉）
检查方法确定同1个物理节点上下面三个模块绑定的核是否冲突：
blockserver cat conf/blockserver.conf | grep mask
dataserver cat conf/dataserver.conf | grep mask
vhost 通过systemctl status essd 检查配置路径:
[root@qo]$ systemctl status ssd ssd.service - ssd service daemon Loaded: loaded (/usr/lib/systemd/system/ssd.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2021-04-14 20:52:11 CST; 1h 15min ago Process: 2284 ExecStop=/etc/init.d/ssd stop (code=exited, status=0/SUCCESS) Process: 52421 ExecStart=/etc/init.d/ssd start (code=exited, status=0/SUCCESS) Main PID: 52427 (reactor_0) CGroup: /system.slice/ssd.service └─52427 /usr/bin/ssd/vhost -c /etc/ssd.d/kunlun.conf -i 0 -S /run/ssd -s 1024 -f /var/run/ssd.pid -D
然后 cat /etc/ssd.d/kunlun.conf | grep -i reactor
超时配置
vhost [root@qo]$ cat /etc/ssd.d/kunlun.conf | grep -i timeout UcxIOTimeout 800000
blockserver cat conf/data_client.conf | grep -i timeout
IO队列配置
vhost [root@qo]$ cat /etc/ssd.d/kunlun.conf | grep -i batch BatchIONum 128
（上面配置对压力大的情况下，不能太小； 对延时敏感的场合，不能太大）
周期任务配置
dataserver data server 有周期比较副本写入点并拉数据的服务，以及周期统计磁盘使用空间的任务，跑性能的时候可以降低这个频率。
均衡性
数据分布是否均衡
通过dbs tool 来查看block 是否在节点和磁盘之间分布均衡， 示例命令如下：
110.1.1.130 上： /home/x1/ssd_test/data_tools
./dbs list-distributions --masters 10.1.18.130:28401,10.1.16.65:28401,10.1.16.66:28401 --show-store 1 | grep total_used
如果上面输出的数据都一致或者非常接近，可以认为均衡。
IO压力是否均衡
通过监控分别每个bs的iops/latency 是否均衡：
比如：
http://10.1.1.65:27823/vars/bs_write
http://10.1.1.66:27823/vars/bs_write
http://10.1.1.130:27823/vars/bs_write
通过监控分别每个ds的iops/latency 是否均衡：
http://10.1.1.66:59018/vars/ucx
http://10.1.1.65:59018/vars/ucx
http://10.1.1.130:59018/vars/ucx
延时
要求：
看block server 监控, 看每个节点的iops/latency 是否符合预期：bs 的延时应该在100us ~ 900 us 左右； 看data server监控，看每个节点的iops/latency 是否符合预期： ds 延时压力大的情况下，延时不超过150us; ds 延时压力小的情况下，延时 不超过80us 左右；
示例：监控看到ds压力到17w iops以上时，data server 延时到上千us，且大头在ack latency, 不符合预期； 分析原因：CRC 计算打开了 （教训：对业务密集且绑核的处理器核，上面不要有频繁的计算密集型任务）
如果碰到延时不符合预期的地方，可以参考下面的方法进行分析：
方法1：确保io depth 为1 时延时符合预期
把 BatchIONum 从256 → 1 延时 从 945us -→ 262us 把 bs 节点上164上冲突的core 11 (之前另外要给bs也用了）：换了： 262us -→ 174us 虚机绑核： 执行 vcpubond.sh ： 174 us -→ 139 us
此时 bs 相关的配置如下：
[root@qr]# cat conf/blockserver.conf [block-master] hosts = 10.1.1.10:9190,10.1.1.14:9290,10.1.1.40:9390 session_timeout_s = 5
[dbs] alloc_open = 1 alloc_used_ratio = 50
[rpc] long_query_time_ms = 0 rpc_service_port = 17822 ucx_io_service_port = 37828 timeout_ms = 5000 enable_heartheat = 1 heartheat_period_ms = 1000
[spdk] #reactor_mask = [5,6,7,8,9,10] reactor_mask = [12,13,14,15,16,17] #mem_size_mb = 1024 thread_num = 3 rpc_addr = /var/tmp/block-server_2yky.sock
[log] level = 4 flush_level = 4 reserve_num = 36
此时bdev 相关的配置：
方法二：开延时异常模块的日志找异常
通过子模块可以看到各自的延时，能够判断哪个模块延时偏大。延时偏大的模块的异常日志排查需要结合具体的业务逻辑和流程，常见的方法如下：
搜索error/warning/fail 等错误日志; 检查是否有非预期的crc/checksum 计算等； 检查是否有timeout/connection lost 等关键字； 根据IO的log字段（或者分阶段的监控），排查整体流程哪里延时大