我得到了我问过的问题的答案。
应用内存分配:
C和C++开发者必须手动管理存储器分配和释放存储器。默认的内存分配器位于libc库中。
Libc 请注意,执行free()后,释放的空间可供应用程序进一步分配,而不返回给系统。只有当应用程序终止时,内存才会返回到系统。这就是为什么应用程序的进程大小通常不会减少。但是对于长期运行的应用程序,应用程序进程大小通常保持稳定状态,因为释放的内存可以重用。如果不是这种情况,那么很可能应用程序正在泄漏内存,也就是说,分配的内存被使用,但是在不再使用时永远不会释放,并且指向分配的内存的指针不会被应用程序追踪 - 基本上会丢失。
当并发malloc或free操作频繁发生时,libc中的缺省内存分配器对于多线程应用程序并不好,特别是对于多线程C++应用程序。这是因为创建和销毁C++对象是C++应用程序开发风格的一部分。当使用默认的libc分配器时,堆由单个堆锁保护,由于在malloc或free操作期间发生严重锁定争用,导致默认分配器无法针对多线程应用程序进行扩展。使用Solaris工具检测此问题很容易,如下所示。
首先,使用prstat -mL -p来查看应用程序是否在锁上花费很多时间;看看LCK专栏。例如:
-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%的时间在等待锁。
然后,使用plockstat(1M)工具查找应用程序正在等待的锁定。例如,使用进程ID 14052跟踪应用程序5秒钟,然后使用C++ filt实用程序过滤输出以对C++符号名称进行取消处理。 (C++ filt实用程序随Sun Studio软件一起提供。)如果应用程序不是C++应用程序,则不需要通过C++ filt进行过滤。
-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
......
从前面,你可以看到堆锁libc_malloc_lock在很大程度上争,是规模问题的可能原因。 libc分配器的这种扩展问题的解决方案是使用改进的内存分配器,如libumem库。
还可以访问:http://developers.sun.com/solaris/articles/solaris_memory.html
感谢所有谁试图回答我的问题, Santhosh。