分配的内存在Solaris / Linux操作系统释放 [英] Freeing of allocated memory in Solaris/Linux
问题描述
我已经写了一个小程序，并在Solaris / Linux操作系统平台编译它来衡量应用此code到我的应用程序的性能。
I have written a small program and compiled it under Solaris/Linux platform to measure the performance of applying this code to my application.
该计划是用这样的方式，开始使用 SBRK（0）堆区系统调用，我已经采取的基址。从那以后，我已经使用的malloc 系统调用分配的内存1.5 GB，然后我用一个的memcpy 系统调用拷贝1.5 GB的内容所分配的内存区域。然后，我释放分配的内存。
The program is written in such a way, initially using a sbrk(0) system call, I have taken base address of the heap region. After that I have allocated 1.5 GB of memory using a malloc system call, Then I used a memcpy system call to copy 1.5 GB of content to the allocated memory area. Then, I freed the allocated memory.
释放后，我用了 SBRK（0）系统调用再次查看堆大小。
After freeing, I used the sbrk(0) system call again to view the heap size.
这是我变得有点困惑。在Solaris中，尽管我释放分配（近1.5 GB）内存，进程的堆大小是巨大的。不过，我在Linux中运行相同的应用程序，释放后，我发现这个过程的堆大小等于1.5 GB的分配前的堆内存的大小。
This is where I get a little confused. In Solaris, even though I freed the memory allocated (nearly 1.5 GB), the heap size of the process is huge. But I run the same application in Linux, after freeing, I found that the heap size of the process is equal to the size of the heap memory before allocation of 1.5 GB.
我知道的Solaris不能立即做免费的内存，但我不知道如何调整Solaris内核立即释放免费（）系统调用后的内存。
I know Solaris does not free memory immediately, but I don't know how to tune the Solaris kernel to immediately free the memory after the free() system call.
我为什么不能在Linux下同样的问题？
Why don't I have the same problem under Linux?
推荐答案
我得到了答案，我问的问题。
I got the answer for the question that i have asked.
应用程序的内存分配：
C和C ++开发人员必须手动管理内存分配和释放内存。默认的内存分配器是在libc库。
C and C++ developers must manually manage memory allocation and free memory. The default memory allocator is in the libc library.
libc库
注意，自由（）被执行之后，释放的空间是由应用程序提供用于进一步分配，而不是返回到系统。存储器被返回到系统只有当在应用程序终止。这就是为什么该应用程序的进程大小平时从不降低。但对于长期运行的应用程序，则应用程序大小通常保持在一个稳定的状态，因为释放的存储器可以再利用。如果不是这种情况，则很可能该应用程序正在泄漏存储器，即，分配的内存使用，但在使用时不再和指针到分配的存储器不是由应用程序基本失去跟踪永远不会被释放。
Libc Note that after free()is executed, the freed space is made available for further allocation by the application and not returned to the system. Memory is returned to the system only when the application terminates. That's why the application's process size usually never decreases. But for a long-running application, the application process size usually remains in a stable state because the freed memory can be reused. If this is not the case, then most likely the application is leaking memory, that is, allocated memory is used but never freed when no longer in use and the pointer to the allocated memory is not tracked by the application—basically lost.
在libc中默认的内存分配器是不适合多线程应用程序时并发的malloc或自由操作频繁发生，尤其是对多线程的C ++应用程序。这是因为创建和销毁C ++对象是C ++应用程序开发风格的一部分。当使用的libc分配器的默认情况下，堆是由单个堆锁因的malloc或免费的操作过程中重锁竞争的保护，导致默认的分配不具有可扩展性的多线程应用程序。这很容易检测到这个问题了Solaris的工具，如下所示。
The default memory allocator in libc is not good for multi-threaded applications when a concurrent malloc or free operation occurs frequently, especially for multi-threaded C++ applications. This is because creating and destroying C++ objects is part of C++ application development style. When the default libc allocator is used, the heap is protected by a single heap-lock, causing the default allocator not to be scalable for multi-threaded applications due to heavy lock contentions during malloc or free operations. It's easy to detect this problem with Solaris tools, as follows.
首先，使用的prstat -mL -p以查看是否该应用程序花费上的锁多少时间;看LCK列。例如：
First, use prstat -mL -p to see if the application spends much time on locks; look at the LCK column. For example:
-bash-3.2# prstat -mL -p 14052
PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID
14052 root 0.6 0.7 0.0 0.0 0.0 35 0.0 64 245 13 841 0 test_vector_/721
14052 root 1.0 0.0 0.0 0.0 0.0 35 0.0 64 287 5 731 0 test_vector_/941
14052 root 1.0 0.0 0.0 0.0 0.0 35 0.0 64 298 3 680 0 test_vector_/181
14052 root 1.0 0.1 0.0 0.0 0.0 35 0.0 64 298 3 1K 0 test_vector_/549
....
这表明，应用花费的其时间大约35％等待锁
It shows that the application spend about 35 percent of its time waiting for locks.
然后，使用通过plockstat（1M）工具，查找锁定应用程序正在等待。例如，追踪5秒进程ID为14052的应用程序，然后用过滤用于还原C ++符号名的C ++程序FILT输出。 （C ++的FILT实用程序提供了Sun Studio软件。）到c ++过滤如果应用程序是不是一个C ++应用程序不需要FILT。
Then, using the plockstat(1M) tool, find what locks the application is waiting for. For example, trace the application for 5 seconds with process ID 14052, and then filter the output with the c++filt utility for demangling C++ symbol names. (The c++filt utility is provided with the Sun Studio software.) Filtering through c++filt is not needed if the application is not a C++ application.
-bash-3.2# plockstat -e 5 -p 14052 | c++filt
Mutex block
Count nsec Lock Caller
-------------------------------------------------------------------------------
9678 166540561 libc.so.1‘libc_malloc_lock libCrun.so.1‘void operator
delete(void*)+0x26
5530 197179848 libc.so.1‘libc_malloc_lock libCrun.so.1‘void*operator
new(unsigned)+0x38
......
从preceding，你可以看到，堆锁libc_malloc_lock在很大程度上争，是比例问题，一个可能的原因。在libc的分配器的这个比例问题的解决方案是使用一种改进的内存分配，如使用libumem库。
From the preceding, you can see that the heap-lock libc_malloc_lock is heavily contended for and is a likely cause for the scaling issue. The solution for this scaling problem of the libc allocator is to use an improved memory allocator like the libumem library.
也可以访问： http://developers.sun.com/solaris/articles/solaris_memory html的
感谢所有谁试图回答我的问题，
Santhosh。
Thanks for all who tried to answer my question, Santhosh.
这篇关于分配的内存在Solaris / Linux操作系统释放的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
