Hello,

I'm using BerkelyDB 4.7.25 (via the BerkeleyDB Perl module) on a FreeBSD
system in a forking daemon, with a shared cache environment. Could
someone, looking at the output below, tell me whether these statistics are
good for the cache? You'd think that "Requested pages found in the cache
(99%)" looks good, but I see no shared memory segments being used of any
kind; or how much shared memory is being used, or if, even.

Thanks,

- Mark



{root} % /usr/local/bin/db_stat -m -h /var/db/smtpd/

20MB 1KB 752B Total cache size
1 Number of caches
1 Maximum number of caches
20MB 8KB Pool individual cache size
0 Maximum memory-mapped file size
0 Maximum open file descriptors
0 Maximum sequential buffer writes
0 Sleep after writing maximum sequential buffers
0 Requested pages mapped into the process' address space
231751 Requested pages found in the cache (99%)
410 Requested pages not found in the cache
1 Pages created in the cache
410 Pages read into the cache
3430 Pages written from the cache to the backing file
0 Clean pages forced from the cache
0 Dirty pages forced from the cache
0 Dirty pages written by trickle-sync thread
411 Current total page count
411 Current clean page count
0 Current dirty page count
2053 Number of hash buckets used for page location
232572 Total number of times hash chains searched for a page
2 The longest hash chain searched for a page
248006 Total number of hash chain entries checked for page
0 The number of hash bucket locks that required waiting (0%)
0 The maximum number of times any hash bucket lock was waited for (0%)
0 The number of region locks that required waiting (0%)
0 The number of buffers frozen
0 The number of buffers thawed
0 The number of frozen buffers freed
483 The number of page allocations
0 The number of hash buckets examined during allocations
0 The maximum number of hash buckets examined for an allocation
0 The number of pages examined during allocations
0 The max number of pages examined for an allocation
0 Threads waited on page I/O

* Mark:

You seem to use only 411 pages of your database, so it fits into the cache.

Berkeley DB typically uses mmap instead of System V shared memory
segments.

"Florian Weimer" <fw (AT) deneb (DOT) enyo.de> wrote


Well, that's the thing. I'd rather have it use System V shared memory.
I do the following to open the environment (in Perl):

if (not eval {$env = new BerkeleyDB::Env
-Cachesize => 16777216,
-Home => '/var/db/smtpd',
-ErrFile => '/var/log/smtpd-BerkeleyDB.log',
-SharedMemKey => 1234,
-ErrPrefix => 'smtpd',
-Flags => DB_CREATE|DB_INIT_CDB|DB_INIT_MPOOL}) {
log ("Cannot open BerkeleyDB environment: " . \
(($_ = $BerkeleyDB::Error) ? ($_) : ($!)));

But with the 'SharedMemKey' addition, I get some weird error, like:
"Numerical argument out of domain" (whatever that means: there's way too
many google references for that one, and none associated with
SharedMemKey).

Problem is, I don't want to cache to file, as this is a forking daemon,
and each child needs to open the BerkeleyDB environment individually. So
when the child exits, a new-spawm child would have to fetch all cache data
all over from file again. I'd rather have BerkeleyDB use the available
System V shared memory; I have ~100MB unused of it:

{root} % sysctl kern.ipc | grep shmall
kern.ipc.shmall: 24576

(those are 4K pages).

So, any idea to get System V shared memory going with BerkeleyDB?

At any rate, thanks for your help so far.

- Mark

* Mark:

No, it's just mapped into the process's address space from the page
cache. It's not really that different from shared memory. FreeBSD
might agressively flush dirty pages to disk if the child exits,
though. But startup isn't the problem, really.

You probably need to compile it into the library explicitly, and you
need to specify a compatible locking algorithm.

"Florian Weimer" <fw (AT) deneb (DOT) enyo.de> wrote


Oh, I see now. Okay, then I won't be using System V shared memory after
all: seems the possible gain is just too negligible, weighed against
introducing all kinds of other possible issues associated with an entirely
different locking mechanism.

Things seem fast enough as they are, actually. I can fork 128 processes,
each opening 20+ databases, each doing a major foreach loop on the biggest
database, all in less than 4 seconds. So it seems mmap is doing just fine.

Thanks.