Solaris 10上更好的内存(堆)管理 [英] Better Memory (Heap) management on Solaris 10
问题描述
我通过Pro * C拥有带有用于Oracle的嵌入式SQL的C代码.
每当我进行插入或更新时(在下面给出一个更新示例)，
update TBL1 set COL1 = :v, . . . where rowid = :v
要管理大容量插入和更新，我分配了几个内存块以大容量插入并提交一次.在必要时还会进行其他内存分配.如何更好地管理内存(堆)以进行动态内存分配?一种选择是在GNU链接期间配置堆大小.我使用的是g ++版本2.95，我知道它是一个很旧的版本，但是必须将其用于旧版本.由于可执行文件(在solaris 10上运行)，建于某处，可以在具有不同资源的多个生产环境上运行，因此不适合一堆大小地分配堆大小.作为替代方案，需要某种机制，在需要时堆可以弹性增长.我认为，与Linux不同，Solaris没有过度分配内存的概念.因此，如果没有剩余空间，内存分配可能会因ENOMEM而失败.有什么更好的策略可以知道我们可能会越过危险级别，现在，如果使用存储块，则应该对其进行分配，或者将存储块转移至oracle DB，以防这些块仍在等待加载，最后再进行存储.解除分配.您有什么建议的策略吗?
C不是java，在启动时堆大小是固定的.
C编译的应用程序的堆和堆栈都共享相同的虚拟内存空间，并且可以动态调整.
此空间的大小取决于您要编译的是32位还是64位的二进制文件，还取决于内核是32位还是64位的内核(在SPARC硬件上，它始终为64位).
如果您没有足够的RAM，并且无论如何要Solaris接受大内存保留，这与Linux over提交内存的类似方式，您可以添加足够的交换空间以使保留由实际存储支持.
如果由于某种原因对Solaris libc内存分配器不满意，则可以评估捆绑的替代项，例如 hoard .请参阅 http://www.oracle.com/详情请参阅technetwork/articles/servers-storage-dev/mem-alloc-1557798.html .
I have c code with embedded SQL for Oracle through Pro*C.
Whenever I do an insert or update (below given an update example),
update TBL1 set COL1 = :v, . . . where rowid = :v
To manage bulk insertions and updates, I have allocated several memory chunks to insert as bulk and commit once. There are other memory allocations too going on as and when necessary. How do I better manage the memory (heap) for dynamic memory allocations? One option is to have the heap size configurable during the GNU linking time. I'm using g++ version 2.95, I know it's quite an old version, but have to use this for legacy. Since the executable (runs on solaris 10), obce built, could run on several production environments with varied resources, one-size-fit-all for heap size allocation may not be appropriate. As an alternative, need some mechanism where heaps may elastically grow as and when needed. Unlike Linux, Solaris, I think, does not have the concept of over-allocated memory. So, memory allocations could fail with ENOMEM if there is no more space left. What could be better strategy to know that we could be crossing the danger level and now we should either deallocate chunks that we are storing in case these are done using or transfer memory chunks to oracle DB in case these are still pending to be loaded and finally deallocate. Any strategy that you could suggest?
C is not java where the heap size is fixed at startup.
The heap and the stack of a C compiled application both share the same virtual memory space and adjust dynamically.
The size of this space depends on whether you are compiling a 32 bit or a 64 bit binary, and also whether your kernel is a 32 bit or a 64 bit one (on SPARC hardware, it's always 64 bit).
If you have not enough RAM and want Solaris to accept large memory reservations anyway, a similar way Linux over commits memory, you can just add enough swap for the reservation to be backed by actual storage.
If for some reason, you are unhappy with the Solaris libc memory allocator, you can evaluate the bundled alternative ones like libumem, mtmalloc or the third party hoard. See http://www.oracle.com/technetwork/articles/servers-storage-dev/mem-alloc-1557798.html for details.
这篇关于Solaris 10上更好的内存(堆)管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
