400应用分析案例：Job的CPU占用过高 如何控制？

400应用分析案例：Job的CPU占用过高 如何控制？

 

问：

 应用subsystem下的job都是通过ODBC连接的，每次运行占用的CPU特别高，有什么办法控制吗？

 

答：

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

 

      现在我们再来探讨cup%的问题。cup系统资源用于处理odbc的应用时，分为三种类型的处理：1）Job的有效处理，即对pf表的有效处理；2）os调度的页进页出；3）磁盘I/O操作占用的cpu处理。

 

   对第一种类型的处理，我们不能降低cpu处理时间，要的话，只能优化应用程序代码（后续会谈到这个问题）。第二种类型的处理，如果程序代码数据量，或表记录数据较大，表的关联数较多复杂，且经常更换处理模式，一旦物理内存资源处在较饱和状态，os对这类操作的系统调度，即页进页出，就会处在频繁状态，会占用较多的系统cpu资源。同样，对第三类操作，如果应用在一个处理单元内频繁访问一个pf或多个pf表，会使得os对这个应用的I/O数始终处在一个较高的次数值，会耗费一定cpu%。如果并发的应用对这样的表同时进行读取和更改，就会使得I/O处在一个高峰期，就会出现系统资源使用排队现象。

 

        对这类odbc，或jdbc的应用优化办法，除了应用代码的改进，就只能从系统上进行管理。首先，通过前端测试软件，测试odbc或jdbc对pf表就一个应用单元的访问次数。不久前前我们做过这方面的测试，对一个客户反应等待时间超长的应用项目进行过测试，这个应用项目由于开发商没有考虑好应用架构，一个应用处理单元对一个pf表的访问次数最高达到好几万次。这样的应用过程，占用系统I/O的操产生的累计时间，肯定会造成不好的后果。

 

 如果对应用程序短时间不能更改应用系统架构的话，在os系统方面的处理，最好把这些应用频繁访问的表放到物流内存中去。这样的措施，起码起到了降低上述第二、三类的cpu%的值。

 

续答一：

 

随着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的百分比值，即无效的调度；或者，因为CPU始终处在繁忙状态，进入物理内存等待系统资源CPU的页等待超时，这时也会产生Fault Pages。

 

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