南大通用GBase 8a运维案例分析:扩容重分布期间,某节点性能极差,其它10分钟,其需要2-3个小时

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