This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Excessive memory usage by associative arrays
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Sergey Klyaus <myautneko at gmail dot com>
- Cc: systemtap <systemtap at sourceware dot org>
- Date: Mon, 19 Jan 2015 15:07:44 -0500
- 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>
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
> Of course, I may reduce MAXMAPENTRIES, but I think there is
> something wrong with such greedy allocation...
Its purpose is to ensure that no dynamic memory allocation occurs
during runtime, so is a safety measure.
> For the record, similiar DTrace script works perfectly (after I
> removed leak of records :) ).
Understood, though their situation is much simpler, and that toy
script can be made to work on stap in many ways.
- FChE