This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Excessive memory usage by associative arrays
- From: Josh Stone <jistone at redhat dot com>
- To: systemtap at sourceware dot org
- Date: Mon, 19 Jan 2015 12:28:18 -0800
- Subject: Re: Excessive memory usage by associative arrays
- Authentication-results: sourceware.org; auth=none
- References: <CANGv3mFvwB=imUM2-t3m8Q09nZ-KMw5+xomXrau3gSoQT2_hCg at mail dot gmail dot com> <y0mbnluedpr dot fsf at fche dot csb>
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.