From: "Douglas B. Jones" <[EMAIL PROTECTED]>
Date: Sun, 27 Aug 2006 16:17:16 -0400

Some other notes, in addition to what Quanah already suggested...

I am  using Red Hat:

#uname -a

Linux system 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 
GNU/Linux

I have compiled openldap-2.23.21 with Berkley DB 4.4.20. This
is a hyperthread 2 processor system with 6gb of mem.

So you're using 32 bit Pentium-4, no x86_64 support. OK.
The disk system being written to is a clariion system
(I think cx600 w/8gb of mem) that is lightly loaded at
the time I am testing this out.

In have ldapadd read an ldif with thousands of entries,
this is what I get (via top and iostat - note that the data
and log.* files are in the same place right now and that
I have seen the clariion push 100meg on another system and
30+meg on this system):

top of slapd never gets past 68% of cpu, usually stays
below 50%.
        I am not sure if the cpu in top on the two processor
        system is saying that 50% is really all of one processor.
        If not, then I am using 1/4 of possible cpu, otherwise
        it does use both cpus sometimes. I am not sure which
        it is.

top shows no swap being used, with 5+gb free (so not all mem
is being used.

top should also show percentage of CPU time spent idle vs waiting for I/O. Double check those. top also can show CPU usage per CPU, so you can check that to see how well the load is being distributed across your processors.
        In this example, I have "set_cachesize 1 0 4" in the
        DB_CONFIG file. I have can't seem to set it to 2gb
        or more. If I set cachesize to 2GB or more, I get:

        mmap: Cannot allocate memory
        PANIC: Cannot allocate memory
        unable to join the environment

That's to be expected, since by default you cannot use more than 2GB of address space in a 32 bit process. I guess there are some kernel variables you can tweak to give you 3GB if you really want it. But first you should use db_stat -m to see if you even need it.
Using iostat, I never see more than about 4mb written
to disk in a 1 second interval, yet I know the clariion
handles far more.

I normally see about 40 entries a second (syslog file)
being written (at less than 50% cpu) and that pushes up
to 50 or so (when the cpu gets in the high 60%). Virtually
memory in top shows less than 2gb and res. mem. less than
600 meg. The ulimit -a shows no limits.

If your syslog is not configured for asynchronous writes, then that's probably the main thing slowing you down at the moment.
So, I do not see any bottle necks (disk, mem or cpu). So,
how can I improve throughput? I feel that I am missing
something, just can't find out what. I have a system totally
dedicated to ldap - nothing else except normal system processes
running on it. Thanks for any help!


--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/


---
You are currently subscribed to ldap@umich.edu as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the 
SUBJECT of the message.

Reply via email to