IBM MQ 学习 03：资源限制修正、队列管理器状态与 FDC 边界
文章目录8 节
第二章安装完成后，QM1 能启动、Q1.LEARN 能完成 put/get，但启动时留下了一个问题：RLIMIT_NOFILE 偏低。这个问题不影响学习环境继续跑通，但它会影响我们对环境健康状态的判断，所以这一章先把它修正掉。
这一章的重点不是背参数，而是建立一个判断顺序：先看当前用户资源限制，再看队列管理器状态，再看队列状态和消息流，最后结合错误日志和 FDC 判断是否还有当前故障。
修正资源限制
本次实际写入了两类配置。
系统级内核参数：
/etc/sysctl.d/99-ibm-mq.conf
fs.file-max = 524288
kernel.threads-max = 32768mqm 用户级限制：
/etc/security/limits.d/99-ibm-mq.conf
mqm soft nofile 10240
mqm hard nofile 10240
mqm soft nproc 4096
mqm hard nproc 4096这里要注意一个边界：sysctl 处理系统级参数，limits.d 处理登录会话中的用户级限制。修改 limits.d 后，需要重新进入 su - mqm，新会话才会拿到新限制。
在 mqm 用户下验证
这一批命令的目的，是证明我们检查的是实际管理队列管理器的 mqm 用户，而不是 root 用户。
# 切换到 mqm 用户，使用 MQ 管理上下文
su - mqm
# 确认当前用户身份
id
# 检查当前会话的 soft nofile 限制
ulimit -Sn
# 检查当前会话的 hard nofile 限制
ulimit -Hn
# 用 IBM MQ 自带工具检查系统和当前用户限制
/opt/mqm/bin/mqconfig实际验证结果：
mqm@IBM_MQ_01:~> id
uid=483(mqm) gid=1000(mqm) 组=1000(mqm)
mqm@IBM_MQ_01:~> ulimit -Sn
10240
mqm@IBM_MQ_01:~> ulimit -Hn
10240mqconfig 的关键输出：
System Settings
file-max 3328 of 524288 files (0%) IBM>=524288 PASS
pid_max 342 of 32768 processids (1%) IBM>=32768 PASS
threads-max 342 of 29558 threads (1%) IBM>=32768 WARN
Current User Limits (mqm)
nofile (-Hn) 10240 files IBM>=10240 PASS
nofile (-Sn) 10240 files IBM>=10240 PASS
nproc (-Hu) 128 of 4096 processes (3%) IBM>=4096 PASS
nproc (-Su) 128 of 4096 processes (3%) IBM>=4096 PASS结论：mqm 用户的 nofile 和 nproc 已达到当前 IBM MQ 检查脚本给出的建议值，系统级 file-max 也已经通过。threads-max 仍然是 WARN，学习环境可以继续；生产环境需要结合内存、内核和实际负载另做评估。
root 结果为什么不能替代 mqm
我一开始也看到了 root 下的 mqconfig 结果：
Current User Limits (root)
nofile (-Hn) 4096 files IBM>=10240 FAIL
nofile (-Sn) 1024 files IBM>=10240 FAIL这个结果不代表 mqm 修正失败。mqconfig 会检查当前运行命令的用户限制；如果用 root 执行，它看到的就是 root 的限制。当前学习环境中，队列管理器由 mqm 管理，所以更关键的是 mqm 会话里的检查结果。
同样，root 下执行 MQSC 管理命令也可能失败：
AMQ8135E: Not authorized.这说明后续做队列管理器管理、MQSC 查询和 mqconfig 验证时，默认应该先进入 su - mqm。
检查 QM1 运行状态
资源限制修正后，先看队列管理器是否还在运行。
# 查看队列管理器列表和运行状态
dspmq
# 通过 MQSC 查看队列管理器运行状态
echo "DISPLAY QMSTATUS" | runmqsc QM1实际输出：
mqm@IBM_MQ_01:~> dspmq
QMNAME(QM1) STATUS(正在运行)mqm@IBM_MQ_01:~> echo "DISPLAY QMSTATUS" | runmqsc QM1
AMQ8705I: 显示队列管理器状态详细信息。
QMNAME(QM1) STATUS(RUNNING)这里顺便修正一个容易混淆的点：DISPLAY QMGR 查询的是队列管理器配置属性，DISPLAY QMSTATUS 查询的是运行状态。STATUS 不是 DISPLAY QMGR 的有效属性。
检查学习队列状态
接着看 Q1.LEARN 这个本地队列是否有消息积压，是否还有样例程序挂着没有退出。
# 查看本地队列深度和当前打开队列的输入/输出进程数
echo "DISPLAY QLOCAL(Q1.LEARN) CURDEPTH IPPROCS OPPROCS" | runmqsc QM1实际输出：
AMQ8409I: 显示队列细节。
QUEUE(Q1.LEARN) TYPE(QLOCAL)
CURDEPTH(0) IPPROCS(0)
OPPROCS(0)这三个字段的含义很直接：
CURDEPTH(0)：当前没有积压消息。IPPROCS(0)：当前没有进程以输入方式打开队列。OPPROCS(0)：当前没有进程以输出方式打开队列。
这不能证明所有业务都正常，但它能证明当前学习队列是干净的，没有积压，也没有样例程序挂着。
修正后再跑一次消息流
资源限制修正后，我们又做了一次最小 put/get 健康检查。
# 放入一条健康检查消息
echo "health check after limits fix" | /opt/mqm/samp/bin/amqsput Q1.LEARN QM1
# 查看放入消息后的队列深度
echo "DISPLAY QLOCAL(Q1.LEARN) CURDEPTH" | runmqsc QM1
# 从队列取出消息
/opt/mqm/samp/bin/amqsget Q1.LEARN QM1
# 查看取出消息后的队列深度
echo "DISPLAY QLOCAL(Q1.LEARN) CURDEPTH" | runmqsc QM1关键输出：
Sample AMQSPUT0 start
target queue is Q1.LEARN
Sample AMQSPUT0 end
CURDEPTH(1)Sample AMQSGET0 start
message <health check after limits fix>
CURDEPTH(0)结论：修正资源限制后，QM1 仍然可以完成本地消息放入和取出，队列最终回到空队列状态。
FDC 怎么看
本章中还发现过一个历史 FDC：
/var/mqm/errors/AMQ10554.0.FDC关键字段：
Probe Id: ZX000065
Component: zxcExecutionController
Program: amqzxma0
QueueManager: QM1
Major Errorcode: xecL_W_PERFORMANCE_BOTTLENECK错误日志里也能看到对应记录：
AMQ6125E: 发生了内部 IBM MQ 错误。
AMQ6184W: 在队列管理器 QM1 上发生了内部 IBM MQ 错误。这类文件不能只按“有 FDC 就一定还有故障”来判断。我们这次的判断依据是：
- FDC 产生在资源限制修正之前。
- 修正后
QM1正在运行。 DISPLAY QMSTATUS返回STATUS(RUNNING)。Q1.LEARN队列状态正常。- 修正后消息 put/get 复测通过。
- 没有新的同类 FDC 证据。
所以这份 FDC 当前按历史残留处理，不作为当前阻塞。以后排查 FDC，要同时看时间线、Probe Id、错误日志、队列管理器当前状态和复测结果。
本章小结
这一章把第 2 章遗留的资源限制问题补齐了，也顺手建立了更完整的 MQ 健康检查思路。
- 已验证：
mqm用户下nofile和nproc通过，系统级file-max通过；QM1运行，Q1.LEARN无积压，修正后消息流正常。 - 环境改变：新增 IBM MQ 相关系统级和
mqm用户级资源限制配置。 - 关键概念：MQ 健康检查要分层看，用户上下文、队列管理器状态、队列状态、消息流和错误日志不能混在一起判断。
- 要记住的坑：
root下mqconfig的nofile FAIL不等于mqm没修好；DISPLAY QMGR和DISPLAY QMSTATUS不是一回事；FDC 要结合时间线和复测结果判断。 - 下一步：进入 listener、SVRCONN 通道和客户端连接，让第二台机器参与实验。