Fedora directory users - Sep 2005 - Tuning nsslapd-dbcachesize on Solaris

When tuning FDS on a Solaris machine, I''ve heard two different 
suggestions about nsslapd-dbcachesize:
1. Decrease nsslapd-dbcachesize, and instead rely on Solaris'' built-in 
filesystem cache which performs better.
2. Tune nsslapd-dbcachesize up to a value that is at least as large as 
the size of your backend LDBM database.

To know for sure which works best in my case, I''ll need to test both of
course.  But, does anyone have any thoughts or prior experience on which 
of the above options performs better?

Thanks a lot,
-- George

George Holbert wrote:
> When tuning FDS on a Solaris machine, I''ve heard two different 
> suggestions about nsslapd-dbcachesize:
> 1. Decrease nsslapd-dbcachesize, and instead rely on Solaris''
built-in
> filesystem cache which performs better.
> 2. Tune nsslapd-dbcachesize up to a value that is at least as large as 
> the size of your backend LDBM database.
The filesystem cache doesn''t really perform better. (Pages that are
in the db cache are used directly from process memory. Any page
that is not resident in the db cache must be fetched from the filesystem,
incuring a user/kernel transition and a memory copy of the payload.)
Someone way back ran some tests and convinced themselves that it
did, and then wrote that doc ;) Actually there was some basis in reality
until recently we didn''t have a 64-bit Solaris version, however the
filesystem cache was able to use 64-bit address space. So for VLDB
deployments it was true that the filesystem cache delivered better
overall use of system memory beyond 2-ishGbytes.

But, the filesystem cache does ok (as is the case on all modern OS''es)
so if you aren''t looking for tip-top performance it''s fine to
confiure a
smallish db cache and rely mostly on the filesystem.

One thing to note is that the db cache is mmap''ed, and Solaris does
some very strange and evil things with mmap''ed files that are not
in tmpfs filesystems (it will decide all of a sudden to write back
dirty pages to disk at an amazing rate, to the exclusion of performing
all other useful work on the box). The solution to this problem is
documented : put the db home dir in tmpfs (or use sysv memory,
but that''s not officially supported I don''t think).

David,
Thanks very much for your explanation!  I appreciate it,
-- George

David Boreham wrote:
> George Holbert wrote:
>
>> When tuning FDS on a Solaris machine, I''ve heard two different
>> suggestions about nsslapd-dbcachesize:
>> 1. Decrease nsslapd-dbcachesize, and instead rely on Solaris'' 
>> built-in filesystem cache which performs better.
>> 2. Tune nsslapd-dbcachesize up to a value that is at least as large 
>> as the size of your backend LDBM database.
>
>
> The filesystem cache doesn''t really perform better. (Pages that
are
> in the db cache are used directly from process memory. Any page
> that is not resident in the db cache must be fetched from the filesystem,
> incuring a user/kernel transition and a memory copy of the payload.)
> Someone way back ran some tests and convinced themselves that it
> did, and then wrote that doc ;) Actually there was some basis in reality
> until recently we didn''t have a 64-bit Solaris version, however
the
> filesystem cache was able to use 64-bit address space. So for VLDB
> deployments it was true that the filesystem cache delivered better
> overall use of system memory beyond 2-ishGbytes.
>
> But, the filesystem cache does ok (as is the case on all modern
OS''es)
> so if you aren''t looking for tip-top performance it''s
fine to confiure a
> smallish db cache and rely mostly on the filesystem.
>
> One thing to note is that the db cache is mmap''ed, and Solaris
does
> some very strange and evil things with mmap''ed files that are not
> in tmpfs filesystems (it will decide all of a sudden to write back
> dirty pages to disk at an amazing rate, to the exclusion of performing
> all other useful work on the box). The solution to this problem is
> documented : put the db home dir in tmpfs (or use sysv memory,
> but that''s not officially supported I don''t think).
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Added here - 
http://directory.fedora.redhat.com/wiki/Performance_Tuning#Database_Tuning_Considerations

David Boreham wrote:
> George Holbert wrote:
>
>> When tuning FDS on a Solaris machine, I''ve heard two different
>> suggestions about nsslapd-dbcachesize:
>> 1. Decrease nsslapd-dbcachesize, and instead rely on Solaris'' 
>> built-in filesystem cache which performs better.
>> 2. Tune nsslapd-dbcachesize up to a value that is at least as large 
>> as the size of your backend LDBM database.
>
>
> The filesystem cache doesn''t really perform better. (Pages that
are
> in the db cache are used directly from process memory. Any page
> that is not resident in the db cache must be fetched from the filesystem,
> incuring a user/kernel transition and a memory copy of the payload.)
> Someone way back ran some tests and convinced themselves that it
> did, and then wrote that doc ;) Actually there was some basis in reality
> until recently we didn''t have a 64-bit Solaris version, however
the
> filesystem cache was able to use 64-bit address space. So for VLDB
> deployments it was true that the filesystem cache delivered better
> overall use of system memory beyond 2-ishGbytes.
>
> But, the filesystem cache does ok (as is the case on all modern
OS''es)
> so if you aren''t looking for tip-top performance it''s
fine to confiure a
> smallish db cache and rely mostly on the filesystem.
>
> One thing to note is that the db cache is mmap''ed, and Solaris
does
> some very strange and evil things with mmap''ed files that are not
> in tmpfs filesystems (it will decide all of a sudden to write back
> dirty pages to disk at an amazing rate, to the exclusion of performing
> all other useful work on the box). The solution to this problem is
> documented : put the db home dir in tmpfs (or use sysv memory,
> but that''s not officially supported I don''t think).
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users