This is a known issue to the SKS developers.  The original DB pagesizes
were not optimal. As bdb takes out a lock(mutex) per page, the entire pool
may be exhausted when creating the database.

The first part of the working around this is to put reasonable pagesize
values into sksconf to override the defaults of 2K for key and 512 for ptree

# bdb's db_tune program suggests a pagesize of 65536 for [K]DB/key. In practice
# this caused page deadlocks. I found 8K (16) and 16K (32) to be better values
pagesize:          16
#
# The tuner recommended 4096 (8) for the pagesize for PTree/ptree. I have had
# very good results with 8196
ptree_pagesize:    16

Add values for pagesize and ptree_pagesize to sksconf and try building again

In the SKS source, there is a sample DB_CONFIG file of tunable bdb parameters
in the sampleConfig directory. Copy this file into the [K]DB and PTree
directories.
Then run db_recover to remove the old environment. I believe for debian the
commands
are:

cd /var/lib/sks
db_recover -h DB
db_recover -h PTree

Verify the database directories are owned by the sks user and sks should
operate fine.

SKS 1.1.4 introduces a couple changes to help alleviate this
problem in the future: per table pagesize values for sksconf and the ability
to utilize a DB_CONFIG file at database creation time.

-- 
John P. Clizbe                      Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP                  or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-k...@gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to