2

我的 WAS 7.0 中有一个消息引擎集群。为我的应用程序的一项功能创建了一个队列，当我通过上传实用工具加载一些数据时正在使用该功能。在创建消息引擎时，创建了 3 个文件：1. 日志文件最大大小 100MB 2. TemporaryStore 最小大小 200MB 和最大大小 500MB 3. PermanentStore 最小大小 200MB 和最大大小 500MB

现在，当我大量加载数据时，PermanentStore 的大小已达到其最大限制，此时我收到异常：“异常 com.ibm.ws.sib.msgstore.TransactionException: com.ibm.ws.sib。 msgstore.PersistenceException：无法回滚批处理，因为它的状态不正确！State=STATE_ROLLEDBACK "

当我将 PermanentStore 的最大限制增加到 Unlimited 大小时，一切正常，但在这种情况下，PermanentStore 的大小在每次事务中都在增加，这使得该文件超过 2-3 GB，然后它会再次增加，这不是正确的方法。

有人请建议我如何将 PermanentStore 文件的大小保持在某个有限的值。

4

1 回答 1

0

我目前在一个环境中工作，我们曾经有多个消息传递引擎，混合使用文件存储和数据库支持的消息存储。该设计最初由 IBM 顾问完成。但是，配置了文件存储的消息传递引擎引起了很多问题，我们最终得出结论，它们缺乏关键任务生产使用所需的可靠性。我们最终消除了所有文件存储（除了一些非关键业务用例）并改为数据库支持的消息存储。

IBM 3 级支持的以下声明（作为对文件存储意外报告为已满的 PMR 的响应）可能会阐明您遇到的问题：

我怀疑观察到的问题与没有碎片整理过程的文件存储碎片有关，只有限制。所描述的测试中的消息传递模式正是可以导致文件存储变满并且尽管
PM10591 仍无法恢复的模式。

本质上，问题是由于日志文件的整个大小需要能够连续地适合存储文件的要求。在正常情况下，这个连续的可用空间（从不使用但必须存在）位于存储文件的末尾，例如：

0...消息数据...400Mb ....可用连续空间...500Mb

当存储文件已满时，这意味着存储文件中没有足够的连续可用空间来容纳日志文件。想象一下，您已经用消息数据填充了 0 到 400Mb 的文件，然后消费了 0 到 200 Mb 的消息数据（耗尽了 MDB 输入队列，但系统异常目标仍然是满的）。因为存储文件本质上是一个文件系统本身，并且节点和目录元数据存储在文件中的可变位置，所以 0 到 200Mb 的存储区域并不是一个连续的空闲空间，因为您已经消费了消息数据。而是以随机间隔存在少量元数据。所以总共有 300Mb 的可用空间，但没有一个连续的 100Mb 块可以存放日志。这是目前没有碎片整理解决方案的问题。

通常使用来自所有队列的消息数据将释放重要的几个字节以在存储文件的末尾重新创建空闲的连续空闲空间。即在异常目的地消费消息数据（这比消费第一个队列中的消息数据来填充更有用）

这个问题的完整解决方案是不要遇到存储满的情况。了解所需最大值的唯一方法是使用消息的最大可能大小将所有队列填充到其配置的限制，然后查看需要什么大小的存储文件。或者您可以将文件存储配置为具有无限大小。

在 v7 中进行了一些更改以尝试抵抗碎片，但再次没有碎片整理程序。这是因为在线碎片整理会非常昂贵，而这个问题的真正解决方案是确保有足够的可用空间来包含在最坏情况下预期的所有消息数据。

这在实践中意味着存在特定的使用模式，其中永久存储需要比基于实际存储的消息的数量和大小所期望的空间大得多的空间。显然，这使得规划文件存储的存储需求基本上是不可能的。

于 2012-11-15T15:00:41.500 回答