[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP, bdb and Linux filesystems
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Howard Chu schrieb:
|>-----Original Message-----
|>From: owner-openldap-software@OpenLDAP.org
|>[mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Stephan Siano
|
|
|>has anyone here done performance measurements with OpenLDAP and the
|>bdb-backend on differen Linux filesystems (the filesystem
|>where the database is stored)?
|
|
| I've only used ext2fs.
|
|
|>The background of the question is that we encountered performance
|>problems with subversion (which also stores the data in a berkeley-db)
|>when the database was stored on an ext3-FS. On closer examination we
|>found out, that for a simple testcase (Import of a 40MB repository) ext3
|>was about four times slower than ext2 (and reiserfs wasn't too much
|>better than ext3, while xfs wasn't too much slower than ext2). It seems
|>to me, that berkeley-db and ext3 (and reiser) filesystems don't play
|>together too well.
|
|
| What are the relative speeds of each filesystem when doing a plain write()
| with 40MB of data?
|
|
|>Has anybody observed a similar behaviour for OpenLDAP? Is only the
|>slapadd command affected or can a siginificant slowdown also be observed
|>in normal directory operation?
|
|
| Was the BDB database configured correctly? At the very least, did you
| configure the database to store the BDB logs on a separate spindle
from the
| BDB data?
|
| What kind of hardware was used for this test, what kind of disk
controllers?
| Since reiser and ext3 are journaling filesystems, I would expect a much
| larger I/O demand than for ext2. Coupled with the write-ahead logging that
| BDB does itself, this would lead to 2-4x the I/O load of an ext2fs
| installation if it's all writing to a single filesystem. Perhaps the I/O
| subsystem of the machine cannot support the demand. Even with multiple
disks,
| without SCSI or connect/disconnect and command queuing it would be
asking an
| awful lot of a typical Intel-based machine.
Hi,
we actually did the tests in an real life environment that was setup
rather straightforward because we didn'3t expect any problems in advance.
The database was located on a IDE-harddisc and we did store the BDB logs
on the same partition as the BDB data (and the Journal for the
journaling filesystems). I know that we might improve performance by
moving the logs to another drive, but I guess this should apply for all
the setups.
The import took approximately 1 min 10 seconds on ext2, 1 min 40 on XFS,
4 min 10 on reiserfs and 4 min 30 on ext3. The CPU was idle all the time
and the subversion process was mainly in the D state (meaning
uninterrupible sleep (wait for IO)) while waiting for the completition
of a sync-call.
I know that this setup wasn't perfectly tuned, but that is what most
people do (and the speed improvment for moving the logs to another
spindle should also be there for ext2)
Yours
Stephan Siano
- --
- ----------------------------------------------------------------------
Dr. Stephan Siano, Consultant
SUSE LINUX AG, Mergenthalerallee 45-47, D-65760 Eschborn
T: +49 (0) 6196 5095131
F: +49 (0) 6196 409607 - stephan.siano@suse.com
- ----------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/uJ8YyNxjFYe4G+cRAjm4AJ9mWv4/MvZPXS3EXcezl0siL4H9UwCfeAuX
oTjGp0+GOimIOc/aVOgh4pQ=
=rGJZ
-----END PGP SIGNATURE-----