性能瓶颈之Source
数据源的瓶颈通常发生从数据库读取数据的时候,原因通常如下:
1) 脚本的查询效率低下
2) 数据库网络包太小
如何判定源瓶颈
通过在session log中读取thread statistics判定源的瓶颈
如果read thread花费的时间大大多于write thread和transformation thread,则可说明性能瓶颈在于目标数据库
如果session是从源文件读取数据,则性能瓶颈可能不在源
如果session是从关系型数据库读取数据的,可通过如下方法判断源的瓶颈
使用filter组件
在每一个source qualifier组件后追加一个filter组件,将条件设为false(如1=2)确保没有数据通过
如果session运行的时间还是没有变化,则可判定瓶颈在源
创建测试用的read mapping
创建测试用的read mapping,并将查询与其他组件隔离,创建步骤如下:
1) 将原来mapping复制
2) 在复制的mapping里,只保留sources, source qualifiers和任何其他custom joins或queries组件
3) 移除所有中间数据转换处理的组件
4) 将source qualifiers组件连接至目标文件
如果session运行的时间还是没有变化,则可判定瓶颈在源
使用数据库查询
直接在数据库端运行查询脚本
如果脚本运行的时间很长,则可判定瓶颈在于源的查询脚本
如何解决源的性能
1) 当Integration Service从文件读取数据,可设定读取每行数据时的最大字节数
2) 让DBA优化查询脚本
3) 增加数据库网络包大小
4) 追加索引和约束
5) 如果一个数据库查询在两个时间测量之间有很长的延迟,可以考虑使用优化器(optimizer hint)
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek 解答了困扰我五年的技术问题
· 为什么说在企业级应用开发中,后端往往是效率杀手?
· 用 C# 插值字符串处理器写一个 sscanf
· Java 中堆内存和栈内存上的数据分布和特点
· 开发中对象命名的一点思考
· PPT革命!DeepSeek+Kimi=N小时工作5分钟完成?
· What?废柴, 还在本地部署DeepSeek吗?Are you kidding?
· DeepSeek企业级部署实战指南:从服务器选型到Dify私有化落地
· 程序员转型AI:行业分析
· 重磅发布!DeepSeek 微调秘籍揭秘,一键解锁升级版全家桶,AI 玩家必备神器!