点击此处浏览总目录

性能瓶颈之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)

posted @   立业的博客  阅读(353)  评论(0编辑  收藏  举报
编辑推荐:
· DeepSeek 解答了困扰我五年的技术问题
· 为什么说在企业级应用开发中,后端往往是效率杀手?
· 用 C# 插值字符串处理器写一个 sscanf
· Java 中堆内存和栈内存上的数据分布和特点
· 开发中对象命名的一点思考
阅读排行:
· PPT革命!DeepSeek+Kimi=N小时工作5分钟完成?
· What?废柴, 还在本地部署DeepSeek吗?Are you kidding?
· DeepSeek企业级部署实战指南:从服务器选型到Dify私有化落地
· 程序员转型AI:行业分析
· 重磅发布!DeepSeek 微调秘籍揭秘,一键解锁升级版全家桶,AI 玩家必备神器!
点击右上角即可分享
微信分享提示