4

このコードをアプリケーションに適用するパフォーマンスを測定するために、小さなプログラムを作成し、Solaris/Linuxプラットフォームでコンパイルしました。

プログラムはそのように書かれており、最初はsbrk(0)システムコールを使用して、ヒープ領域のベースアドレスを取得しました。その後、システムコールを使用して1.5 GBのメモリを割り当てmalloc、次にシステムコールを使用memcpyして、割り当てられたメモリ領域に1.5GBのコンテンツをコピーしました。次に、割り当てられたメモリを解放しました。

解放した後、sbrk(0)システムコールを再度使用してヒープサイズを表示しました。

これは私が少し混乱するところです。Solarisでは、割り当てられたメモリ（1.5 GB近く）を解放しましたが、プロセスのヒープサイズは膨大です。しかし、Linuxで同じアプリケーションを実行しました。解放した後、プロセスのヒープサイズは、1.5GBを割り当てる前のヒープメモリのサイズと同じであることがわかりました。

free()Solarisがすぐにメモリを解放しないことは知っていますが、システムコールの直後にメモリを解放するようにSolarisカーネルを調整する方法がわかりません。

Linuxでも同じ問題が発生しないのはなぜですか？

4

1 に答える 1

4

私が尋ねた質問に対する答えを得ました。

アプリケーションメモリアロケータ：

CおよびC++開発者は、メモリ割り当てと空きメモリを手動で管理する必要があります。デフォルトのメモリアロケータはlibcライブラリにあります。

Libc free（）が実行された後、解放されたスペースはアプリケーションによる追加の割り当てに使用できるようになり、システムに戻されないことに注意してください。アプリケーションが終了したときにのみ、メモリがシステムに返されます。そのため、通常、アプリケーションのプロセスサイズは決して減少しません。ただし、長時間実行されるアプリケーションの場合、解放されたメモリは再利用できるため、アプリケーションのプロセスサイズは通常安定した状態のままです。そうでない場合は、アプリケーションがメモリリークを起こしている可能性があります。つまり、割り当てられたメモリは使用されますが、使用されなくなったときに解放されることはなく、割り当てられたメモリへのポインタはアプリケーションによって追跡されません。基本的には失われます。

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.

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
 ....

It shows that the application spend about 35 percent of its time waiting for locks.

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

......

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.

Also visit: http://developers.sun.com/solaris/articles/solaris_memory.html

Thanks for all who tried to answer my question, Santhosh.

于 2010-06-03T06:28:01.027 に答える