Huge NWDSSearch() performance issue, need some ideas...
Robert Charles Mahar
This may certainly be OT, but since its one of the last forums standing...
I'm trying to track down a performance related issues with one of my
apps doing a fairly simple NWDSSearch(). Customer had DS 6.xx / 7.xx
tree over IPX and searches would take 3-4 seconds. After upgrade to
new / fast servers with eDir 8.7.3.9 the same searches take 10x as much
time to run, and CPU on the eDir server at 90%. We have tried adding
indices for every attribute we can think of related to the search and
can see that the indices are being used via DSTRACE. There was no
increase in performance.
The only other "difference" is that the communications is now over IP
rather than IPX. Is there a way to force CLIB ( or whatever ) on the
server performing the NWDSSearch() to use IPX comms rather than IP? Is
there a CLIB OPTION to make this happen? Something else?
The search is of the ilk: " Search for all objects in branch X of the
tree where ( attribute A exists or attribute B or attribute C exists or
attribute D exists )" and we are looking for 4 attributes. Does not
matter which branch or if it crosses partition boundaries. In our case
we are looking for attributes containing network addresses. We can see
that both the slow and fast search return the same data, just a lot
slower and with much higher CPU load on whatever server the search is
hitting.
Any general info on profiling eDir search performance is also greatly
appreciated.
The the DS 7.xx servers were on 1.00 Ghz boxes, the new 8.7.3.9 servers
have 2 / 4GB of RAM and 1 or 2 3.xx Ghz Xeons. The DIB size is about
100MB. Up to 500Mb of RAM is dedicated for eDir cache.
The entire search might return 6000 objects. Considering that DS 7.xx
was doing the same stuff 10x faster on 4x slower boxes, there is clearly
an issue.
Any ideas appreciated!
Thanks!
-- Bob
- - - - - - - - - - - - - - - - -
Robert Charles Mahar
Traffic Shaping Engine for NetWare
http://www.TrafficShaper.com
- - - - - - - - - - - - - - - - -
Russell Bateman
introduced in MySQL response time. Now, obviously the two don't sound
very related, but since I don't know precisely what the issue is, I
can't say it's not related.
Russ
Alex Warmerdam
<in...@trafficshaper.com> schreef het volgende:
Hi,
>
>This may certainly be OT, but since its one of the last forums standing...
>
Have u disabled hyperthreating in the bios and have u fixed the amount
of memory DS may use?
That can effect the performens of DS....
Jeff Lawson
are writing extensively to the filesysten, It also only occurs in the latest
(Jan 3 2007) LibC patch.
Jeff Lawson
NetWare Core OS
LibC Engineering
>>> On 2/21/2007 at 8:34 PM, in message
<nb8Dh.4293$rL6....@prv-forum2.provo.novell.com>, Russell
Robert Charles Mahar
Please indulge me in a bit more OT on this...
I've started profiling the worker threads involved, its all a lot of
FLAIM activity, so its just grinding through the dibset pulling the
records out. It just seems as though the performance just
intrinsically, ahem, sucks. And this is on test boxes where the eDir
cache is set to 6 - 8 x DIB size, and the eDir Cache Hit percentage is
99.97% You cannot get any better than that, its not possible.
Everything eDir and FLAIM touches is already in RAM.
I've taken the same DIB on the same equipment under DS 7.62 and the
performance is 15-23x faster! E.g. a search taking 45 seconds on
8.7.3.9 takes 2.5 seconds on same hardware, same DIB contents, on DS
7.62! The 2.5 seconds seems to be limited by bandwidth, as the search
returns about 10MB of data over the wire. So there has to be something
really wrong here - either that or the modern FLAIM based eDir code is
hideously bloated compared to 8.6 or recman based 7.x. All hail recman,
I guess.
And more guesses / advice are greatly appreciated.
-- Bob