为什么连接没有在我的 iSeries/ASP.NET MVC 4 应用程序中重用？

我们正在 Windows 2008 服务器场上运行 MVC 4 Web 应用程序。我们一直在尝试将服务器场升级到 Windows 2008 R2 64 位服务器，但在 iSeries（运行 V7R1）上遇到了连接池问题。我们经常调用 DB2 java 存储过程，并启用连接池来减少建立连接所需的时间。下面是我们正在使用的连接字符串的示例。

<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 以及我们的应用程序的性能。代码库是exactly与 2008 年 32 位服务器上的情况相同。我们将目标平台设置为“任何 CPU”，并将 IIS 中的“启用 32 位应用程序”设置为 True。我们在本月早些时候尝试升级到这些服务器，重置 IIS 并没有像预期那样自动终止盒子上的连接，并且在我们完全恢复到旧服务器之前不会创建任何新连接。

看起来它似乎并没有建立已经建立的联系并不断创建新的联系。有谁知道在 iSeries 连接池升级到 32 位到 64 位时我们是否错过了一个步骤？

问题回顾：将 ASP.NET MVC 4 Web 应用程序从 32 位 Windows 2008 服务器场移动到 Windows 2008 R2 64 位服务器时，QZDASOINITIBM i 创造的就业机会从约 2,000 个跃升至约 200,000 个。代码库没有改变，唯一改变的是执行环境。

一些相关的事情需要了解QZDASOINIT作业...默认情况下，这些作业是在子系统中创建的QUSRWRK（尽管它们也可能出现在QSYSWRK and QSERVER if the QUSRWRK当请求 ODBC 连接时子系统不活动）。QUSRWRK配置为创建其中之一QZDASOINIT子系统一启动就开始工作。如果发出 ODBC 请求但没有QZDASOINIT职位空缺，还有2个QZDASOINIT工作将开始。每个QZDASOINIT作业在结束之前将处理 200 个 ODBC 请求。所有这些默认值以及更多内容都可以使用以下命令进行更改CHGPJE or CHGSBSD命令。

QZDASOINIT工作有一个或两个“类别”。可以使用这些类来微调这些作业的执行。

您可以找到有关您当前活跃的信息QZDASOINIT工作通过使用DSPACTPJ命令。

资源：

CHGPJE – 更改预启动作业条目 http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fcl%2Fchgpje.htm

CHGSBSD – 更改子系统描述 http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fcl%2Fchgsbsd.htm

CRTCLS – 创建类 http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fcl%2Fcrtcls.htm

DSPACTPJ – 显示活动的预启动作业 http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fcl%2Fdspactpj.htm

ENHOSTSVR – 终端主机服务器 http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fcl%2Fendhostsvr.htm

ENDSBS – 末端子系统 http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fcl%2Fendsbs.htm

WRKCLS – 与类一起工作 http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fcl%2Fwrkcls.htm

QZDASOINIT 作业的性能注意事项 http://www.linkedin.com/groups/Performance-considerations-QZDASOINIT-jobs-59314.S.123804107

可能的“解决方案”#1：

在 Windows 端的连接字符串中，更改MaximumPoolSize=-1 to MaximumPoolSize=XXX其中 XXX 是一些数字，它允许 ASP.NET 应用程序正常运行，但不会降低 IBM i 上的性能。我建议使用 2,000，因为当应用程序在 32 位服务器上运行时，这似乎是可以忍受的。

可能的“解决方案”#2：

让 IBM i 管理员对 IBM i 进行一些更改 - 因为您知道服务器场的 IP 地址范围，所以管理员可以设置一个新的子系统，该子系统除了为您的应用程序 ODBC 连接提供服务外什么也不做。 更改允许的最大数量QZDASOINIT工作使用CHGPJE命令 – 再次，我建议从 2,000 开始，并根据需要进行调整，以满足应用程序的性能和对 IBM i 的影响。如果有必要，管理员可以设置一个作业来杀死所有QZDASOINIT新子系统中的作业 – 通过结束该子系统 (ENDSBS) 或ENDHOSTSVR SERVER(*DATABASE) ENDACTCNN(*DATABASE)（我会终止该子系统，但您的管理员会知道什么最适合您的环境）。

其他一些建议本身不是解决方案，但可能会有所帮助：

限制 ASP.NET 应用程序中并发执行的线程数。显然这不是一件快速或容易的事情，而是要在应用程序的下一次迭代的注释中添加一些内容。

改变MaximumUseCount=100匹配您使用的任何使用计数QZDASOINIT jobs.

我在“解决方案”周围加上引号，因为虽然它们可能允许您将应用程序迁移到新环境，但它们实际上并不能解决问题。