Good
point Joe.
I
will use perfmon to monitor the health of my DC.
An
nother question.
The
Web app timed out with this generic error "the serveur is down", where "the
server" = mydc.
-----
Message d'origine ----
De : joe <[EMAIL PROTECTED]>
À :
ActiveDir@mail.activedir.org
Envoyé le : Vendredi, 9 Juin 2006, 2h25mn
26s
Objet : RE: [ActiveDir] AD LDAP Logging.
When you change that threshhold you are specifying how
expensive you want the query to be before AD reports it.
Changing "Expensive" to 1, according to the docs means that
as soon as a query has to look at one or more entries it will be logged.
So when you turn down that value, you are telling it to log pretty much
everything.
That being said, unless you have changed your schema,
objectclass isn't indexed and a filter with no indexed attributes is generally
considered inefficient unless it is properly scoped. The fact that you are
returning 58 of 63 entries means that that isn't too bad, but just the same, I
would work on getting the query changed to using an indexed attribute or more
likely, because so many apps/scripts screw up around objectclass, indexing
objectclass AND getting the query changed.
When you see big noticable deltas in how long the same
query takes to run, it is usually a couple of things that could be at fault,
possibly Eric will pipe in with more. The first is that the DC is tied up with
something else and just can't give you the proc time, the other is that it has
to go to disk instead of pulling from cache. Either way you should be looking at
your perf counters to see how the DC is performing. I tend to really look at
disk counters because that is where it often falls down at. Things like disk
queue and and number of read ops for the DIT drive (write ops are usually a
rounding error except during heavy population periods) are the things I
immediately focus on. Just seeing the number of read ops doesn't help, you have
to understand your disk architecture because on some systems 500 read ops may be
just fine, but on others it could be over what the disk system is capable
of sustaining so you start backing up. As a quick rule of thumb I start
with the assumption that each spindle that is part of the volume gives you
100 IOPS capability. That can be generous so if you are on the edge keep that in
mind, but if you are at 20 OPS and you have 8 spindles in a RAID 0+1 it is
unlikely disk is your bottleneck[1] and the disk queues should bear that
out. Of course I tend to focus on disk because I memory is almost always
boosted up there because most people realize how important RAM is but only folks
who think about Exchange tend to think about disk and the only guideline I have
seen from MSFT recommends 3 RAID-1 sets for anything above several thousand
users which I don't feel is very good. Again, as a general rule I would rather
see a single RAID 0+1 (or even better if you don't care about faul tolerance a
RAID 0) or RAID-5 than 3 RAID-1's. But this is all just recanting a zillion
conversations we have had here on the list about disk layouts.
joe
[1] Virtualization really screws with this from the disk
standpoint because you need to look at counters for the physical machine and
while your DC may not be generating many read ops, if other virtual machines
are, you could be slowed down considerably by those without the Read Ops
reflecting much on the individual DC.
Hello
Tony,
Very
usefull information ! Thanks.
i
enabled this config:
15 Field
Engineering to 5
Expensive Search Results
Threshold to 1
Here
are the LDAP operation, :
1644 INFORMATIONAL NTDS
General Fri Jun 09 09:55:16 2006 childdomain\user1 Internal
event: A client issued a search operation with the following
options.
Client: 11.22.33.44 Starting node: OU=MyOU
OU=myou1 DC=childdomain DC=parentDomain
DC=root DC=fr Filter:
(objectClass=user) Search scope:
subtree Attribute selection:
givenName sAMAccountName sn Server
controls: Visited entries:
63 Returned entries: 58
Followed
by this:
1139 INFORMATIONAL NTDS
LDAP Fri Jun 09 09:55:16 2006 childdomain\user1 Internal event:
Function ldap_search completed with an elapsed time of 16 ms.
=>
for 63 visited entries, only 58 are returned and the ldap search
lasted 16 ms (Sometimes the ldap search took 140 ms...).
Questions:
Would
the IDs 1644 + 1139 tell me that the web app. is performing Inefficient and
Expensive LDAP Query to my DC ?
Thanks
for advices,
Yann
----
Message d'origine ----
De : Tony Murray <[EMAIL PROTECTED]>
À
: ActiveDir@mail.activedir.org
Envoyé le : Mercredi, 7 Juin 2006, 11h16mn
33s
Objet : RE: [ActiveDir] AD LDAP Logging.
Hi Yann
One option would be to enable
logging of all LDAP searches against the DC.
http://www.activedir.org/article.aspx?aid=97
Tony
PS. Were just loading a
new version of the site, so it might take a few minutes before you can load the
page.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Yann
Sent: Thursday, 8 June 2006 6:39 a.m.
To:
ActiveDir@mail.activedir.org
Subject: [ActiveDir] AD LDAP
Logging.
I need advices about troubleshooting LDAP connections to one
of my DC in my AD2k3.
An application named ZOPE running on a linux box accesses my
DC.
Users use a web page, via ZOPE application, that
connect to my DC to list users information. Sometimes, users are disconnected to
my DC and the admin that is responsible for the ZOPE app. called me to resolve
this issue.
What are the different steps to tshoot possible problem
with LDAP connections to my DC ?
Thanks in advance for help,
__________________________________________________
Do You
Yahoo!?
En finir avec le spam? Yahoo! Mail vous offre la meilleure protection
possible contre les messages non sollicités
http://mail.yahoo.fr
Yahoo! Mail
This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.