Sure. There is a good chunk of the db that doesn't replicate because it is outside of the AD object model (example: indexes) or marked to not replicate (ex: some attributes). But in the aggregate, for most objects, a fair statement...without clouding the issue with the nuances.
~Eric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, April 15, 2005 9:02 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] NTDS.dit size Just to clarify, it is the parts that change and are tagged to replicate that replicate. You could have shitloads of changes occuring that never leave the DC. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Friday, April 15, 2005 11:45 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] NTDS.dit size Trick question? The parts of the 100gb that will replicate are the parts that change. (not counting dcpromo of new boxes) How much is changing? Who knows. Different for everyone. ~Eric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Magalhaes Sent: Friday, April 15, 2005 2:32 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] NTDS.dit size Eric, Granted but how much of that actual 100gb will be replicated over that 64k line? I can see the issue if you do a DC promo on a W2k3 server on the other size and it's the first box and has to pull info over 64k, but once established that traffic shouldn't even be close to 100mb.' That said it is also environment dependant :P Carlos Magalhaes -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: 15 April 2005 06:00 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] NTDS.dit size Oops, I typo'd. First paragraph should have read: ------ It's hard to characterize how "much" connectivity you need vs. how big your db is. A huge db of mostly static info doesn't need nearly as much connectivity as a smaller db that changes a _ton_. So really, it's all about your rate of change, with the size only being a guideline. ------ I would also add, that in the average case, you're right....large DBs _tend_ to require more bandwidth than smaller ones. I can't picture a 100gb DB on the other side of a 64k link being good in the average case. :) ~Eric -----Original Message----- From: Eric Fleischman Sent: Thursday, April 14, 2005 8:56 PM To: 'ActiveDir@mail.activedir.org' Subject: RE: [ActiveDir] NTDS.dit size It's hard to characterize how "much" connectivity you need vs. how big your db is. A huge db of mostly static info doesn't need nearly as much connectivity as a smaller db that doesn't change very much. So really, it's all about your rate of change, with the size only being a guideline. For promotion, at that scale, IFM is clearly the way to go. But there's nothing wrong with the occasional promotion that is over the wire. It'll finish, it will just take a while, even on a fast network. With a 20gb db, a few things might help you: 1) Explore 64bit (ia64 or x64). Recall that on 2k3 32bit your best case cache is ~2.6gb in size. With 64bit, the sky is the limit....throw ram at a DC, and it will use it to cache more of the db. DB caching cuts down on the I/O required for reads (which for most people are the bulk of their load) and help your perf a lot. 2) If you're on 32bit, I like boxes w/~4gb of physical memory, nothing else on them, and /3gb set. It lets you really use your cache well, and still have some headroom for the OS and tools you might use here and there. 3) I'm a fan of profiling traffic hitting my DCs and optimizing the queries for AD, and possibly optimizing AD for the queries (both are on the table). Tools like SPA, field engineering logging (mentioned in a thread on this dl earlier today) and any 3rd party tools you might like all can help here. Though this advise isn't specific to large DBs......I like making things faster at any scale. :) 4) Standard disk logic about optimizing I/O throughput applies. 5) Some people "warm" the cache on DC boot. This is particularly interesting on 64bit DCs where you have tons of memory headroom. That is, after the box boots they run some really expensive queries that walk very expensive indexes (ancestry, dnt, etc.) to traverse as many objects as they can, and get them off of the disk and in to memory. It hits the DC hard from an I/O standpoint on boot, but it does get a lot of the db in to memory for actual load that starts to hit the box after. It's done in more environments than one. I like the idea quite a bit, and have thought about if there is anything we should do in the product to help facilitate this. The list is of course endless, but these are a few things that come to mind. My $0.02 ~Eric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mike kline Sent: Thursday, April 14, 2005 8:43 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] NTDS.dit size Eric/Joe, Thanks for the great input! My test lab is VM ware running on 20 GB.... TB SAN that you can use as a test = very nice setup. 100 GB did those sites have really good connectivity? You can install AD from media in 2003 but I would think there would be problems in a 2000 domain with poorly connected offices. Joe, do you run joeware.net... if you do great site and thanks for the nice tools. Thanks again Mike On 4/14/05, Eric Fleischman <[EMAIL PROTECTED]> wrote: > Well I've seen very very large in test on many occasions. The numbers I > cited below (with those very descriptive adjectives) are just what I've > seen in production. I didn't think test counted. > > If you want to count test, I could fire up a test db that is a TB or so > on a san I have nearby. :) > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Thursday, April 14, 2005 4:58 PM > To: ActiveDir@mail.activedir.org > Subject: RE: [ActiveDir] NTDS.dit size > > See I almost cc'ed you on the response to get your input on this too as > I > knew you had played with some 16GB+ DITS but didn't want to bother you > for this and didn't want to speak out of turn for you. > > joe > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman > Sent: Thursday, April 14, 2005 7:35 PM > To: ActiveDir@mail.activedir.org > Subject: RE: [ActiveDir] NTDS.dit size > > I've seen larger. > I've seen 15GB+ on MANY occasions, 30GB+ on quite a few occasions, and > 100GB+ on a few occasions. > > ~Eric > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Thursday, April 14, 2005 4:28 PM > To: ActiveDir@mail.activedir.org > Subject: RE: [ActiveDir] NTDS.dit size > > The largest production DIT I have personally seen was on the order of > 8GB for the GC DIT for a Fortune 5 company running about 250k users of which > about 180k were Exchange enabled. Also had some 250k contacts, 200k or > so computer objects, 100k or so group objects and consisted of 9 > domains. > > joe > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of mike kline > Sent: Tuesday, April 12, 2005 2:53 PM > To: ActiveDir@mail.activedir.org > Subject: [ActiveDir] NTDS.dit size > > I know that AD can have millions of objects, just trying to see what the > real world size of some your AD databases are. Do any of you have > databases greater than 20GB+... or more? > > Thanks > Mike > 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.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/
