应用程序服务器 CPU 达到 >80 并在近 24 小时后挂起 同样的问题每天都在重复

Posted 2023-02-25

【中文标题】应用程序服务器 CPU 达到 >80 并在近 24 小时后挂起 同样的问题每天都在重复

【英文标题】：application server CPU go to >80 and hang after nearly 24 hour the same problem repeats every day

【发布时间】：2021-03-21 20:55:13

【问题描述】：

我有 IBM WebSphere Application 8.5 服务器与 Db2 11.1 一起工作 2 年。由于应用程序服务器挂起一个月，dB CPU 变为 0 并且应用程序服务器 CPU 变为 >80 ，并且在近 24 小时后挂起，同样的问题每天都在重复。应用服务器上的日志

db2diag 今天出错了 2020-12-09-10.03.24.732486+120 I1234525159E610 级别：错误 PID：5737 TID：139739072030464 PROC：db2sysc 0 实例：db2inst1 节点：000 数据库：WPJCR APPHDL : 0-38161 APPID: ::ffff:x.42258.201209075007 UOWID：199 ACTID：1 AUTHID：DB2INST1 主机名：ERTUWCMDB1Az EDUID：1760 EDUNAME：db2agent（WPJCR）0 FUNCTION：DB2 UDB，普通通信，sqlcctest，probe:50 消息：sqlcctest RC 数据 #1：十六进制转储，2 个字节 0x00007F1789BFCDE0：3600 6.

2020-12-09-10.03.24.732661+120 I1234525770E601 级别：错误 PID：5737 TID：139739072030464 PROC：db2sysc 0 实例：db2inst1 节点：000 数据库：WPJCR APPHDL : 0-38161 APPID: ::ffff:x.42258.201209075007 UOWID：199 ACTID：1 AUTHID：DB2INST1 主机名：ERTUWCMDB1Az EDUID：1760 EDUNAME：db2agent（WPJCR）0 功能：DB2 UDB，基本系统实用程序，sqeAgent::AgentBreathingPoint，探针：10 CALLED : DB2 UDB，通用通信，sqlcctest RETCODE：ZRC=0x00000036=54

[11/3/20 6:42:13:596 EET] 000006ad XATransaction E J2CA0027E: 一个 在 XA 资源适配器上调用回滚时发生异常 来自数据源 jdbc/wpjcrdbDS，在事务 ID XidImpl: formatId(57415344), gtrid_length(36), bqual_length(54),

数据（000001758C648AA700800F8C220C5F6BDAB92156A760BY31E28A7605ADE8000001558C28CAICH925C220C500CH921550000WA-A760C550000W000000000000 ：com.ibm.db2.jcc.am.XaException：[jcc][t4][2041][12326][4.25.13] 执行 XAResource.rollback() 时出错。服务器返回 XAER_NOTA。 ERRORCODE=-4203, SQLSTATE=null

一段时间后，dB CPU 变为 0，应用服务器 CPU 变为 >80，并在近 24 小时后挂起，同样的问题重复出现。

这是由于数据损坏导致的死锁或锁定超时吗？？

【问题讨论】：

请仔细检查 Db2 诊断文件（例如 db2diag.log）和 Db2 服务器上的 Db 通知日志。如果有死锁或超时，他们会在那里被提及。您的问题不是关于编程，而是关于疑难解答，为此，您需要有能力的人知道如何阅读和理解日志文件。确定一个月前发生了什么变化也很有帮助。

我更新了今天添加 dB2 诊断的帖子，有 2 个错误

级别：错误 PID：5737 TID：139739072030464 PROC：db2sysc 0 WPJCR APPHDL：0-38161 APPID：UOWID：199 ACTID：1 AUTHID：DB2INST1 HOSTNAME：ERTUWCMDB1Az EDUID：1 0 FUNCTION: DB2 UDB, common communication, sqlcctest, probe:50 MESSAGE: sqlcctest RC DATA #1: Hexdump, 2 bytes 0x00007F1789BFCDE0: 3600 6.

欢迎来到 SO。请在发布之前花点时间正确格式化您的问题。

这可能与 DB2 比 WAS 更相关，但链接到 WAS 性能调试：ibm.com/support/pages/node/72419 这有助于您收集 WAS 进程的线程转储。告知哪些 WAS 线程使用的 CPU 最多，以及是否存在死锁。在 Windows 上，使用 Jython 脚本收集线程转储： 将以下内容放入名为 ThirtyThreadDumps.py 的文件中（用正确的服务器名称替换“server1”）： jvm = AdminControl.completeObjectName('type=JVM,process=server1 ,*') for x in range(30): AdminControl.invoke(jvm, 'dumpThreads') Sleep(30)

【参考方案1】：

在没有看到任何其他应用服务器日志的情况下，您注意到这一点的组合

“近 24 小时问题不断重复” sqeAgent::AgentBreathingPoint 错误（请参阅 IBM 技术说明 https://www.ibm.com/support/pages/what-does-agentbreathingpoint-error-mean-db2 了解更多信息） “从 2 年开始工作。自一个月以来，应用程序服务器挂起”

会引导我寻找最近设置了连接超时的网络变化，24 小时后关闭连接。这可能是由于更换路由器或升级设置不同的固件造成的。这是否每天大约在同一时间发生？如果是，它是否发生在应用程序从安静状态（如过夜）到忙碌状态（如工作日开始）时？ 根据您的回答，听起来整个连接池在一夜之间变得“陈旧”，这意味着连接没有被使用并且网络超时导致它们与数据库服务器断开连接。您可以尝试将“最小连接数”的 WAS 数据源设置更改为 0，将“未使用超时”更改为 12 小时。当服务器流量停止时，这将允许连接池在一夜之间耗尽。随着应用程序在早上开始加载，将获得新的连接，从而避免错误。如果您的“最大连接数”设置非常大，当连接池被填满时，您可能会遇到一些缓慢。

【讨论】：

这发生在每天大约同一时间，每天移动 +1 到 +2 小时，所以它每天移动的时间不同。是的，它从安静状态开始到忙碌状态