[Fedora-directory-users] Red Hat capacacity planning guidelines

Richard Megginson rmeggins at redhat.com
Tue Jan 9 15:26:55 UTC 2007


Eddie C wrote:
> Directory server at least in my usage seems to be fairly light on 
> RAM/SWAP usage. I would focus on some other things.
>
> We use a dell 860 2 sata disks 1 3.6 ghz duel core processor 2 gigs 
> ram 4 gigs swap.
>
> 1) Disk: My directory server is using software mirrored 80 GIG sata 
> disk. I notice the utilization can hit 100% but by iowait is near 
> zero. For now it seems to be running great find but next server we 
> will end up investing in a raid system. We are multi-master so a fast 
> multidisk stripe or RAID 5 is what we might end up with.
If you want to maximize your disk usage, you should put your database 
index files on their own separate disk, and put the database transaction 
logs on their own separate disk.
>
> 2) There is a varabile that can only be defined in dse.ldif and 
> requires rebuilding the databases if its changed then name escapes me. 
> But if the number of returned results is higher then a certain number 
> it causes directory server to abandon the index. It comes stock at 
> 1,000?? but if you are going to be running a huge database and queries 
> that return large result set you should set this varaible before 
> creating the database. (Sorry the name totally escapes me)
nsslapd-sizelimit, nsslapd-timelimit, nsslapd-lookthroughlimit, and 
possibly 
http://www.redhat.com/docs/manuals/dir-server/ag/7.1/index1.html#1112653
>
> 3) Ram and processor  can hit 6%  memory up to 5% processor. We all 
> know this is application/ deployment specific. My point from part, 1 
> in my deployment disk speed will be the choke point. But in general a 
> DB like mysql seems to really want to consume large ammounts of 
> memory, seems like FDS works more on disk. (I could be wrong)
You want to make FDS cache as much information in RAM as it can.  You 
want to set nsslapd-cachememsize as high as you can, to accomodate the 
entire database in RAM if possible, without taking any memory away for 
other uses of RAM in the ns-slapd process or other processes on the 
machine.  See 
http://www.redhat.com/docs/manuals/dir-server/ag/7.1/dsmanage.html#996824 
for starters.  You can use the console Status tab under each database to 
monitor cache usage.
>
> 4) Set you look through limits high otherwise the server will abandon 
> searches that examin too many records. If your DB is big
>
> In any case we get great performance on a fairly basic hardware platform.
>
> Hope that was helpful,
> Edward
>
>
> On 1/7/07, *Ankur Agarwal* <ankur_agwal at yahoo.com 
> <mailto:ankur_agwal at yahoo.com>> wrote:
>
>     Hi,
>      
>     Are there any capacity planning guidelines available for Red Hat
>     directory server? I am specifically looking for planning my disk
>     size and RAM requirements based on my userbase and frequent
>     operations.
>      
>     regards,
>     Ankur
>
>     __________________________________________________
>     Do You Yahoo!?
>     Tired of spam? Yahoo! Mail has the best spam protection around
>     http://mail.yahoo.com
>
>
>     --
>     Fedora-directory-users mailing list
>     Fedora-directory-users at redhat.com
>     <mailto:Fedora-directory-users at redhat.com>
>     https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20070109/b707cbfc/attachment.bin>


More information about the Fedora-directory-users mailing list