<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40" xmlns:ns0="urn:schemas-microsoft-com:office:smarttags"> <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="State"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PlaceName"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"/>  <style>  </style> </head> <body lang=EN-GB link=blue vlink=purple> <div class=Section1> Hi,<o:p></o:p> <o:p> </o:p> Sounds like the box is asleep….if the i/o is 2% this suggests nothing is getting to the box…..not being a LDAP expert, but if that was a “straight” database like Oracle or MYSQL I’d think that the problem was external to the LDAP server….if the indexing was bad, I’d expect high disk i/o as a result/indicator….<o:p></o:p> <o:p> </o:p> Be interesting to see if indexing does a thing….<o:p></o:p> <o:p> </o:p> regards<o:p></o:p> <o:p> </o:p> <div> Steven Jones Senior Linux/Unix/San/Vmware System Administrator APG -Technology Integration Team <ns0:PlaceName w:insAuthor="Full Name" w:insDate="2007-12-14T09:32:00Z" w:endInsAuthor="Full Name" w:endInsDate="2007-12-14T09:32:00Z"><st1:PlaceName w:st="on">Victoria</st1:PlaceName></ns0:PlaceName> <ns0:PlaceName w:insAuthor="Full Name" w:insDate="2007-12-14T09:32:00Z" w:endInsAuthor="Full Name" w:endInsDate="2007-12-14T09:32:00Z"><st1:PlaceName w:st="on">University</st1:PlaceName></ns0:PlaceName> of <ns0:place w:insAuthor="Full Name" w:insDate="2007-12-14T09:32:00Z" w:endInsAuthor="Full Name" w:endInsDate="2007-12-14T09:32:00Z"><ns0:City w:insAuthor="Full Name" w:insDate="2007-12-14T09:32:00Z" w:endInsAuthor="Full Name" w:endInsDate="2007-12-14T09:32:00Z"><st1:City w:st="on"><st1:place w:st="on">Wellington</st1:place></st1:City></ns0:City></ns0:place> Phone: +64 4 463 6272<o:p></o:p> </div> <div> <div class=MsoNormal align=center style='text-align:center'> <hr size=2 width="100%" align=center tabindex=-1> </div> From: fedora-directory-users-bounces@redhat.com [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Jared B. Griffith Sent: Friday, 14 December 2007 9:15 a.m. To: General discussion list for the Fedora Directory server project. Subject: Re: [Fedora-directory-users] LDAP Accounts for large website<o:p></o:p> </div> <o:p> </o:p> Resources are fine, and if we really need a 16 way machine this early in the game, then we should just forgoe all of this and stick it in our regular db that sits on a 16way with 32g of mem and a fiber channel san attached to it. iostat is fine, 2% usage CPU is at 0, RAM is not even being used, so of course there is no swap going on. I think we need to do some of this indexing on particular attributes, then address the possible query issue that we think is happening. ----- Original Message ----- From: "Steven Jones" <Steven.Jones@vuw.ac.nz> To: "General discussion list for the Fedora Directory server project." <fedora-directory-users@redhat.com> Sent: Thursday, December 13, 2007 12:04:36 PM (GMT-0800) America/Los_Angeles Subject: RE: [Fedora-directory-users] LDAP Accounts for large website<o:p></o:p> <div> Hi,<o:p></o:p> <o:p></o:p> For applications there are lots of ways to improve performance….with no information supplied there is no where to start…<o:p></o:p> <o:p></o:p> Ie, look at your disk i/o…use iostat are the disks LDAP sits on at 100% utilisation? Even 80% is not good….if so make bigger raid sets and/or distribute the database over differing raid controllers and disk sets….get the utilisation down to 30%....<o:p></o:p> <o:p></o:p> Is you memory full and you are into swapping? Make sure the issue is not disk i/o bottlenecks….if not add more ram…..make sure your swap is not exhausted….add more swap until you can get more ram…<o:p></o:p> <o:p></o:p> Are your switches or routers too slow? Check their utilisation…..<o:p></o:p> <o:p></o:p> CPU maxed out? Where is it going? On wait? Check disk i/o….consider dual Quad core machines…..or even 4 way quad core machines….Dell R900s are seriously grunty boxes, have 16 cores and hold 64gig of ram cheaply, then attach them to a SAN….<o:p></o:p> <o:p></o:p> regards<o:p></o:p> <o:p></o:p> <div> Steven Jones Senior Linux/Unix/San/Vmware System Administrator APG -Technology Integration Team <st1:PlaceName w:st="on">Victoria</st1:PlaceName> <st1:PlaceName w:st="on">University</st1:PlaceName> of <st1:City w:st="on"><st1:place w:st="on">Wellington</st1:place></st1:City> Phone: +64 4 463 6272<o:p></o:p> </div> <div> <div class=MsoNormal align=center style='text-align:center'> <hr size=2 width="100%" align=center> </div> From: fedora-directory-users-bounces@redhat.com [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Jared B. Griffith Sent: Friday, 14 December 2007 8:37 a.m. To: fedora-directory-users Subject: [Fedora-directory-users] LDAP Accounts for large website<o:p></o:p> </div> <o:p></o:p> 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 - <st1:State w:st="on"><st1:place w:st="on">California</st1:place></st1:State> IT Department - Email - jared.griffith@farheap.com - Phone - 949.417.1500 ext. 266 - Cell Phone - 949.910.6542<o:p></o:p> </div> -- - Thank you, - Jared B. Griffith - Farheap Solutions, Inc. - Lead Systems Administrator - <st1:State w:st="on"><st1:place w:st="on">California</st1:place></st1:State> IT Department - Email - jared.griffith@farheap.com - Phone - 949.417.1500 ext. 266 - Cell Phone - 949.910.6542<o:p></o:p> </div> </body> </html>