南大通用GBase 8a运维案例分析:通过sftp加载几十个300MB的文件的性能差

客户现场一般都做了安全加固,如果某些服务,有连接频率限制,可能会导致性能问题。本文介绍的一个案例是客户的sftp服务加载,导致的加载性能慢的情况。

现场

客户反馈加载性能慢,数据有挤压‘。每次加载40个文件,均在300MB左右,压缩的,借解压后大约1.5GB。现场有80台服务器,每次设置了50个加载机,每次加载需要耗时80秒。

分析

查看数据源

未发现sftp服务器有严重的CPU和磁盘IO问题,而总数据量才300MB*40个=12G,分散到60秒内,每秒才200MB。

而能达到200M,网络没有降速的问题,否则万兆网降速到千兆不会超过100MB。

查看加载进度

通过观察加载进度元数据表(GBase 8a集群查看加载进度的方法),发现每个加载节点的任务,耗时只有10-20秒,而最终的完成时间却要80秒,多出来的50-60秒呢? 怀疑在加载任务分解期间,耗费了大量时间。

查看加载TRC日志

通过打开加载日志,手工执行了一个加载任务,发现时间果然花费在连接sftp服务,并获取文件信息的阶段。 GBase 8a集群加载的详细过程日志排查加载性能问题

怀疑用户的sftp服务,设置了频繁连接的安全加固策略,不允许客户端过于频繁连接。

解决方案

由于客户是压缩文件,是无法拆分的,同时客户的每个数据文件尺寸,很好的控制在了300MB, 也没必要切分,所以在加载的SQL参数里,增加了nosplit参数,让加载执行任务生成计划时,直接按照文件数量拆分即可,无需考虑文件尺寸。

GBase 8a 加载大量小文件时,通过NOSPLIT参数较少执行计划耗时

最终现场的性能在20-30秒之间。