POWERCENTER 调优方法体会

POWERCENTER 调优方法体会
调优方法体会：
经过一段时间的摸索，个人认为调优一个很关键的问题在于session的调度上，尽管在单个mapping的设计上可以有所改进，但是改进效果是有限的。比如我一开始说的例子，实际上如果在server非常空闲，数据库也非常空闲的时候，跑起来也并不会非常慢，3个多小时。但是同样一个session一旦和其他session并发跑起来，争夺数据库以及机器的资源的时候。可能分配到很有限的资源，造成速度极慢，而各个session的重要性以及里面的数据量却是不一样的，平均分配资源显然不是一个好办法。
一开始我认为尽量并发多个session肯定是最好的，大不了一个session跑完，资源释放掉，再分配给另一个session嘛，但实际情况并不是这样，我的观察结果是，一旦一个session跑起来以后，即使其他session已经跑完了，只剩下他自己在跑，他的速度也不会提高，会按照自己的速度继续下去。比如说上面提到的例子是所有session中最慢的，其余的都跑完了，他一开始得导入速度是几百条，以后就会一直按照这个速度进行下去，这样整个系统的抽取时间必然是增加到一个不可接受的程度。自我感觉，资源好像是在一开始分配好的，后来就不能改变了。
对于单个mapping的调优，首先应该在设计上找些问题，一般来说速度慢的地方都会出现在joiner和aggregator组件中，尤其在数据量非常大的时候，这两个组件都会占用大量时间，因为他们先是读入数据，然后再经过处理，最后再一点点的输出。而像expression这样的组件就很好，基本上是边读边输出，再进目标表之前如果是个expression组件当然是再好不过，基本不会对效率有任何影响。当然，我的意思并不是说不使用joiner和aggregator组件，一个mapping里面不使用这两个组件的情况还是非常少的，只是说效率的瓶颈往往出现在他们身上，我们找mapping的问题的时候，有个方向。
对于joiner和aggregator组件，一个常用的方法就是在session里面提高他们的cache,尽量减少io。对于aggregator还有一个if sorted的用法，在分组之前排好序，会提高aggregator的分组速度，尤其是对于iq，可以充分利用它的特点，在sql qualifier中先排好序，然后再经过aggregator组件，具体的使用方法大家就看infor的帮助吧。对这个排序的问题想多说两句，大家不要认为在进入任何aggregator组件前都要排序，这样就能提高性能，自此大量使用sorter组件，我的经验是要根据具体情况具体分析，有些数据量很小的根本没有进行排序的这个必要，试想一下，一件事情交给两个组件做，又多了一个处理过程，这样并不一定对效率有什么好处，而且又占用了server的资源。而针对大数据量进入aggregator的时候，加一个sorter组件，同时增加sorter的cache，还是有一定好处的，我的例子中就使用了这一招，还是有一定效果的。而同样一个针对小数据量的mapping,用了同样的招数，反而速度降低了。
如果大家细心的话，可能会发现，对于单个mapping的优化很有可能要针对瓶颈组件增加大量的cache ,以及在session中提高dtm，这个时候我们的系统资源！！！一旦多个session并发跑起来，不可想象的情况就会出现，每一个session都要占用大量的虚拟内存，数据库资源，cpu。。。这时候机器不死掉就已经是万幸了，还指望跑得快?
我们的矛盾出现了，我们非常希望提高每一个session的效率，但是我们有要求整体跑得快。。最终我认为还是应该在整体上考虑，也就是说通过调度顺序的调整来使每个session达到尽量高的效率，并发度不要太高，但是也不能完全串行跑。这个调整的过程是有趣的，由于我的环境问题，经过几天的测试，我找到适合自己环境的比较合理的一个并发度以及调度次序。使得每一个session跑起来的速度不会比资源完全空闲单独跑的时候慢，简单说就是串并比较合理，比完全串行要快，比完全并行也要快。这个过程我没有找到很好的办法，需要根据具体情况来调整了。“田忌赛马”的故事可能会给我们一点提示，呵呵！咱是我的调整情况时，尽量保持同时只有2-3个session并发，而且保证那些大数据量的session在启动的时候一定要能够分配到多的资源，不要在它启动的时候和多个session竞争资源，而对于跑得特别特别快的session完全可以让它一起并发作，反正占用不了多少时间，做完了就释放掉了。这也算是一个原则吧。

总结一下吧：1。调优要着眼在整体调优。
2。单个mapping是否存在效率问题，最好是单独测试一下再作判断，不要在并发session的过程中盲目认为它存在效率问题。
3。对单个mapping的调优主要集中在joiner,aggregator组件上（大家再补充），调整相应的session中的cache会有一定效果，但并不绝对。
4。提高dtm有限度，而且会占用很多存储，最好是经过计算得到合理的dtm值。
5。session中搜集调试信息也可以帮助你判断单个mapping的瓶颈，同时可以加深对mapping运行过程的理解。日志的重要性就更不用说了，是我们发现瓶颈问题的最关键的信息。
6。个人认为整体session的调度次序是最重要的，串行不一定慢，并行也不一定快，串行和并行达到合理得"度"是很关键的。在提高了单个session的dtm、cache等等之后，适当减少并发度是必需的。

我说的都是一些个人体会，希望各位看官多多指正，多多拍转。也希望大家多和我交流：）
针对楼主的问题， 我要说两句， 强调一下，只针对问题
1，首先我要说你调研的深度，比较浅。 你在并行多个session的时候，你发现速度有时候反而比较慢，这实际上归根到底是机器资源的问题，但是 我想你肯定没玩过，一个session并发成多个线程跑，即parallel 的特性，前提是你购买了informatica集群的服务。那么举个例子，一个session并发6个线程，可以同时在3台机器跑，每台机器两个线程，那么以这种方式，想你应该没调研过
2，informatica这玩意，所以他对内存的要求比较高，特别是你在 使用sort，join ，aggreate，rank ，lookup 这组件时候，如果你分配的好，而且机器内存又够的情况下，性能提升很明显
3，在针对单个mapping调优的情况下，这其实取决一个开发人员对各个组件的认识深度上，就最简单的例子来说，join 其中的master跟detail两源数据的时候，master跟detail量的问题对配置session中cache有很重要的影响，这只是一个最小最简单的例子说明下问题
4，想必你对DTM的概念理解的很浅，建议你把英文文档翻出来，好好体会下意思，已经它对提供性能方面的意义
5， 我们在实际的一个项目中，使用了类似你的串并行想结合的方式，在实际开发运行中，实施难度比较大，既要集合数据量的问题，又要考虑机器cpu，men负载问题， 除非你做的是一个大型企业级项目，否则，这种方案 并不见得能有多大提高效率