求助： Job的CPU占用过高 如何控制？

passthru

谢谢qingzhou

进一步的问题：我是希望这个subsystem下的job一直保存我更改后的值：因为这个subsystem下的 ...
lhh03seer 发表于 2011-02-28 14:31

    这个‘subsystem’是自己设置的应用子系统吗？还有其它应用子系统与之并存吗？

   如果只有这个应用子系统，可以把这个子系统的ASP空间分配一个较大的空间，最好不要让系统自动分配。因为，odbc，或jdbc连接的应用，os会在这个子系统中运行os下sql环境，一个连接会占用一定asp空间，随着odbc的连接数加大，asp占用的空间加大。

   现在我们再来探讨cup%的问题。cup处理odbc的应用，分为三种类型的处理：1）有效处理，即对pf表的有效处理；2）os调度的页进页出；3）磁盘I/O操作占用的cpu处理。
   对第一种类型的处理，我们不能想法降低cpu%，要的话，只能优化应用程序代码。第二种类型的处理，如果程序代码数据量，或表记录数据较大，表的关联数较多复杂，且经常更换处理模式，os对这类操作的系统调度，即页进页出，就会处在频繁状态，会占用较多的系统cpu%资源。同样，对第三类操作，如果应用在一个处理单元内频繁访问一个pf或多个pf表，会使得os对这个应用的I/O数始终处在一个较高的次数值，会耗费一定cpu%。
   对这类odbc，或jdbc的应用优化办法，除了应用代码的改进，就只能从系统上进行管理。首先，通过前端测试软件，测试odbc或jdbc对pf表就一个应用单元的访问次数，（以前我们做个这方面的测试，不好的应用架构，一个应用处理单元对一个pf表的访问次数最高达到好几万次。）如果这些应用程序短时间不能更新的话，在os系统方面的处理，最好把这些应用频繁访问的表放到物流内存中去。这样的措施，起码起到了降低上述第二、三类的cpu%的值。

passthru

轻舟从系统管理角度对odbc或jdbc应用引起cup值过高采取的措施。这方面他是专家，比我更专业。我主要是从软件和应用开发方面提出我的经验，供你，或有同类问题的朋友参考。

随着400应用项目开发深度开拓，一类以400为DB，前端用odbc或jdbc的应用领域也不断扩大。这类以400为DB，前端用odbc或jdbc的应用开发，在400方面可以采用IBM对这类应用的一些改善性能的技术和措施，比如通过odbc或jdbc连接到400的sql语句，在项目实施初期，采用MQT技术，即较复杂的sql语句事先通过navigatior窗口定义MQT类型应用，把定义中使用的sql语句事先运行，在400磁盘上产生一个数据结果集。在前端通过odbc或jdbc进入400应用发生原调用sql的之处，因为sql已经在磁盘上产生了这个sql运行的数据结果集，这时，这个sql应用只要在sql语句中做一个实际表与MQT表的数据同步，即事先产生sql数据结果集的数据与sql发生的对象数据源记录数据进行同步。因为，实际同步的记录数据量很有限，数据同步时间比运行sql产生数据结果的时间大大缩短，关键是避免了实际应用中sql的运行环境和sql运行占用系统资源。这样在实际odbc或jdbc项目中，就会使得系统cpu%值大大降低。

前面说过的把sql频繁访问的表（PFs）放到物理内存中，即每一天应用系统初始化时，用SETOBJACC (Set Object Access)命令，把这些频繁被odbc或jdbc访问的表放到物理内存中。当然这些pf表的大小，与物理内存大小比值是决定这些pf表或某个pf表是否能放入物理内存的要素。要留有充分的物理内存空间让os和应用系统正常运行。

另外，我再补充一下，这类应用的分析和400系统相关的措施。
对400为DB，前端采用odbc或jdbc的应用，cpu%过高是一种现象；另外一种现象是两个Fault Page%系统指标，可以通过dspsyssts查看到。前者的fault page是反映os调度DB数据的页进页出，无效页操作的百分比；后者是os调度除db数据之外的系统资源与应用代码的无效页操作百分比。

我们都知道计算机的实际运行处理都是通过物理内存来处理进行的，任何程序代码和数据只有放到物理内存，通过cpu，依照程序代码时序进行处理。当物理内存充足时，os就把运行的程序代码和数据都装入内存进行处理。当物理内存不富裕时，os就采取调度策略，只装载需要的程序代码段数据和相关的数据到物理内存进行处理，装载数据过程采用按页进行装载和卸载，这就是os调度的页进页出调度机制。页调度通过dspsyssts画面看到的unprotected，即没有通过RIAD保护的磁盘空间，作为页池，进行页进页出到物理内存。实际应用处理中，比如前端odbc或jdbc链接的应用，如果并发的应用链接数较大，如果系统资源没有预先分配好，或通过系统自动调整等因素，就会增加页进页出的调度频繁，会增加系统cpu的开销。页进页出调度后页处理单元在等待进入物理内存进行处理的时间如果超时，就会照成Fault Page的百分比值，即无效的调度。

如果我们在规划400用于怎么样的应用处理时，我们在安装OS400时，比如用400为DB，前端odbc或jdbc链接的应用，把相关的子系统使用系统资源设为一个较合理的值；把unprotected的缓冲池设置到一个合理的数值，从400平台整体效益上就会处在一个较为合理的处理环境下。