客户现场一般都做了安全加固,如果某些服务,有连接频率限制,可能会导致性能问题。本文介绍的一个案例是客户的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秒之间。