免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 3571 | 回复: 5
打印 上一主题 下一主题

AS400服务器假死机 [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2009-09-21 12:12 |只看该作者 |倒序浏览
AS400服务器假死机

1、可能是由于用户通过ODBC查询AS400上比较大的表造成的。(大概千万级别)

有什麽办法控制吗?

论坛徽章:
1
操作系统版块每日发帖之星
日期:2015-08-03 06:20:00
2 [报告]
发表于 2009-09-21 13:15 |只看该作者
建立独立的子系统运行odbc  限制odbc作业数量

论坛徽章:
0
3 [报告]
发表于 2009-10-19 19:02 |只看该作者
怎么实现建立独立的子系统控制ODBC呢,能说详细点吗,谢谢

论坛徽章:
0
4 [报告]
发表于 2009-10-19 22:32 |只看该作者
以前个人BLOG写的心得,重新COPY出来供参考。
===================================================================================
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.

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

3、导入WRKODBCJOB工具简便管理:
通过WRKACTJOB仅能看到QUSRWRK/QZDASOINIT该ODBC作业名称,无法针对使用ODBC的帐户、IP地址、以及打开的文件数 等情况进行管理,可以导入WRKODBCJOB工具来进行方便管理。

4、改善和优化ODBC的应用:
可通过OS/400命令行执行STRDBMON数据库监控器专门来收集ODBC应用的信息,也可以通过Navigator,同时,最好选择在ODBC业务高峰期收集信息,这样收集的信息会更有参考价值。然后会得到一份分析报表,根据分析报表我们可以知道ODBC应用存在什么缺陷或不足,然后再去改善你的ODBC应用,从而到达改善和优化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呢?!但这种方案要求用户有足够的银子~~~

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

论坛徽章:
0
5 [报告]
发表于 2009-10-21 10:24 |只看该作者
ODBC 是个很消耗系统资源的东东,一定要控制好

坛子里有很多朋友深受其害,呵呵

论坛徽章:
0
6 [报告]
发表于 2009-10-21 19:35 |只看该作者

回复 #4 qingzhou 的帖子

qingzhou也来了。。难得啊!支持一下!
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP