Solaris 10上更好的内存（堆）管理
我通过Pro * C为嵌入式SQL for Oracle提供了c代码。
每当我进行插入或更新时（下面给出更新示例），
update TBL1 set COL1 = :v, . . . where rowid = :v 为了管理批量插入和更新，我已经分配了几个内存块作为批量和提交一次插入。 在必要时，还会有其他内存分配。 如何更好地管理动态内存分配的内存（堆）？ 一种选择是在GNU链接时间内配置堆大小。 我使用g ++版本2.95，我知道它是一个相当旧的版本，但必须使用它来传统。 由于可执行文件（在solaris 10上运行），obce内置，可以在具有不同资源的多个生产环境上运行，因此用于堆大小分配的单一大小适合可能不合适。 作为替代方案，需要一些机制，其中堆可以在需要时弹性地生长。 与Linux不同，我认为，Solaris没有过度分配内存的概念。 因此，如果没有剩余空间，则内存分配可能会因ENOMEM而失败。 什么可能是更好的策略，知道我们可以跨越危险级别，现在我们应该释放我们正在存储的块，以防这些是使用或传输内存块到oracle DB完成的情况下，如果这些仍然有待加载，最后解除分配。 您可以建议的任何策略？
C不是启动时修复堆大小的java 。
C编译应用程序的堆和堆栈共享相同的虚拟内存空间并动态调整。
此空间的大小取决于您是编译32位还是64位二进制文件，以及您的内核是32位还是64位（在SPARC硬件上，它总是64位）。
如果你没有足够的RAM并希望Solaris无论如何都接受大容量内存预留，就像Linux提交内存一样，你可以添加足够的交换来保留实际存储。
如果由于某种原因，您对Solaris libc内存分配器不满意，则可以评估捆绑的备用库，例如libumem ， mtmalloc或第三方库。 有关详细信息，请参阅http://www.oracle.com/technetwork/articles/servers-storage-dev/mem-alloc-1557798.html 。
一种解决方案是在代码中使用软限制用于各种目的，即一次只处理100个事务，而其他事务必须等到前一个事务被释放。 这保证了可预测的行为，因为没有代码部分可以占用比允许的内存更多的内存。
问题是：你的应用程序中是否真的内存不足，或者你是否破坏了内存并且无法获得足够大的连续内存块？ 处理每个案件的策略是不同的。