本文所列的诸要点都是对Informatica相关产品进行调优过程中所涉及到较宏观的问题。他们不是放之四海而皆准的教条,也不是最终的解决方案。其中一些已经条目(尤其是已经进行过调优)的建议可能结果会有所不同。适用于某些特定条目的技巧由于其所要解决问题的层次不同也会产生不同的调优结果。
对性能进行测试的时候,建议使用20万条记录左右的数据源进行处理。使用比之更大数据量的测试数据源,可能会产生因为表分区、删除和重建索引、RAID数据条带化等数据库问题导致性能下降的问题,而如果使用的数据源的集合太小,统计出来的平均处理时间肯能会因为数据库吞吐量、主机负荷以及网络流量等因素的影响而变得不稳定。20万条记录的集合一般是进行准确统计的比较理想的测试数据源。
首先试着用如下的方法对Mapping进行调优,然后进行Session的优化,然后重复这一过程直到对调优的结果满意为止,或者无论怎么努力也无法取得更好的效果。如果经过调优,性能仍然无法令人满意,那么整个处理的体系结果就需要进行调整(或者说改变Mapping所要完成的工作)。
始终要记住:要想得到一个理想的运行性能,尽量的要使得系统中的各个部分到达一种运行的平衡状态,包括数据库、硬件资源等,让他们做各自擅长的事情。不同的体系结构可能在速度以及优化的可能性等方面产生巨大的差异。
1)利用数据库(例如Oracle、Sybase、Informix、DB2)进行大量的数据处理操作(例如排序、分组、汇总等)。换句话说,临时表(中间表)会对并行操作有很大的益处。在并行设计中,尤其是通过临时表计算简单的数学计算。
2)尽可能的本地化。将所有的目标表放到Oracle的同一个实例中(相关的SID)。对任何处理都不要使用同义词(远程数据库连接),包括Lookup、存储过程、目标表、数据源、函数、权限等等。远程连接的使用会使得处理的变得很慢。
3)尽可能的使目标表、存储过程、函数、视图以及序列都放到数据源的本地。同样,不要通过同义词连接。
4)减少外部定义的模块。作为代替,在pre-processing/post-processing中使用perl、sed、awk等功能。调用外部的应用编程接口(API)本身就会降低性能
5)时刻谨记Informatica建议每个Session使用1--1.5个CPU。在这种情况下,Informatica可以和关系数据库引擎在同一台机器上配合的很好。
6)减少基于数据库的序列。因为基于数据库的序列生成器需要一个Wrapper函数和过程调用。使用这样的过程会使得性能降低3被左右。而且这样的速度降低也不容易通过Debug来发现,它仅仅是在写入数据库的列是才引起速度的降低。先复制这个Mapping,然后改调用上面提到的存储过程为调用Informatica本身提供的内部序列生成器,这样的运行结果是这个Mapping所能得到的最快的运行结果。如果你必须使用基于数据库的序列发生器,那么最好遵循临时表的使用建议,然后调用一个属性为POST TARGET LOAD的存储过程来分配序列的批量操作。
7)关闭详细日志。Session的日志会对整个Mapping的性能产生极大的影响。在Session里面去掉“覆盖”(over-write),将生成日志的属性设置为正常日志模式。不幸的是,在Informatica的内部,日志记录并不是一个并行的机制,而是直接安排在操作的进行过程中。
8)关闭“收集性能统计”开关。然而,在进行调优的过程中,开启这项功能又是非常必要的,它能发现一些Reader和Writer线程在速度方面的一些问题。
9)如果你的数据源是平面文件,可以使用临时表。这样的话,你就可以使用sql*loader、bcp或者其他数据库的并行装在功能。只把那些简单的处理逻辑放置在数据源的加载Mapping中,不要加入那些编码的查询和转换逻辑。尽量把平面文件放在本地磁盘上,不要放在磁盘阵列中。
10)尽量不要使用无缓冲Lookup。使用无缓存的Lookup时,性能会受到显著的影响,尤其是如果Lookup的表是一个可增长或者是可更新的表,一般来讲这样的表在整个操作过程中它的索引是会发生变化的,因此优化器就无法利用所有的统计信息。同时,尽可能的使用临时表,此时数据库中的视图可以将相关的数据关联起来,或者可以利用Informatica的Joiner对象来关联数据,这两种都可以明显的提高数据处理速度。
11)分离复杂的Mapping。试着将整个Mapping分成一个个逻辑处理单元。如果需要进行并行的处理,重新进行体系结构的设计和布局。通过小的组件来处理单个的任务,可以提高整个处理过程的并行度。
12)平衡,在Informatica、SQL语句和数据库之间取得一种平衡。要重复利用数据库的特长:读、写、排序、分组、过滤;利用Informatica来处理复杂逻辑:外关联、数据继承、多数据源处理等等,这种平衡需要DBA的帮助来实现。
13)调优数据库。根据数据库的大小调整数据库的参数。
14)确保在PMSERVER的机器上有足够的SWAP空间和临时空间。尤其是在Mapping中含有Aggregator、有缓冲的Lookup或者不同数据源的数据关联的操作的情况,更有必要这样做。
15)在开发、运行过程中,在服务器上面运行一些加载监控工具。EMC磁盘阵列也可以考虑一下。
16)设置Session。Session属性中有很多可以用来调优。通过设置“Collect Performance Statistics”属性可以获得在Mapping运行期间的一些性能方面的信息,从而可以对Session的其他属性进行修改,或者对数据库的参数进行调整。调优一个有问题的Mapping的最好办法是把它分成几个部分分别进行测试:(1)读处理,调优Reader,检查相关的配置是什么,把读出来的数据输出到平面文件,以减少冲突。检查“Throttle Reader”参数(默认是不被设置的)。(2)如果在平面文件中写入数据的时候Reader都不是很快,就需要做一些基本的Mapping调优了。尽量合并Expression控件,如果可能的话将Lookup改为非连接的。检查Aggregator和Lookup中索引和shju缓冲区的大小。(3)写处理,如果目标的写入速度比较慢,把Mapping改为一次写入一张目标表,然后可以找到引起写入慢的那个目标表。然后采用数据库优化技术分区、修改统计信息、加载过程中去掉索引等等。
17)将PMSERVER的机器上的所有其他应用都移走,除了数据库、内存数据库和数据仓库本身。PMSERVER可以喝关系数据库配合的很好,但是和其他的应用服务器配合的就很差。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25811908/viewspace-1269442/,如需转载,请注明出处,否则将追究法律责任。