扩容后测再平衡性能核心看三件事：数据是否真搬过去、集群负载是否拉平、业务访问是否受影响；重点是迁移的快、稳、准，需监控进度分布、资源波动及业务指标，并按需调速。
扩容后测再平衡性能，核心是看三件事：数据是否真搬过去了、集群负载有没有被拉平、业务访问是否受影响。重点不是“有没有触发”，而是“搬得快不快、稳不稳、准不准”。
看数据迁移进度与分布均匀性
先确认再平衡是否启动并持续进行，再验证结果是否达标：
- 查迁移任务状态：比如在 Ceph 中执行 rados df 或 ceph osd df，观察各 OSD 的 KB used 是否逐步趋近；DolphinDB 可调用 getClusterStatus() 查看 rebalanceProgress 字段
- 算标准差：取所有存储节点的已用容量百分比，计算均值与标准差。若标准差 >15%，说明分布仍倾斜；理想值应控制在 5% 以内
- 核对副本落点：用 hdfs fsck / -files -blocks -locations（HDFS）或 ceph pg dump_pgs_brief（Ceph）检查关键数据块的副本是否已按新拓扑分散到新增节点
监控再平衡过程中的系统资源波动
再平衡本质是后台大量读写+网络传输，会争抢 IO、CPU 和带宽。必须在业务低峰期测，并紧盯以下指标：
- IO 延迟稳定性：关注 P95/P99 延迟是否突增或抖动。zStorage 实测表明，重构时若延迟波动超 20%，就可能引发数据库事务排队
- IOPS 与吞吐下降幅度：正常再平衡应控制在整体 IOPS 下降 ≤10%。可用 fio 持续压测 + iostat -x 1 对比迁移前后数值
- 网络与 CPU 占用：特别是源节点（读旧数据）、目标节点（写新副本）、元数据节点（调度协调）三类角色的负载是否局部过载
验证业务层可感知的性能变化
再平衡不是运维内部动作，最终要落到应用表现上。建议用真实负载或影子流量测试：
- 跑一组固定 SQL 或查询作业（如 Scan 1TB 表、聚合统计），记录平均响应时间、失败率、重试次数，对比扩容前基线
- 模拟热点访问：定向请求某几个原热点分片对应的数据范围，确认这些请求是否已被分流到新节点，响应是否变快
- 检查连接池与超时：部分中间件（如 TiDB Proxy、HBase RegionServer）在再平衡期间可能短暂拒绝连接或返回 NotServingRegion，需捕获这类异常日志
调整再平衡强度以匹配业务节奏
多数系统支持限速，避免“一把梭”式迁移冲击线上服务：
- Ceph 可设 osd_max_backfills、osd_recovery_max_active 控制并发恢复数
- zStorage 提供 1–32 档位的重构速率参数，日常默认 8（≈1GB/s），维护窗口可临时调至 24–32
- DolphinDB 的 rebalance 函数支持 maxBytesPerSec 参数，单位字节/秒，建议从 50MB/s 起步压测
