扩容后测再平衡性能核心看三件事：数据是否真搬过去、集群负载是否拉平、业务访问是否受影响；重点是迁移的快、稳、准，需监控进度分布、资源波动及业务指标，并按需调速。

扩容后测再平衡性能，核心是看三件事：数据是否真搬过去了、集群负载有没有被拉平、业务访问是否受影响。重点不是“有没有触发”，而是“搬得快不快、稳不稳、准不准”。

看数据迁移进度与分布均匀性

先确认再平衡是否启动并持续进行，再验证结果是否达标：

• 查迁移任务状态：比如在 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 起步压测