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