某客户反馈，扩容操作重分布已经快1个月了，发现每天就完成十几个表，按照这个速度，需要半年以上。经过排查，发现客户是在云环境，部分计算节点之间，出现严重的网络问题，上行和下行速度都极差(500K-2MB),正常的至少150MB。
目录导航
现场
某国外客户，业务最大的表，每天400-600亿行，由于业务还在增加，从60扩容到了80多个节点。数据重分布已经有1个月了，发现完成分布的表只有300多个，其中还包括了一些业务量较小的表，总共任务有2000+。
另外，该客户使用了2分片方案，也就是每个计算节点有2个主分片，是由于建立集群时，对参数理解歧义，操作失误造成的，本次扩容，也调整成1个主分片。
排查
查看加载进度
通过 GBase 8a集群查看加载进度的方法，发现其它节点很快完成，不超过10分钟，而这个节点的任务需要2-3个小时。
查看计算节点任务
show processlist，也能看到只有这个节点有任务在跑。
等待新一轮的任务，发现其它节点，在500秒左右就完成了，只有这个节点还在继续。
检查速度慢的节点
检查CPU
cat /proc/cpuinfo | grep MHz每个核的频率基本一致，没有看到降频的情况。
检查内存
free -g可用内存还有20G,没有SWAP。
检查IO性能
iostat -xdc 1发现CPU,磁盘都非常空间，都不要10%的使用率。磁盘的等待时间大约20-30毫秒，属于极差的范围，怀疑磁盘问题。
测试磁盘fio
通过fio测试，(fio磁盘性能测试参数)未发现问题，基本读写都能达到140以上。
测试网络性能
随意挑选了几天服务器，通过SCP做文件复制，都能达到150MB/s的速度。
阶段一总结
至此，该节点的系统资源，未发现问题，但为啥性能如此慢呢？ 难道是数据库内部出现了逻辑错误？
重启数据库服务
将该节点的数据库服务重启后，问题依旧。 难道是操作系统本身除了问题吗？
重启虚拟机操作系统
reboot了该虚拟机，问题依旧。 没办法了，只能联系研发处理了。
打开详细的trc日志
此时发现该节点，该i节点的有2个分片任务，其中一个耗时略长，大约600-700秒，另一个分片耗时几个小时，同一个机器，难道还有区别对待？
通过trc日志，发现快的分片发，向2个节点发送了数据，慢的分片，是完全不同的另外2个节点，难道是目标节点性能有问题？
排查目标节点
整个测试了2台目标节点，CPU，内存都正常。向集群首节点scp数据也正常。
但向前面数据发送方的节点，做scp时，发现速度只有2MB/s。 反向scp,从加载机向目标接受端，性能竟然只有500KB/s。这些机器，向集群首节点scp都能达到150MB/s，这是啥情况？
排查网络
客户安排人员排查网络问题，最终发现，某些在一个机架上的虚拟机，全部有网络问题，且上行和下行速度有明显差异，但都很低，但对外连接性能又是正常的。
解决
最终，客户从云平台，自行解决了【部分节点】之间的网络问题，重分布性能整体恢复。
总结
由于部分节点之间网络性能问题，包括上行和下行就差距很大，导致节点外发数据慢，最终重分布耗时长。
另外，云环境的磁盘IO,其等待时间普遍较长，物理机基本在5毫秒以内，而云虚拟机，要达到20-30毫秒，确实性能差了很多。