[Date Prev][Date Next]
Re: Feature Request: Allow separate location of dn2id and id2entry (ITS#3377)
>Thank you for your reply
>I submit this issue because we need a great performance LDAP server,
>so we care about it very much. I know I can use the symbol link, but I
>think it will slower than access that database directly, right?
Wrong. Use of a symbolic link will not slow performance down at all. The
link is referenced when a file is opened, after that it is irrelevant.
>If I can configure it to separate disk, we can use two scsi card to
>drive two diskes, I think it can promote performance than place them
>in same card and disk.
This will only make a difference if your BDB cache is too small. When
the BDB cache is configured correctly, I/O bandwidth to the actual
database files is insignificant.
>If you think that feature is useless, I still have a question.
>Can I the define the bdb databases' page size when I create them?
No. You can change the size of the id2entry page at compile time if you
wish, but there is very little reason to. It sounds to me like you
haven't studied the database mechanisms well enough to be qualified to
make such a change, and do not understand the Unix filesystem or
operating system well enough to evaluate the results.
First you must read the SleepyCat DB library documentation. Then you
must analyze your existing database performance (using tools such as
db_stat). Only then can you determine whether changing the page size
will make any difference.
Currently our benchmarking shows that OpenLDAP with back-bdb/back-hdb
yield the fastest LDAP performance on the planet. If you have configured
the available options correctly, tuning this parameter will probably not
yield any improvement.
> Zhao Xin
>On Thu, 28 Oct 2004 00:21:48 -0700, Howard Chu <email@example.com> wrote:
>>>Full_Name: Xin ZHAO
>>>Submission from: (NULL) (18.104.22.168)
>>>A properly setting of block size for file system will increase or decrease
>>>performance of file access. If it is possible to separate dn2id and id2entry
>>>databases' location (Normally, the former uses 4K page size and the latter uses
>>>16K), then it will be possible to separate them into different filesystems and
>>>hence optimize performance for large file systems.
>>It doesn't seem to me that such a feature would get very much use. You
>>can just symlink the files to another location if you really need to.
>>The size of the dn2id database page is not fixed at all, it is whatever
>>the underlying filesystem uses, so it will already be optimal by
>>default. The 16K of the id2entry database is already an even power-of-2
>>and multiple of the common page sizes in use today, so I don't see any
>>compelling reason to try to optimize it further.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support