Solaris 10 上更好的内存（堆）管理答案

【问题标题】：Better Memory (Heap) management on Solaris 10Solaris 10 上更好的内存（堆）管理
【发布时间】：2015-11-27 02:23:12
【问题描述】：

我有通过 Pro*C 为 Oracle 嵌入 SQL 的 c 代码。

每当我进行插入或更新时（下面给出更新示例），

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

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

【问题讨论】：

这不是讨论网站。如果您对代码有特定问题，请发帖minimal reproducible example。并选择一种语言。没有语言 C/C++；这是两种不同的语言。
感谢@Olaf，编辑了我的问题
您始终可以构建自己的内存分配器——它可能不是最简单的解决方案，但它是最可定制的。如果您有兴趣，IBM 有一个不错的教程 here。
我认为 gcc，正如你所写的那样，你有 C 代码。 g++ 通常是编译器 C++ 代码的名称。一个更好的主意是使用更新的编译器。这可能会给手工制作内存分配器带来更多的推动力。通常堆确实动态增长。不确定您认为要增强什么。你有没有看过当前分配器的操作？不过，我不认为问题是 OT。
@Olaf 我现在必须将 2.95.3 版本用于遗留生产代码，并且 g++ 正在使用，因为我们在整个软件中有几个 C++ 类以及一些 C 来管理 Pro* Oracle 嵌入式 SQL 的 C 部分

标签： c oracle memory memory-management solaris

【解决方案1】：

一种解决方案是在代码中为各种目的使用软限制，例如一次只处理 100 个事务，其他事务必须等到前一个事务被释放。这保证了可预测的行为，因为没有代码部分可以使用超过允许的内存。

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

【讨论】：

【解决方案2】：

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

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

此空间的大小取决于您是编译 32 位还是 64 位二进制文件，以及您的内核是 32 位还是 64 位（在 SPARC 硬件上，它始终是 64 位）。

如果您没有足够的 RAM 并且希望 Solaris 无论如何都接受大内存预留（类似于 Linux 过度提交内存的方式），您只需添加足够的交换空间以使预留空间得到实际存储的支持。

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

【讨论】：