Brian Buhrow <buhrow%nfbcal.org@localhost> writes:
> Hello. In my continuing quest to try and get i/o performance up on
> some NetBSD-5.1 production boxes I have, I find I have a question about the
> minimum and maximum sizes of a specific pool.
> Given the following snippet of output from vmstat -m, does the size 164,
> which I realize represents the number of objects in the pool, also
> represent the maximum number of objects in the pool? That is, if more
> than 164 instances of this object are needed, would the system be unable
> to provide the 165th instance or can it grow the pool to accomodate the
> request? If it does grow the pool, would the size value in vmstat -m
> change?
> If I've got it completely wrong, could someone elaborate?
>
> -thanks
> -Brian
>
> Name Size Requests Fail Releases Pgreq Pgrel Npage Hiwat Minpg Maxpg
> Idle
> scxspl 164 67714659 0 67714659 2101 2092 9 9 1 inf 9
First, I suggest reading the following, if you haven't already:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4759
http://www.usenix.org/event/usenix01/bonwick.html
size is the number of bytes in each object - look at vmstat -m and
kmem-N. pools allocate fixed-size objects so they can be efficienctly
packed into pages (see the first paper above). The pool is entirely
unallocated, beacuse requests-releases==0. Note that fail is 0, which
means no requests were denied. There are 9 pages in the pool, and
probably there are 24 objects per page, so 216 unallocated presently.
Pools are designed to return pages to the kernel vm system if they are
not needed, and to get pages when needed. So that line looks like a
very large number of alloc/free, but with no failures and not a lot
still allocated. Hard to really be sure, but it looks entirely healthy
to me.
Attachment:
pgphQCaq42F0Z.pgp
Description: PGP signature