Re: [Sks-devel] 3 million keys & and community help requested

[Jeffrey Johnson]

On Nov 3, 2011, at 1:09 PM, Kim Minh Kaplan wrote:

> Jeffrey Johnson wrote:
> 
>> The mmap tunable is by far the most significant performance
>> tunable if there is some concept of "working set", which might not
>> be achievable for a 3M pubkey store.
> 
> I did not find any reference to a "mmap tunable" in the documentation.

Sure.

Here is what is used by rpmdb's tuned aggressively for I/O performance
(the heuristic is 25% of 1Gb of memory = 256Mb permitted to be mmap'd)

        set_mp_mmapsize         268435456

The tunable is a resource cap on the max. memory permitted to
be mmap'd. There's a huge performance win when all the blocks
in the mpool can just be flipped in rather than copied.

OTOH, one needs some concept of "working set" which may not be achievable
with SKS databases; an rpmdb tends to perform well when all
installed packages can be mmap'd:
        $ ls -al /var/lib/rpm/Packages
        -rw-r--r--. 1 root root 85352448 Oct 30 11:30 /var/lib/rpm/Packages
(just what I happen to have installed, ymwv).

> Could you give me some more detail? Or is it just another way to name
> the cache 
> (http://download.oracle.com/docs/cd/E17076_02/html/programmer_reference/general_am_conf.html#am_conf_cachesize)?

I personally have never seen any signficant I/O increases changing
the cache size in an rpmdb. Other types of access will be different of course.

There's a huge win if you stub-out the sync(2) vector in Berkeley DB:
but that isn't on a "reliability" path but rather aggressive performance
tuning.

its likely feasible for the initial import, were you don't much care
about "reliability". One can likely also disable sync(2) if you are prepared
to deal with the consequences of information not reaching disk. A pretty safe
assumption in SKS because of the gossiping.

73 de Jeff