IBM i 上的某核心应用突然挂起,不能为前端应用提供数据服务了,经检查发现日志多次报 MCH2804 消息。
MCH2804 的字面含义是“试图超过目标对象 &1 的存储限制。”这里的“目标对象 &1 ”代表某个 user profile
,也就是说,试图超过某个 user profile 的存储限制。
这个 user profile 定义中的 MAXSTG 参数已经是 *nomax 了,怎么会超过这个 user profile 的存储限制呢?
原来 MCH2804 消息与 user profile 的极限值有关系,虽然 user profile 中的 MAXSTG 被设置为 *NOMAX ,但日志中还会报 MCH2804 , MAXSTG 定义了这个 user profile 所拥有的 object 能占用的存储空间的大小,而操作系统中的 user profile 最大支持的 entry 数目是有限制的,不能超过系统规定的极限值,这是系统报 MCH2804 的真正原因。下表列出了不同 IBM i 版本中 user profile 所能支持 entry 数量的极限值。
User Profile最大条entry | User Profile对于iASP的支持 最大entry数目 | |
V4R3M0 | 1,048,574 | |
V4R4M0 | 5,000,000 | |
V5R1M0 | 5,000,000 | 5,000,000 |
V5R2M0 | 10,000,000 | 10,000,000 |
V6R1M0 | 50,000,000 | 50,000,000 |
V7R1M0 | 50,000,000 | 50,000,000 |
V7R2M0 | 50,000,000 | 50,000,000 |
V7R3M0 | 50,000,000 | 50,000,000 |
V7R4M0 | 50,000,000 | 50,000,000 |
客户一定会关心哪些 Object 会被记录到 user profile 的 entry 条目。
数据库文件由多个 MI object 组成,这些 MI object 被保存到 user profile 的条目中,例如,一个 FILE object 至少有三个对象被保存到 user profile 的条目;一个用于文件目标,两个用于文件的每个 Member (成员)。如果在文件上建立一个索引,那么文件中的每个成员还都会有增加一个额外的条目。一个有 100 个成员的文件将至少有 201 个目标占用条目,如果在文件上建立了索引,还会有 100 个条目。还有一些额外的内部目标也可能与该文件相关联,如果这个文件有私有权限,那么每个 MI 对象都有一个私有权限(不仅仅是外部 FILE 对象)。给数据库文件授予私有权限可能会导致拥有者 User Profile 中的条目迅速增长,这也是导致 User Profile 爆表的主要原因。
可以通过 WOKOBJPVT 命令查看某个 User Profile 对 object 的私有权限。
每个 User Profile 都有两个存放上述信息的库 (repository) 。一个库是 machine index ,用于快速访问定位条目,另一个是用于永久存放条目的表( table ),该表主要用于重建索引,这是因为 machine index 在系统崩溃后可能会被损坏。 Machine index 和 space 目标会随着 authority 、 primary group authority 和所有权权限被添加到 user profile 中而分配存储空间,这些空间对象的存储会根据需要进行扩展。
一个 user profile 的物理大小限制约为 48MB ,表为 16MB ,索引可以根据需要增长,以容纳 1 , 048,574 个条目。当表被占满时,索引通常在 32MB 左右。
如果 user profile 的空间被占满了之后,我们可以通过以下两种方法来解决:
例如可以用 DSPUSRPRF USRPRF(XIAOQING) TYPE(*OBJOWN) 命令显示某用户所拥有的 object 的名称和数量。
用 CHGOBJOWN 命令将 object 的所有权限转移到另一个用户 , 例如 :
当权限和所有权从 user profile 中被删除时,这些 entry 同时被删除,并生成自由空间, free entry 可被立即重用,该空间被适合的相同逻辑空间中的相似条目所使用。
索引和表中被释放的 entry 将随着时间的推移被删除;另外当达到大小极限时,表和索引被压缩;在系统 IPL 和 reclaim storage 时,也会被压缩。
User profile 的索引空间和表空间不会被自动重建,只在损坏或不同步时才会被重建,正常的 IPL 或异常的 IPL 不会自动重建 user profile 。
最后,有人可能会问, IBM i 对 User profile 的这个极限值有没有预警信息可以参考?回答时肯定的,目前系统提供两种方法。
方法 1 :通过 PRTPRFINT 命令列出每个 user profile 的 entry 使用情况,单位时百分比。
方法 2 :通过 AUINTERNALS 宏来分析每个 user profile 在 SYSASP 和其他 iASP 中的的 entry 使用情况,这种方法提供的信息更为详细。
使用这个方法之前,需要安装补丁。
v7r2m0: MF68098 (pre-reqs MF68059)
v7r3m0: MF68099 (pre-reqs MF68060)
v7r4m0: MF68101
在 vlog 中会提供报警信息 0B00 3009 。
当 user profile 的空间使用了 90% 的时候,系统就会自动报 VLOG 0B00 3009 ,提示 user profile 的名称、 iASP 和当前 entry 的使用数量。
这里的“ 02F00000 ”是十六进制数,代表 entry 的数量( 49283072 ),“ E3C5E2E3D7D9C6F1 ”是 TESTPRF1 user profile , ASP NUMBER 是“ 23 ”, 35 ASP 。
同时,可以进入 SST 查看更详细的信息,如 entry 的准确数目、使用的百分比、拥有的目标对象数量、授权对象数量
、授权用户数量等信息。
具体方法如下:
这里的 90 代表 90% ,即列出 entry 数超过 90% 的 user profile 等信息。
总之,每个系统都会有自己的极限值, IBM i 也不例外,没有必要大惊小怪,事实证明采用上述两种解决方法和对 user profile 的 entry 值的两种预警检测方法,可以有效地预防和避免这个问题的发生。
参考文档:
“ User Profile Size Limit/Limit of Pointers to Objects Owned by a User Profile ”
谢谢阅读,仅供参考。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞3
添加新评论0 条评论