以下提到的Session log,是指在这个$PMRootDir/SessLogs目录下对应着每个运行的session都有一个以.bin结尾的二进制文件,在查看的时候用strings这个命令
用线程统计定位瓶颈:默认情况下infa会分配:一个read线程,一个transformation线程,一个write线程,来处理一个session,这些都可以在Session log中查看:
run time:线程运行时间
Idle time:线程空闲时间
Busy time: 线程忙的时间(是个比列)
Thread work time:处理某个transformation用的百分比。
排除基于线程的瓶颈:1.在read和write 线程中busy占的时间比较高时,可用string这种数据类型来对源和目标进行处理,因为处理非string时需要更多的时间。2.在transformation线程busy占的时间比较高时,可用增加partition point来进行处理,当你每增加一个partition,会多分配一个transformation线程来处理数据(这也要考虑系统的环境)。3.当某个transformation组件的处理时间超过其它的组件很多的处理时间时,可以考虑增加partition来对其进行处理。
很悲剧的是,我在8.5.1里面好像没能准确到某个transformation组件,找不到breakdown的等信息?
写数目标瓶颈:通常造成写数目标瓶颈有都是写入数据库:小的checkpiont间隔,小数据库网络包,系统负载过重。找出写瓶颈:可以把目标直接设成写文件模式,这时要是速度快很多,表明是有写数据瓶颈,可以查看session log如果write 时间明显超过转换或读的时间,也表明有。大致的解决思路,DBA帮你优化数据库,数据库查询,增加网络包大小,建立索引,和主键等。
读源数据瓶颈:主要有低效的查询,数据网络数据包配置的较小
找出读瓶颈:可以查看session log如果read时间明显超过转换或写的时间,也表明有该瓶颈。用Filter transformation查出,在这个组件中把condition直接设为false假如速度还是很慢,说明read有瓶颈。去掉其它多余的组件直接写入文本中,看速度如何。还是较慢,说明有问题。直接在log文件中把生成的sql代码放到数据库中执行,看速度如何解决办法:假如是从数据文件中读取,调整每行的字节数对数据库进行优化,增加数据库的网络包大小,建立索引,和主键,还可以告诉数据库sql的按照自己执行计划等。
Mapping瓶颈:当transformation线程这个线程明显高于读,写线程的时间时,或者在某一个transformation组件上花费了较多时间时,瓶颈极有可能是在transformation线程上查看session log 分析性能计数器。errorrows rowsinlookupcache计数器显示很高,也表明是这个瓶颈。还可以这样,直接在写入时加上一个filter,条件为false,看比原先的执行速度没有明显的提高说明存在这个瓶颈。
Session瓶颈:这个主要是监控session log文件中的信息,主要监控input rows, output rows, and error rows这些数据。
系统瓶颈:infa在执行Aggregator, Joiner, Lookup, Sorter, XML, and Rank这些组件时,这些在系统分配的时候同样在Session log里面都有了详细的记录,都是要利用系统空间来创建cache文件的,当然cpu Memory usage,Swap usage.磁盘的占用空间都是要实时进行监控的。