优化指标
EBS中OPP(Output Post Processor)的优化,主要可以由下面3个方面来入手:
- Threads
- Processes
- Jvm memory argument
Threads & Processes
Threads和Processes的设置可以在并发管理器定义的页面中看到,如下:
其中,2代表service threads的数量,max_threads参数控制request threads的数量。可以根据需要增加max_threads的值(max_threads可以说是定义OPP吞吐量的一个重要参数)。
Jvm memory argument
Jvm memory argument可以使用apps用户登录数据库,运行下面sql得到:
sql
SELECT service_id, service_handle, developer_parameters FROM fnd_cp_services WHERE service_id = (SELECT manager_type FROM fnd_concurrent_queues WHERE concurrent_queue_name = 'FNDCPOPP'); SERVICE_ID SERVICE_HANDLE DEVELOPER_PARAMETERS ---------------- -------------- -------------------------------------------------------------------------------- 1080 FNDOPP J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx512m
优化原则
Threads VS Processes
每个OPP process都需要在OS中启动单独的java进程。所以在调优过程中,建议先增加Threads的数量,Threads的数量受每个process可以使用的内存限制,在已有的threads还不够用时,就需要增加process的数量了。
每个OPP的process都会占用单独的内存,所以在增加process个数的时候,OS空闲内存就是要考虑的一个因素。
Increase jvm memory
在OPP服务进程中出现outofmemory错误时,就需要增加jvm内存参数了,可使用下面sql来调整OPP的jvm memory参数。调整之后需要重启OPP生效。
sql
UPDATE fnd_cp_services SET developer_parameters = 'J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx1024m' WHERE service_id = (SELECT manager_type FROM fnd_concurrent_queues WHERE concurrent_queue_name = 'FNDCPOPP');
系统整体性能考虑
EBS中,OPP主要用来处理XML Publisher生成报表的请求,在11i和R12版本中,OPP使用32位java,所以单个OPP process最多只能使用4G内存(而Oracle建议的值为2G),所以从处理能力方面来看,单个OPP进程是受到很大限制的。在运行比较大的报表,出现outofmemory错误时,单纯增加process和threads已经不能很好解决问题,需要从报表的性能上去考虑。在处理比较小的报表请求时,较大的process和threads参数可以增加系统的吞吐量。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。