某客户反馈,扩容操作重分布已经快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毫秒,确实性能差了很多。