[Date Prev][Date Next]
Re: [ldap] Implementation Suggestions
1. Separate directory from account data . . . perhaps using
some sort to "make it look" like they're all one server/service.
Directory stuff is by far the most intensely searched, updated, and
involves "unusual" queries instead of a simple "give me this one
Splitting up your DIT can give some performance improvements if you
have separate storage for each part. back-meta may also give you some
flexibility options. You may also want to review your indexing
I was even almost thinking more than just separate storage . . .
separate machines entirely. Back-meta looked quite interesting and I
never got a chance to look into it heavily. I did run into a weird
problem at one point where I tried to effectively alias o=NCSU,c=US
to dc=ncsu,dc=edu and for some reason the backend that was handling
that kept "crashing". (by crashing I meant, it would start to spit
errors instead of answering queries we elected to just kick that to
2. Is Solaris causing too much of a bottleneck I/O wise? It seems
notorious for having slower I/O than Linux, so I'm wondering if
part of my problem. This is Solaris 8 btw.
Solaris 9 started huge updates to the disk system and Solaris 10 keeps
it going. (Although they were always faster than linux, in my
opinion) Upgrading to Solaris 10 will give you a boost for free.
Hrm. Unfortunately I really don't have the option of upping to >
Solaris 8 yet. We operate around 'kits' here and no one has created
a kit for 9 or 10 yet. (Working on 10 but looots of other things
If you want to stick with solaris 8, there are a lot of articles out
there about tuning solaris disks with fsflushr-related settings. Look
at docs.sun.com for solaris 8 /etc/system tunables. Even if you
upgrade, you should look into your OS tunables for such an I/O-intense
service as ldap.
Hrm, Ok! I'll take a look around!
3. Maybe I have Berkeley DB configured like crap? Thing is I
Thanks for your response!!