This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Excessive memory usage by associative arrays


On 01/19/2015 12:07 PM, Frank Ch. Eigler wrote:
> Sergey Klyaus <myautneko@gmail.com> writes:
> 
>> [...]
>> - Each string is stored statically and MAP_STRING_LENGTH is 256 (i
>> have 2 keys so its 256)
>> - Plus statistics data gives us 1088 bytes per entry
>> - SystemTap initializes map on per-cpu basis and do it with
>> for_each_possible_cpu() (128 in my case)
> 
> Yes, unfortunately all those factors multiply.  You can control
> MAXMAPENTRIES and MAXSTRINGLEN directly via -D options or other ways.
> How many CPUs does your machine actually have?
> 
> See also
> https://sourceware.org/systemtap/wiki/TipExhaustedResourceErrors 

Especially declare "global foo[SIZE]" if you know a static size limit
for a particular array.

On stats, if you're just using @count and you don't expect this value to
have highly-concurrent updates, then a simple "+=" counter will save
memory by not reserving per-cpu space.

Also if your probe has any other global writes that aren't stats, then
you'll be taking an exclusive write lock anyway, so stats don't help.
That is, a probe is only concurrent if all its globals are concurrent.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]