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

qingzhou

再转下我以前回复的比较完整的解决ODBC/JDBC访问DB2/400方案。

================================================================================

（原）如何妥善处理ODBC for iSeries应用业务
QINGZHOU 发布时间：2007-05-07 20:05


AS/400机器对ODBC接口支持方面很糟糕，不但ODBC应用严重消耗400资源，引发DISK ARM I/O高峰，而且会产生甚至高达200G以上的临时空间，从而造成400宕机，所以要引起管理人员的重视。
针对ODBC应用的问题，我是这样去处理：

1、错开多项ODBC应用同时使用：
如果有多项以ODBC方式的应用使用的并发，可以根据企业实际情况尽量错开使用时间，以免造成AS/400 DISK I/O持续高峰，严重影响机器性能，致使核心业务系统无法正常运行；

2、限制ODBC的“最大作业数”和“允许最大使用临时空间”参数：

具体处理方法是：

㈠ 修改QZDASOINIT作业所使用的CLASS(系统缺省为QSYS/QPWFSERVER)，将CLASS 中MAXTMPSTG 值改为允许的最大临时空间，当其在运行中，临时空间超过该值时，系统自动结束此QZDASOINIT作业，避免系统崩溃。
CHGCLS CLS(QSYS/QPWFSERVER) MAXTMPSTG(50000)
例将缺省的*NOMAX改为50000(50MB),则当该作业的临时空间超过50MB时,作业会自动停止。

㈡ 另外,通过修改QZDASOINIT作业的Prestart Job Entry，将Maximum number of jobs值改为指定的最大作业数，以限制其最大的并发作业数，避免系统崩溃。
===> dspsbsd qsys/qusrwrk 再通过10. Prestart job entries查询QZDASOINIT作业所对应的Program和JOBD
===> CHGPJE SBSD(QSYS/QUSRWRK) PGM(QSYS/QZDASOINIT) MAXJOBS(500)
例将缺省的*NOMAX改为500，则当该作业的最大作业数超过500时,作业会自动停止。
Notes！！！
1. The value specified on this parameter must be greater than or equal to the value specified on the Initial number of jobs (INLJOBS) parameter.
2. The value specified on this parameter must be greater than the value specified on the Additional number of jobs (ADLJOBS) parameter.
3. If the value specified on this parameter is changed, the value specified on the Class (CLS) parameter might also need to be changed.

文件: 如何限制ＱＺＤＡＳＯＩＮＩＴ作业的临时空间和最大作业数.rar
大小: 111KB
下载: 下载



通过限制ODBC作业的“最大连接数”和“允许使用的最大临时空间”这2项参数来控制ODBC，以免ODBC干扰系统性能；也避免因ODBC作业产生的临时空间造成400的%system asp used >95%(默认警戒值)后引发机器宕机.

3、导入WRKODBCJOB工具简便管理：
通过WRKACTJOB仅能看到QUSRWRK/QZDASOINIT该ODBC作业名称，无法针对使用ODBC的帐户、IP地址、以及打开的文件数 等情况进行管理，可以导入WRKODBCJOB工具来进行方便管理，具体可参考如下连接：
wrkodbcjob工具管理以ODBC方式访问AS400的用户、访问文件数以及ip地址

4、改善和优化ODBC的应用：
可通过OS/400命令行执行STRDBMON数据库监控器专门来收集ODBC应用的信息，也可以通过Navigator，同时，最好选择在ODBC业务高峰期收集信息，这样收集的信息会更有参考价值。然后会得到一份分析报表，根据分析报表我们可以知道ODBC应用存在什么缺陷或不足，然后再去改善你的ODBC应用，从而到达改善和优化ODBC的应用的作用。
例如：通过iSeries Navigator使用DB Monitor对ODBC作业进行监控


5、升级DISK CACHE
一般在DISK I/O高峰时，我们通过WRKDSKSTS可以发现往往都是前6块DISK比较繁忙，那是因为那6块DISK上装的是OS/400操作系统，而且其中一块是SOURCE盘，本身400机器出厂的6个DISK上的CACHE很可怜，可能才30多M，难怪I/O BUSY会集中在前6块DISK上。

