postgresql tuning w/OpenBSD kernel/ MAX_KMAPENT/uvm_mapent_alloc crash

[Chris Paul <openbsd_(_at_)_rexconsulting_(_dot_)_net>]

Dear Misc,

After miserable performance on a 2-Xeon machine with 2GB memory on a 2GB
database, I started playing with kernel configurations. I was able to
get pretty screaming performance with the following kernel parameters
(in /etc/sysctl.conf):

kern.seminfo.semmni=256
kern.seminfo.semmns=2048
kern.shminfo.shmmax=1000000000
kern.maxfiles=4096

In postgresql.conf, I made the following changes:

shared_buffers = 100000               # min 16, at least
max_connections*2, 8KB each
sort_mem = 8192               # min 64, size in KB
max_fsm_pages = 320000                # min max_fsm_relations*16, 6
bytes each
max_fsm_relations = 16000     # min 100, ~50 bytes each
wal_buffers = 10240           # min 4, 8KB each

In /etc/login.conf, I have:

postgresql:\
        :openfiles-cur=1024:\
        :datasize-max=2048M:\
        :datasize-cur=1024M:\
        :maxproc-max=1024:\
        :maxproc-cur=128:\
        :openfiles-cur=1024:\
        :stacksize-cur=2048M:\
        :tc=daemon:


Like I said, it was pretty fast with the tweaks. I think I got almost
the whole database loaded into memory. It went along fine for about 2
days before it crashed with a :

panic:uvm_mapent_alloc: out of static entries, check MAX_KMAPENT
(currently 1000)

So I'm thinking as a next best try I will rebuild a kernel with:

option          MAX_KMAPENT=4000
option          NKMEMPAGES=16384

This server serves about 100 connections at a time. I'm thinking maybe I
should tweak more conservatively so I know what make the system
unstable. At this point, I realize I'm just jacking up values.

Anyhow, I'm very much willing to listen to any ideas, tips or tricks
anyone can offer.

Regards,

CP