Solaris 10上更好的内存(堆)管理

Question

我已经通过Pro*C为Oracle编写了带有嵌入式SQL的C代码。

每当我执行insert或update (下面给出一个更新示例)时，

update TBL1 set COL1 = :v, . . . where rowid = :v

为了管理批量插入和更新，我分配了几个内存块作为批量插入并提交一次。在必要时，还会进行其他内存分配。如何更好地管理动态内存分配的内存(堆)？一种选择是让堆大小在GNU链接期间可配置。我使用的是g++版本2.95，我知道这是一个相当旧的版本，但必须将其用于遗留版本。由于obce构建的可执行文件(在Solaris10上运行)可以在具有不同资源的多个生产环境中运行，因此“一刀切”分配堆大小可能并不合适。作为替代方案，需要某种机制，在这种机制中，堆可以在需要时弹性增长。与Linux不同，我认为Solaris没有过度分配内存的概念。因此，如果没有更多的剩余空间，内存分配可能会因ENOMEM而失败。有什么更好的策略可以知道我们可能正在跨越危险级别，现在我们应该释放我们正在存储的块，以防这些块是使用完成的，或者将内存块传输到oracle DB，以防这些块仍然等待加载并最终释放。你有什么可以建议的策略吗？

Answer 1

C不是java，因为堆大小在启动时是固定的。

C编译的应用程序的堆和堆栈都共享相同的虚拟内存空间，并动态调整。

这个空间的大小取决于您正在编译的是32位还是64位二进制文件，也取决于您的内核是32位还是64位(在SPARC硬件上，它始终是64位)。

如果您没有足够的RAM，并且希望Solaris接受大的内存预留，这与Linux over提交内存的方式类似，您只需为预留添加足够的交换空间，以便由实际存储来支持。

如果由于某些原因，您对Solaris libc内存分配器不满意，您可以评估捆绑的替代内存分配器，如libumem、mtmalloc或第三方hoard。详情请参见http://www.oracle.com/technetwork/articles/servers-storage-dev/mem-alloc-1557798.html。

Answer 2

一种解决方案是在你的代码中使用软限制用于各种目的，f.e.一次只处理100个事务，而其他事务必须等待，直到先前的事务被释放。这保证了可预测的行为，因为任何代码部分都不能使用超过允许的内存。

问题是:您是否真的在应用程序中耗尽了内存，或者您是否将内存碎片化而无法获得足够大的连续内存块？处理每种情况的策略是不同的。