named.memstats file question
Joseph S D Yao
jsdy at center.osis.gov
Thu May 9 22:51:57 UTC 2002
On Thu, May 09, 2002 at 06:05:42PM -0400, Todd Herr wrote:
...
> Maybe it's me, but I just can't seem to lay hands on a good source of
> documentation for the named.memstats file, with an emphasis on how to
> parse it to get a feeling for how well one's nameserver is performing,
> if in fact such information can be gleaned from this file. Lines
> such as the following:
>
> 142: 2 gets, 0 rem
> 144: 746 gets, 1 rem (1 bl, 27 ff)
> 168: 943 gets, 1 rem (1 bl, 23 ff)
> 169: 2 gets, 0 rem
> 192: 552 gets, 1 rem (1 bl, 20 ff)
> 196: 2 gets, 1 rem (1 bl, 19 ff)
> 216: 939 gets, 0 rem (1 bl, 18 ff)
> 240: 1558 gets, 0 rem (1 bl, 17 ff)
> 256: 3 gets, 3 rem (1 bl, 13 ff)
> 264: 811 gets, 0 rem (1 bl, 15 ff)
> 288: 162 gets, 0 rem (1 bl, 14 ff)
> 312: 120 gets, 0 rem (1 bl, 13 ff)
> 336: 227 gets, 0 rem (1 bl, 12 ff)
> 360: 189 gets, 0 rem (1 bl, 11 ff)
> 384: 58 gets, 0 rem (1 bl, 10 ff)
> 388: 6 gets, 0 rem (1 bl, 10 ff)
> 408: 26 gets, 0 rem (1 bl, 10 ff)
> 432: 58 gets, 0 rem (1 bl, 9 ff)
> 456: 67 gets, 0 rem (1 bl, 8 ff)
> 460: 9 gets, 9 rem (2 bl, 7 ff)
> 480: 72 gets, 0 rem (1 bl, 8 ff)
> 499: 5 gets, 0 rem
...
Sorry about this cross-post, but I wanted it available on this mailing
list, too, next time I need to remember. ;-)
I think this has been addressed before in this mailing list. Archives
are easily findable on www.isc.org, although I think there may be a
more easily searchable copy somewhere.
The following answer is for BIND 8.*. It looked like that was what you
had printed out there. If you need a better answer for BIND 9 ... it's
easily findable, I'm sure. ;-}
I find the source for this output in "lib/isc/memcluster.c".
Each stats structure looks like this:
struct stats {
u_long gets;
u_long totalgets;
u_long blocks;
u_long freefrags;
};
The relevant prints are:
fprintf(out, "%s%5d: %11lu gets, %11lu rem",
(i == max_size) ? ">=" : " ",
i, s->totalgets, s->gets);
if (s->blocks != 0)
fprintf(out, " (%lu bl, %lu ff)",
s->blocks, s->freefrags);
These relate to the number of requests to allocate blocks of memory
using this subroutine package. The first number is the size of the
allocation. The second number ["gets"] is the total number of requests
["gets"] that have been done - counter-intuitively, this is the
structure element "totalgets". The next number ["rem"] is the number of
gets that have not been put - the amount of allocated memory
outstanding. This is very useful when debugging for a memory leak!
The last two numbers relate to the numbers of full memory blocks
allocated and memory block fragments available. It looks like, when a
request is made for a particular size of memory, a whole block of a
certain size is allocated [I'm not taking the time to research what
size]. This is broken up into fragments of the requested size, and a
freelist created to point to those fragments. The block appears to
always stay with the fragments of that size; it appears that there is no
de-fragmentation. Anyway, these statistics can help to show if there
are too many allocations of a given size before de-allocation; and if in
fact some kind of de-fragmentation would help [it looks like not; when
I implemented something like this for shared memory, I did the de-frag
just because I couldn't stand leaving it broken up like that].
Hope this helps.
--
Joe Yao jsdy at center.osis.gov - Joseph S. D. Yao
OSIS Center Systems Support EMT-B
-----------------------------------------------------------------------
This message is not an official statement of OSIS Center policies.
More information about the bind-users
mailing list