以下有3种做法：

1）将6块DISK与外面扩展柜（上面是应用数据）进行对调，扩展柜一般都有300-400M的CACHE，这样把最频繁读写OS/400的前6块DISK调到外面扩展柜，CACHE大了近10倍，I/O性能多少有改善。

2）将系统进行划分，ASP1，ASP2，ASP3，其中1个分区放OS/400，一个放核心应用，还有一个放Journal日志，这种说法以前曾经得到比较多工程师的认可，但后来很多人都不认为这样做法会显著改善系统性能。

3）加磁盘扩展柜，也就是说，干脆前6块DISK都拿出来，放在扩展柜里面，宁可让系统自带的6个插槽空着，30多M的CACHE让我们如何跑OS/400呢？！但这种方案要求用户有足够的银子~~~

处理案例：

AS400 ASP %BUSY持续居高不下时的诊断过程及一些处理措施

AS400生产机器%system ASP used涨满的紧急处理参考对策

就暂且说到这，希望这些经验给你带来帮助。

qingzhou

另外，附上一个解决“在断开ODBC/JDBC连接后QZDASOINIT作业仍然处于RUN状态”的办法。

当您偶尔运行一个运行时间长或者未经调试的查询语句的时候，您发现后台iSeries的响应速度很慢，于是，您断开了客户端，或者强行结束了查询所在的前端应用程序。此时，尽管您的前台ODBC/JDBC应用都已经停了，但是发现iSeries后台数据库服务器（对应QZDASOINIT作业）还在继续运行（处于RUN的状态），并且占用大量的CPU和临时空间。

对这种现象，我们要先知道iSeries后台的HOST服务是如何处理这样的通讯的：

当HOST服务作业收到一个从前台应用发出的运行查询的请求的时候，它会把执行的内容发送到iSeries DB2 UDB。如果客户端应用程序企图通过断开连接来取消这样的请求，TCP/IP将这样的请求错误/通讯错误存到缓冲里面，因此，HOST服务就收不到这样的出错信息，直到查询的执行代码在iSeries DB2 UDB中运行结束，HOST服务才会送出一个回答信息。

如何把这种长时间运行的查询语句所产生的影响减到最小，您可以考虑以下的方法：

1。使用命令ENDJOB来结束那些长时间运行的查询作业。

2。使用或修改前端的应用程序，使这些程序支持“取消”操作。（ODBC/JDBC/CLI都支持取消操作）

3。利用应用程序对查询运行时间的限制条件，让长时间运行的查询语句超时。或者使用iSeries上改变查询属性的命令来实现：
CHGQRYA QRYTIMLMT(20)

注意：
A）这个方法并不适用于那些未经优化的查询语句。查询运行时间是根据预计的访问计划计算的，如果所有的数据都已经提供了，那么查询会一直运行。
B）对于那些有多处理器的iSeries系统，可以通过命令CHGQRYA DEGREE（*NONE）来关闭系统的多处理功能，这样就能帮助您减少QZDASOINIT作业所使用的系统资源。

4。优化您的查询语句。iSeriesAccess的操作导航器中包含一个可以显示引起长时间运行的SQL语句的功能。您可以利用这个功能来优化您的语句。

5。另外，如果在QZDASOINT中运行DEBUG，也会引起作业不结束，现象是检查该作业的CALL STACK，发现有以下2个项：
WZDA_GetBigArea
WZDA_Stg_Report
WZDA_Stg_Report 是DEBUG工具用来把该作业所使用到的临时空间的情况输出到打印文件中。所以建议不要在该作业中使用DEBUG功能。

qingzhou

把帖子存档备查，以便下次需要的朋友直接参考处理。

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平台整体效益上就会处在一个较为合理的处理环境下。

lhh03seer

回复 11# qingzhou


    感谢两位大师的回复。