< add name =“DB2”connectionString =“ConnectionTimeout = 45; Pooling = true; MinimumPoolSize = 1; MaximumPoolSize = -1; MaximumUseCount = 100; CheckConnectionOnOpen = true; DataSource = XXX; Naming = sql; DataCompression = True; UserID = username; password = pwd; DefaultCollection = XXX“/>
自从进入2008R2以来,iSeries的连接数量(QZDASOINIT作业)稳步增加,从而伤害了iSeries和我们的应用程序的性能.代码库与2008年32位服务器上的代码基本完全相同.我们为Any cpu设置了目标平台,并在IIS中将“启用32位应用程序”设置为True.我们试图在本月早些时候升级到这些服务器,重置IIS并没有自动杀死盒子上的连接,因为它应该是这样,不会创建任何新的连接,直到我们完全恢复到旧的服务器.
几乎看起来它并没有拾起已经建立的连接并且不断创建新的连接.有人知道如果在使用iSeries进行连接池升级到32位到64位时,我们错过了一个步骤？
解决方法
有关QZDASOINIT作业的一些相关内容…默认情况下,这些作业是在子系统QUSRWRK中创建的(尽管如果在请求ODBC连接时QUSRWRK子系统不活动,它们也可以在QSYSWRK和QSERVER中进行裁剪). QUSRWRK配置为在子系统启动后立即创建其中一个QZDASOINIT作业.如果做出了ODBC请求,并且没有QZDASOINIT作业可用,还会再启动另外两个QZDASOINIT作业.每个QZDASOINIT作业将在结束之前处理200个ODBC请求.所有这些默认值和更多可以使用CHGPJE或CHGSBSD命令进行更改.
QZDASOINIT作业有一个或两个“类”.这些工作的执行可以使用这些类进行微调.
您可以使用DSPACTPJ命令找到有关当前活动的QZDASOINIT作业的信息.
资源：
CHGPJE – Change Prestart Job Entry
CHGSBSD – Change Subsystem Description
DSPACTPJ – Display Active Prestart Jobs
Performance considerations with QZDASOINIT jobs
可能的“解决方案”#1：
在Windows端的连接字符串中,将MaximumPoolSize = -1更改为MaximumPoolSize = XXX,其中XXX是允许您的ASP.NET应用程序运行良好但不降低IBM i性能的某个数字.我建议使用2,000,因为当应用程序在32位服务器上运行时,似乎是可以忍受的.
可能的“解决方案”#2：
让IBM i管理员在IBM i上进行一些更改 – 由于您知道服务器场的IP地址范围,管理员可以设置一个新的子系统,只能为应用程序ODBC连接提供服务.
使用CHGPJE命令更改允许的QZDASOINIT作业的最大数量 – 再次建议从2,000开始,并根据需要进行调整,以满足应用程序对IBM i的性能和影响.如果需要,管理员可以设置一个任务,将终止新子系统中的所有QZDASOINIT作业 – 通过结束该子系统(ENDSBS)或ENDHOSTSVR SERVER(* DATABASE)ENDACTCNN(* DATABASE)(我将结束子系统,但是您的管理员会知道在你的环境中最好的工作).
一些其他建议,不是解决方案本身,但可能有帮助：
限制ASP.NET应用程序中并发执行线程的数量.显然不是一个快速或容易的事情要做,但要放在应用程序的下一次迭代的笔记中.
更改MaximumUseCount = 100以匹配您使用QZDASOINIT作业的任何用户数.
