VIRT memory continues to grow when using 64k byte buffers

[GoogleCodeExporter]

This issue is similar to ticket 515
( https://code.google.com/p/gperftools/issues/detail?id=515 ).

My program is dealing with socket message buffers that are
64bytes in size. Most messages are not that big, but the protocol
specification says that a message could have that maximum size.
We malloc & free these buffers constantly.
One thread receives a message putting it in a malloc'd buffer.
Another thread processes the message, and then frees the buffer.
We use tcmalloc.

We notice that with this usage pattern, our VIRT memory
as reported by 'top' grows - not continuously like a slope,
but incrementally like steps. The steps appears at random
intervals. In some cases, the step up in VIRT memory no longer
occurs after several hours.

The documentation for tcmalloc says that it handles allocations
up to 32k bytes, but greater than that the buffers are handled in a
different manner.

Can tcmalloc be adjusted to handle 64k buffers 
via patch or switch or environment variable ?
This would allow the buffers to recycle and hopefully
get rid of the incremental step up in VIRT memory.

What steps will reproduce the problem?
1. build & run the a.out program in the attached ticket.tgz file.

What is the expected output? What do you see instead?
The current output as see by 'top' is that the VIRT memory for this
program grows over time. ( The program simulates the processing
of 7,000 messages per second. )

What version of the product are you using? On what operating system?
gpertools 2.4 on RedHat/Centos 6.x  64bit OS

Please provide any additional information below.
n/a

Original issue reported on code.google.com by sirwmsha...@gmail.com on 19 Mar 2015 at 7:49

[GoogleCodeExporter]

the code to see the issue

Original comment by sirwmsha...@gmail.com on 19 Mar 2015 at 7:55

Attachments:

• ticket.tgz

[GoogleCodeExporter]

tcmalloc documentation is actually somewhat stale. Since before 2.0 (I don't 
recall exact version) it is using SLAB-ful memory management for blocks up to 
256k.

That virtual address space size grows slowly is likely some virtual address 
space fragmentation. If you don't see RSS growing, then it is harmless.

Running your program for a bit I don't see RSS growth. And I did see some VSS 
growth but it stopped occurring.

It looks like most of VSS is actually thread stacks, that's why it looks 
somewhat scary.

Original comment by alkondratenko on 22 Mar 2015 at 8:20

[GoogleCodeExporter]

thanks ...  
my own tests match agree with your statements.

but...
I am going to have customers that will monitor memory usage
of the deployed program. Seeing a 'step-function' for memory ( attachment )
is going to create a headache for my support team as they will have to explain 
this.

can you point me to a code source file that confirms that 64k buffers are 
managed similar to 1k buffers ?

Original comment by sirwmsha...@gmail.com on 24 Mar 2015 at 1:02

Attachments:

• memory_step.png

[GoogleCodeExporter]

You can see it in common.h. kMaxSize constant and you can see how it is used in 
SizeMap::Init.

Another place to see it is output of MallocExtension::GetStats.

BTW, I don't see how this question might affect your case. Closing the ticket 
anyways.

Original comment by alkondratenko on 5 Apr 2015 at 5:09

• Changed state: NotABug