Centos 4 - would have been Gentoo 2007 if I could have gotten Directory Server 
working correctly on it prior to having to have it up and running. 
Iostat - 2 % 
Raid 1 on the drives, SATA 3 drives. 


----- Original Message ----- 
From: "Steven Jones" <[EMAIL PROTECTED]> 
To: "General discussion list for the Fedora Directory server project." 
<[email protected]> 
Sent: Thursday, December 13, 2007 12:31:11 PM (GMT-0800) America/Los_Angeles 
Subject: RE: [Fedora-directory-users] LDAP Accounts for large website 





Operating system? 






CPU and Ram look good…. 



Iostat? 



Hi, 



Where is your basic fault finding data? 



We run a database backend for spam control and find that cleaning up / indexing 
the database has dramatic effects….like after 6 months our Dell 6850 is 
screwed….clean it up and its disk i/o is 2% again….but this shows up under 
iostat….using mrtg you can see the graph climbing steadily over the months….. 



A pair of SATA disks (I assume raid 1) is not very fast (on board 
raid?...shudder…)….also these are SATA, SATA sucks for random i/o and guess 
what you have a database doing random i/o…….. 



In terms of code, yes it is often the code at fault. Somehow developers who 
have written sucky code expect sys admins to spend serious time and money on 
hardware compensating for their bad code….it does not work. 



This could be the hard thing to prove….ie….is your disk i/o inadequate or is 
their code so bad its causing the i/o! 



If its disk i/o…… 



Generally, you are going to be spending most of your time reading from disk….so 
you need to be optimising for reads….raid5 is ideal but testing will prove 
this….LDAP can be distributed over disk sets…so would 4 disks in two raid1s out 
perform a R5 3+1? From my experience a r5 3+1 for databases is 20% faster than 
raid 1s…. 



I suspect you are very budget conscious and have no-name white boxes….so 
articles like this, 



http://www.tomshardware.com/2007/11/30/more_serial_raid_controllers_from_amcc/ 



Can give you good pointers as what to get….generally avoid SATA, look at 
SAS….for databases the LSIMegaraid SAS 8888ELP in a raid 5 looks worth 
buying….maybe a very small disk strip is in order so small raid5 sets…. 



You are ahead of me at present I’m still piloting FDS…. 



Regards 




Steven Jones 
Senior Linux/Unix/San/Vmware System Administrator 
APG -Technology Integration Team 
Victoria University of Wellington 
Phone: +64 4 463 6272 




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared B. 
Griffith 
Sent: Friday, 14 December 2007 9:05 a.m. 
To: Chris G. Sellers 
Cc: General discussion list for the Fedora Directory server project. 
Subject: Re: [Fedora-directory-users] LDAP Accounts for large website 




Here are the specs on the server: 
2 x 2.0Ghz Intel Dual Core Xeon 
4 x 1Gb Registered ECC RAM 
2 x 74Gb Western Digital Raptors 
Given that, the hardware issue should be more than sufficient. 
Network connections are Gigabit full duplex throughout our cage network. 

How would we go about indexing the attributes? 

Me and another sys admin have a distinct feeling that it is an issue with the 
query, but they are going to point blame at us, so we want to make sure that we 
are golden before saying it's the code. 







----- Original Message ----- 
From: "Chris G. Sellers" <[EMAIL PROTECTED]> 
To: "Jared B. Griffith" <[EMAIL PROTECTED]>, "General discussion list for the 
Fedora Directory server project." <[email protected]> 
Sent: Thursday, December 13, 2007 11:47:35 AM (GMT-0800) America/Los_Angeles 
Subject: Re: [Fedora-directory-users] LDAP Accounts for large website 


Performance is often impacted greatly by 





1) Memory on the LDAP server. Make sure you can store as much of your directory 
data store in RAM for fast access 


2) Indexing. Make sure attributes that you search on freqently are indexed. 
Also, limit what fields you search on to avoid having a heavy indexing tax. 


3) Make sure your network connections are stable, and your not connecting on a 
100MB half duplex connection while your network equiptment is expecting a full 
duplex connection. 





Once you have auditing those situations, please check your performance again. 





Sellers 





50k accounts is not that much, and a 2GHz Pentium Class or 1.5GHz Core 2 system 
with 1GB-2GB of RAM should perform okay. 










On Dec 13, 2007, at 2:36 PM, Jared B. Griffith wrote: 






I was wondering if anyone here has ever used LDAP for a website, that will 
potentially have millions of LDAP accounts. 
If so, are you experiencing slow query responses or other issues? 
If you were experiencing slow query responses, and were able to rectify the 
issue, how did you do this? 
We are currently using FDS for our main website for customer accounts. We 
currently have over 52,000 accounts in LDAP and have only been using this for 3 
months. We are now experiencing extreme slow down in query response when 
getting customer data into and out of the LDAP servers. 
Any help would be greatly appreciated. 

-- 
- Thank you, 
- Jared B. Griffith 
- Farheap Solutions, Inc. 
- Lead Systems Administrator 
- California IT Department 
- Email - [EMAIL PROTECTED] 
- Phone - 949.417.1500 ext. 266 
- Cell Phone - 949.910.6542 
-- 
Fedora-directory-users mailing list 
[email protected] 
https://www.redhat.com/mailman/listinfo/fedora-directory-users 






______________________________________________ 
Chris G. Sellers | NITLE Technology 


734.661.2318 | [EMAIL PROTECTED] 


AIM: imthewherd | GTalk: [EMAIL PROTECTED] 





-- 
- Thank you, 
- Jared B. Griffith 
- Farheap Solutions, Inc. 
- Lead Systems Administrator 
- California IT Department 
- Email - [EMAIL PROTECTED] 
- Phone - 949.417.1500 ext. 266 
- Cell Phone - 949.910.6542 

-- 
- Thank you, 
- Jared B. Griffith 
- Farheap Solutions, Inc. 
- Lead Systems Administrator 
- California IT Department 
- Email - [EMAIL PROTECTED] 
- Phone - 949.417.1500 ext. 266 
- Cell Phone - 949.910.6542 
--
Fedora-directory-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-directory-users

Reply via email to