Following up:
http://msexchangeteam.com/archive/2006/06/15/427966.aspx
Cheers,
BrettSh
On Thu, 28 Apr 2005, joe wrote:
>
> > Hey Brett... I've seen your blog, how about you tell ~Eric the story
> > and he can blog it. :o)
> >
> > <evilgrin>
> >
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley
> > Sent: Thursday, April 28, 2005 8:32 PM
> > To: [email protected]
> > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> >
> > The dev who put it in, is what I like to call "my boss" ... he has no
> > child, I can guarantee it had nothing to do with that ...
> >
> > Email me directly the Exch product manager's name, and I'll try to
> > light a fire under them ... if they don't product something, I'll
> > produce something on my blog (when it is up) and send it around ...
> >
> > Cheers,
> > BrettSh
> >
> >
> > On Thu, 28 Apr 2005, Michael B. Smith wrote:
> >
> > > One of the Exchange Product Managers said today that she is
> > > preparing a blog on Squeaky Lobster, including a picture of the
> > > original Squeaky. I also asked about the KB and was told, simply,
> > > that "it isn't currently publicly available".
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of joe
> > > Sent: Thursday, April 28, 2005 7:38 PM
> > > To: [email protected]
> > > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> > >
> > > Try - http://www.realcooltoys.com/squeakylobster.html
> > >
> > > Squeaky Lobster is a magic reg key to enable special "Squeaky Lobster"
> > > ESE counters. It first came to being, I believe, with Exchange 5.5
> > > where I heard two different stories, the first being that the dev
> > > guy who put it in had a kid who had a squeaky lobster toy (or he had
> > > it) and the other is that it was thought up after lunch. I would
> > > tend to go with the first explanation myself... Anyway, it was
> > > carried through and is available on AD, or at least it was on 2K AD
> > > which is the last time I used it a couple of years ago.
> > >
> > > There used to be a KB out there that talked about what it made
> > > available but I don't see it anywhere which sucks because if I need
> > > it again I will have to go dig through 8 GB of PSTs and notepad
> > > docs. :o)
> > >
> > > I want to say that I think I heard they changed (or were changing)
> > > the name of this reg entry to something like "show advanced
> > > counters" or something like that but I don't think I can point at
> > > any references for that.
> > >
> > > As far as I know, this key wasn't supposed to be hidden or secret,
> > > though it appears it might have gone underground. I don't think I
> > > will post any more on it and let ~Eric or Brett put out in the
> > > public whatever they think should be available.
> > >
> > >
> > > joe
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour,
> > > Joseph
> > > Sent: Thursday, April 28, 2005 1:31 PM
> > > To: [email protected]
> > > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> > >
> > > This has been a great thread. I've really enjoyed reading it.
> > >
> > > This question is going to illustrate my extreme ignorance; however,
> > > the answer is worth it. What is "Squeaky Lobster"?
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Brett
> > > Shirley
> > > Sent: Wednesday, April 27, 2005 3:42 PM
> > > To: [email protected]
> > > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> > >
> > >
> > > >>From ESE's advanced perf counters exist, that tell you on a
> > > >non-per-search
> > > basis:
> > > - Database Pages Transferred/sec
> > > - Database Page Latches/sec
> > >
> > > IIRC, the first is rate of pages being transferred from disk, and
> > > the 2nd is the rate at wich you are "making a read of something on a
> > > page in the cache"
> > > (that will include the read right after a page is transferred, BTW).
> > > It doesn't give you the per query stats you were discussing, but it
> > > does give you an idea of how much disk the DC is requiring ...
> > >
> > > If you were to isolate a DC from load, except your query, it could
> > > give a _rough_ idea for a paticular query, but remember latches
> > > aren't unique references, so if a single query internally has to
> > > read a page several times, that will be several latch counts.
> > >
> > > ...
> > >
> > > Cheers,
> > > -BrettSh
> > >
> > > On Wed, 27 Apr 2005, joe wrote:
> > >
> > > > I waffled on posting that at all. I am not sure I can properly
> > > > illustrate why I think it would be good for educational info.
> > > > Maybe just to see from the outside the deltas in speeds of the
> > > > same query when things are in cache versus not, etc. Overall it is
> > > > just another stat to help understand how your directory is performing.
> > > >
> > > > joe
> > > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] On Behalf Of Eric
> > > > Fleischman
> > > > Sent: Wednesday, April 27, 2005 2:14 AM
> > > > To: [email protected]
> > > > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> > > >
> > > > Correcting myself inline (full of that today aren't I?).....
> > > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] On Behalf Of Eric
> > > > Fleischman
> > > > Sent: Tuesday, April 26, 2005 10:41 PM
> > > > To: [email protected]
> > > > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> > > >
> > > > > I think it would be kind of interesting if the STATS control
> > > > > could tell you what % of the result set came from cache or
> > > > > something like that
> > > >
> > > > Actually, that's not really what you want. If I may, let me change
> > > > your ask in to what I think you really would like....
> > > > What you really want is the % of pages touched to service the
> > > > query that were in the cache. It doesn't matter if those pages are
> > > > returned or not, it only matters that you needed the pages to
> > > > effective service
> > >
> > > > the search. As that's what defines the amt of time it takes to
> > > > service
> > > it.
> > > > [Efleis] - I shouldn't say this, it isn't quite true. What I meant
> > > > was, this defines the amt of time that we would spend on I/O,
> > > > should those pages not be in memory. Other things might
> > > > necessitate more time
> > > spent on the search.
> > > >
> > > > That said, assuming you got what you really want, I'm not totally
> > > > sold
> > >
> > > > of the value. What will you learn?
> > > > 1) More db cache -> inefficient searches are faster
> > > > 2) Better search filter optimization -> better index selection ->
> > > > faster searches with less cache needed and less I/O needed
> > > >
> > > > Searches that hit infrequently used indexes will have a lower % of
> > > > pages in memory, but still be faster than inefficient ones that
> > > > hit many pages in memory. And the avg IT admin will wonder why. :)
> > > >
> > > > Inefficient searches are still inefficient, and are still going to
> > > > require a large db cache to service them in any sort of timely manner.
> > > > How much cache? As much as you have dataset that need be traversed
> > > > for
> > >
> > > > the inefficient search in question. Whatever that dataset might be.
> > > >
> > > > Sell me on the learning opportunity here? Sorry, I'm just not
> > > > seeing
> > > it.
> > > > I like the idea on paper, and would be more than happy to file the
> > > bug.
> > > > I'm just not seeing what you think you can do better with this
> > > > data point than you can today.
> > > >
> > > > ~Eric
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] On Behalf Of joe
> > > > Sent: Tuesday, April 26, 2005 9:11 PM
> > > > To: [email protected]
> > > > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> > > >
> > > > Thanks ~Eric. I think it would be kind of interesting if the STATS
> > > > control could tell you what % of the result set came from cache or
> > > > something like that. How feasible would something like that be?
> > > > Possibly the results of that would only be for educational reasons
> > > > but
> > >
> > > > I, at least, would find that info interesting.
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] On Behalf Of Eric
> > > > Fleischman
> > > > Sent: Tuesday, April 26, 2005 8:01 PM
> > > > To: [email protected]
> > > > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> > > >
> > > > You beat me to the reply, thanks Brett.
> > > >
> > > > A better way to think of this Joe is that a subset of the DIT is
> > > > in RAM, as much as we can fit, assuming 1) we don't run out of
> > > > memory to use 2) we don't have pressure to back off. And we try
> > > > and pick the best pages to cache ("best" definition omitted for now).
> > > >
> > > > The one thing we can't do today is that we can't proactively cache
> > > > something. Though I've thought a lot about whether or not it is
> > > > something that I should personally be pushing Brett's team to work on.
> > > > There's good and bad, but the bottom line today is that you can "warm"
> > > > the cache. In the absence of memory pressure, this warming
> > > > technique will help get things in the first time. But there are
> > > > some things it doesn't do
> > > > 1) It doesn't let you tell buffer manager to keep something in the
> > > > cache no matter what, if you think you're smarter than the buffer
> > > > manager. I would point out, almost never are you smarter than
> > > > buffer manager, even when you think you are. But that doesn't mean
> > > > you won't complain that we don't have a mechanism for it.
> > > > 2) You can't really guarantee that something is in the cache with
> > > > these sorts of warming techniques. You can get close, but you
> > > > can't (for
> > > > example) say "please prefetch this index". But warming the cache
> > > > can do the big stuff, like walking ancestry and pulling in the
> > > > mass of the
> > > data table.
> > > >
> > > > ~Eric
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] On Behalf Of Brett
> > > > Shirley
> > > > Sent: Tuesday, April 26, 2005 4:46 PM
> > > > To: [email protected]
> > > > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> > > >
> > > > Joe,
> > > >
> > > > When you say
> > > > > the actual DIT isn't cached in RAM, the tables, indexes, and such
> > > > > are cached.
> > > > I'd take issue with that ... that isn't a good way to explain what
> > > > is really happening.
> > > >
> > > > The DIT is most definately cached in RAM, it is cached directly 1
> > > > or more pages at a time. Where a page is an 8k chunk for Active
> > > > Directory. We do not extrude the tables and indexes from those
> > > > pages,
> > >
> > > > they stay in the pages, and we "take a latch" on that page's
> > > > memory when we want to update the page ... then later we write
> > > > that 8k chunk directly from that memory to the offest (based on
> > > > it's pgno) of the
> > > DIT file it belongs at.
> > > >
> > > > Now, it is true, not all of the DIT may be cached, we'll only
> > > > cache what we need, and it will not pull in free space pages into
> > > > memory (at
> > >
> > > > least in most circumstances ...? I'm thinking of prefetching might ...
> > > but lets ignore).
> > > >
> > > > I _think_ _online_ defrag (I know we're talking offline defrag
> > > > below, but mentioning online defrag is important, it is what makes
> > > > offline defrag unnecessay ... online defrag is frequently
> > > > abbreviated
> > OLD ...
> > > > which of course would be the acronym of offline defrag if it had
> > > > one, trust me OLD is online defrag (at least as far as the ESE
> > > > devs are
> > > concerned) ...
> > > > poor
> > > > taste for a TLA in my opinion ... that was a long aside), actually
> > > > logs an event on how much free space there is in the database ...
> > > > I'm 57% sure that "the DIT size" - "that free size", is the
> > > > approximate size of the non-empty data pages (i.e. pages with
> > > > data) in
> > the DIT ...
> > >
> > > > due to underflow of a record size on a page, the actual data size
> > > > is almost assuredly even less than that ... I just made that up
> > > > w/o looking at the code, so I may take that back later ...
> > > >
> > > > You can see exactly how many bytes of the DIT file + Temp DB* are
> > > > in RAM with perfmon, counters, by using perfmon ... first set the
> > > "Squeaky Lobster"
> > > > registry key to get the advanced ESE performance counter, then use
> > > > the
> > >
> > > > "Database" performance object the "Database Cache Size" counter.
> > > >
> > > > Also look at the "Database Cache % Clean", b/c you should multiply
> > > > those by each other to get real data pages currently in memory.
> > > >
> > > > * Temp DB ... so the database cache is global, so any temporary
> > > > sorts we needed to do, during LDAP queries may be taking up some
> > > > of the database cache ... I think it's like tmp.edb next to the
> > > > ntds.dit file. There'd be no technical way to subtract one from
> > > > the other, but
> > >
> > > > maybe just subtract the whole tmp database size, because that
> > > > gives you a lower bound on what is definately ntds.dit.
> > > >
> > > > ( watch for usage of offline and online here ... ) I agree you
> > > > shouldn't worry about offline defrag, but you should make sure
> > > > that online defrag is completing every now and then or the space
> > > > wastage will grow towards (I'll make a number range here) 3-5x
> > > > what it could be. Online defrag ensures that useful data is
> > > > collected onto the same
> > >
> > > > page when it can be, such that the number of non-empty data pages
> > > > is really quite close to what you'd get if you did an offline defrag.
> > > > THOUGH, you'd have free pages in the database in the online defrag
> > > > case, that offline defrag would give you back in the form of a
> > > > smaller
> > > DIT file.
> > > > So for memory purposes, joe is right, don't worry about offline
> > > > defrag, unless there are disk space issues ... but do look for the
> > > > successful online defrag event.
> > > > Note: There was an issue where online defrag was never
> > > completing.
> > > >
> > > > Both online defrag and offline defrag basically scrunch all the
> > > > data closer to where it belongs (on a per table, per index, etc
> > > > basis), with the online version leaving white space in between
> "places" ...
> > > > BUT all that said, there is technically one difference between
> > > > online defrag and offline defrag data layout ... the offline
> > > > defrag will reorder burst long values, into a order that matches
> > > > the rows in the database ... I don't feel lik delving into that yet
> ...
> > > >
> > > > That's off the top of my head, I'll check facts, and try to write
> > > > more
> > >
> > > > later ...
> > > >
> > > > Cheers,
> > > > Brett Shirley [msft]
> > > >
> > > >
> > > > posting is as is, but ...
> > > >
> > > > On Tue, 26 Apr 2005, joe wrote:
> > > >
> > > > > Possibly Eric will see my response to this and come on and smack
> > > > > me
> > > > but I
> > > > > think your PSS guy may be less than accurate. It is entirely my
> > > > opinion
> > > > > though.
> > > > >
> > > > > Reducing the physical size of the DIT I don't believe will
> > > > > increase
> > > > the perf
> > > > > of your queries. As Carlos mentioned, the actual DIT isn't
> > > > > cached in
> > > > RAM,
> > > > > the tables, indexes, and such are cached. The empty spaces in
> > > > > the DIT physical file should have little if any impact on those
> > > > > tables in
> > > > memory
> > > > > unless you start looking at things like how long does it take
> > > > > the head
> > > > to
> > > > > get from the physical location on the spindle of one entry of
> > > > > the
> > > > table to
> > > > > the next which again, once in memory, shouldn't come into play.
> > > > >
> > > > > The big bene of offline defrag that I am aware of is simply to
> > > > > reduce
> > > > DIT
> > > > > bloat and bring it down to a smaller size. You can accomplish
> > > > > the same
> > > > with
> > > > > a dcpromo demote and repromote and you can automate that with an
> > > > unattended
> > > > > script. :o) But honestly, unless you are having disk space
> > > > > issues, I
> > > > don't
> > > > > know many people who worry overly much about doing offline defrags.
> > > > >
> > > > > Even once you enable the counters, I am not sure if you will
> > > > > know
> > > > whether or
> > > > > not the whole DB is cached or not simply because the DIT size
> > > > > may not accurately reflect how much data you really have due to
> > > > > free space in
> > > > the
> > > > > DIT.
> > > > >
> > > > > I saw go out and buy a 64 bit machine, load 64 bit Windows
> > > > > Server
> > > > > 2003
> > > > on it
> > > > > and buy RAM = 4GB+2xDIT size and you can be pretty sure your
> > > > > entire DB
> > > > is
> > > > > cached. ;o)
> > > > >
> > > > > >>From the numbers Wook posted on his slide deck between poems
> > > > > >>and
> > > > haiku's at
> > > > > the most recent DEC you should see a remarkable increase in perf.
> > > > >
> > > > > joe
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: [EMAIL PROTECTED]
> > > > > [mailto:[EMAIL PROTECTED] On Behalf Of
> > > > > Fugleberg,
> > > > David A
> > > > > Sent: Monday, April 18, 2005 11:36 AM
> > > > > To: [email protected]
> > > > > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> > > > >
> > > > > The reason I asked was out of curiosity, not because of any problem.
> > > > A MS
> > > > > engineer told us that if the DIT is small enough in relation to
> > > > > the
> > > > amount
> > > > > of RAM in the DC, the entire DIT would be cached, increasing
> > > > > directory
> > > > query
> > > > > performance. I was just curious if there was a way to
> > > > > objectively
> > > > measure
> > > > > this. It's always interesting to measure things to see how
> > > > > changes
> > > > affect
> > > > > performance. For example, if I delete a large number of objects
> > > > > and
> > > > wait
> > > > > for the tombstones to age out, I know I could shrink the DIT
> > > > > with an
> > > > offline
> > > > > defrag. Would doing so have any measurable effect on perfomance ?
> > > > > I
> > > > don't
> > > > > know, but it would be interesting to do some before and after
> > > > measurements
> > > > > to find out.
> > > > >
> > > > > By the way, the context of the conversation was that the
> > > > > engineer was recommending offline defrags after removing a large
> > > > > number of objects
> > > > (and
> > > > > waiting the requisite time for garbage collection). I have no
> > > > argument with
> > > > > that, but it's nice to be able to measure what if anything it's
> > > > > buying
> > > >
> > > > > (besides a smaller DIT file). Some of us are just funny that
> > > > > way, I guess....
> > > > >
> > > > > Dave
> > > > >
> > > > > -----Original Message-----
> > > > > From: [EMAIL PROTECTED]
> > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
> > > > Magalhaes
> > > > > Sent: Friday, April 15, 2005 4:27 AM
> > > > > To: [email protected]
> > > > > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> > > > >
> > > > >
> > > > > Well none of the actually DIT is cached (into the RAM), IMO. The
> > > > engine
> > > > > might cache regular/common lookups, indexes etc but none to the
> > > > actually
> > > > > DC's RAM. But then again you have to define but what you mean by
> > > > > "into
> > > > RAM".
> > > > >
> > > > > Nathan is quite right with "Checking the working set size of
> > > > > LSASS is
> > > > not
> > > > > reliable." There are many more processes that the LSASS is
> > > > > taking care
> > > > of.
> > > > > You could dump the LSASS process and take a look and then
> > > > > determine
> > > > from
> > > > > there what is happening.
> > > > >
> > > > > But now I am curious why you asking :P Do you have a hungry
> > > > > LSASS
> > > > process?
> > > > > If you do what Patch/Service Pack level do you have on that box?
> > > > >
> > > > > Carlos Magalhaes
> > > > >
> > > > > -----Original Message-----
> > > > > From: [EMAIL PROTECTED]
> > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Nathan
> > > > > Muggli
> > > > > Sent: 15 April 2005 06:10 AM
> > > > > To: [email protected]
> > > > > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> > > > >
> > > > > Checking the working set size of LSASS is not reliable. There's
> > > > process
> > > > > overhead for things like lsa session handles and other stuff
> > > > > related
> > > > to the
> > > > > security sub system.
> > > > >
> > > > > The most accurate method is to enable the ESE Database
> > > > > performance
> > > > counters
> > > > > and look at "Cache Size". To enable the DB counters, install
> > > > > Server Performance Advisor, or check out
> > > > >
> > > > http://www.microsoft.com/resources/documentation/Windows/2000/serv
> > > > er
> > > > /r
> > > > es
> > > > >
> > > > kit/en-us/Default.asp?url=/resources/documentation/Windows/2000/se
> > > > rv
> > > > er
> > > > /r
> > > > > eskit/en-us/distrib/dsbm_mon_pzgc.asp
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: [EMAIL PROTECTED]
> > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Roger
> > > > Seielstad
> > > > > Sent: Thursday, April 14, 2005 8:45 PM
> > > > > To: [email protected]
> > > > > Subject: RE: [ActiveDir] How much of the DIT is cached in RAM ?
> > > > >
> > > > > By checking the working set size of by LSASS?
> > > > >
> > > > > --------
> > > > > Roger Seielstad
> > > > > E-mail Geek
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [EMAIL PROTECTED]
> > > > > > [mailto:[EMAIL PROTECTED] On Behalf Of
> > > > > > Fugleberg, David A
> > > > > > Sent: Thursday, April 14, 2005 2:22 PM
> > > > > > To: [email protected]
> > > > > > Subject: [ActiveDir] How much of the DIT is cached in RAM ?
> > > > > >
> > > > > > How can I determine how much of the DIT is being cached in RAM
> > > > > > on a given DC ?
> > > > > >
> > > > > > Dave
> > >
> > > List info : http://www.activedir.org/List.aspx
> > > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > > List archive:
> > > http://www.mail-archive.com/activedir%40mail.activedir.org/
> > > List info : http://www.activedir.org/List.aspx
> > > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > > List archive:
> > > http://www.mail-archive.com/activedir%40mail.activedir.org/
> > >
> >
> > List info : http://www.activedir.org/List.aspx
> > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > List archive:
> > http://www.mail-archive.com/activedir%40mail.activedir.org/
> >
> > List info : http://www.activedir.org/List.aspx
> > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > List archive:
> > http://www.mail-archive.com/activedir%40mail.activedir.org/
> >
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
