Here's the numbers from a small LPAR inhouse.

sasquatch vm-oracle:/mtn_home/sasquatch> vmstat -v

4194304 memory pages

3915331 lruable pages

393725 free pages

2 memory pools

773459 pinned pages

95.0 maxpin percentage

3.0 minperm percentage

90.0 maxperm percentage

28.4 numperm percentage

1114771 file pages

0.0 compressed percentage

0 compressed pages

28.4 numclient percentage

90.0 maxclient percentage

1114771 client pages

0 remote pageouts scheduled

4 pending disk I/Os blocked with no pbuf

0 paging space I/Os blocked with no psbuf

2228 filesystem I/Os blocked with no fsbuf

0 client filesystem I/Os blocked with no fsbuf

5330 external pager filesystem I/Os blocked with no fsbuf

64.0 percentage of memory used for computational pages

OK... so that's 64.0% computational memory, 28.4% numperm/numclient, and 393725 free pages. Let's see...

393725 free pages from 4194304 total pages... that's 9.4%.

64.0%

+ 28.4%

+ 9.4%

-------

101.8%

Huh?!? I guess I could pass this off as a rounding error if it was between 100% and 101%. But not if the total of 3 numbers is 101.8%!

What's going on?

If I look at the total of those numbers over a 12 hour period in 30 second increments, it doesn't get any better.

Well... if there's anything that will make me look like a stooge on a conference call, its when I can't add 3 numbers to get 100% reliably when its expected. But, I'm not willing to fudge the numbers, either.

Lets consider just these numbers.

4194304 memory pages

28.4 numperm percentage

1114771 file pages

28.4 numclient percentage

1114771/4194304 = 26.58%

Not 28.4%? Oh. That seems like a clue. Is there some level of inaccuracy when numperm/numclient is calculated? Nope. (It took me a long, long time to figure this out but because this is *my* blog, I get to look smart here.)

What about this number reported by vmstat?

3915331 lruable pages

Hmmm...

1114771/3915331 = 28.47%

Well, look at that. The number reported as numperm is not a percentage of *total* memory pages on the server, but rather a percentage of *lruable* pages. And, rather than rounded as one may typically expect, the number is just truncated to one decimal point. I proved that to myself by looking at a bunch of numbers that I won't insert here because I think this post is already ending up too long.

So that's one reason my stacked graphs of computational, filesystem, and free memory have had such a jagged top edge like this. It won't look too jagged when its this small and with a 0-100 scale... but its bothered me for a while. At the very top of this stacked graph the jagged edge is the same as the jagged blue line displayed above which flits up and down between 100.5 and 101.6.

4194304 memory pages

3915331 lruable pages

393725 free pages

1114771 file pages

64.0 percentage of memory used for computational pages

393725/4194304 = 9.39% free memory

1114771/4194304 = 26.58% filesystem cache memory

That leaves 64.03% for computational pages. Pretty good in comparison to the 64.0% reported by vmstat. Looking at a few other values is enough to convince that while numperm is computed as a portion of lruable pages (and then truncated rather than rounded), computational memory is computed as a portion of total pages. But, is the reported computational memory truncated or rounded?

Total - (Free + File) | percentage of memory used for computational pages |

58.57 | 58.6 |

58.58 | 58.6 |

58.58 | 58.6 |

58.95 | 59 |

58.97 | 59 |

58.93 | 58.9 |

In this case, the numbers are rounded. So, there you have it. Numperm is calculated with 'lruable pages' as the denominator, and truncated to one decimal point. The reported percentage for computational memory is calculated with total pages as denominator, and is rounded as typically expected.

So... from now on to get rid of the jagged edge in my stacked graphs I'll use the page counts and convert to each to percentages with total pages as the denominator: free pages, file pages, and the remaining pages from the total as computational pages.

You can't see it... but trust me, the top edge is now straight. By definition :-)

## No comments:

## Post a Comment