[Date Prev][Date Next]
Re: multiple subordinates and shm_key - not a good idea
On 4/27/06, matthew sporleder <firstname.lastname@example.org> wrote:
> On 4/27/06, Quanah Gibson-Mount <email@example.com> wrote:
> > Quoting matthew sporleder <firstname.lastname@example.org>:
> > > > On my systems, at least, OpenLDAP does handle this correctly. However,
> > > I am
> > > > only using a single shared memory segment, and I'm using BDB 4.2.52.
> > > >
> > > > Based off the configuration you sent in, I'm not exactly clear why you
> > > set
> > > > up so many subordinate databases instead of just using a single
> > > database.
> > > > Certainly your performance would improve by using a single database,
> > > and
> > > > you'd get better resource usage...
> > > >
> > > > --Quanah
> > >
> > > I'll compile 4.2.52 and retry some testing soon. I was having trouble
> > > finding sleepycat docs for 4.2.52 to see if the db_open/shm api had
> > > changed between them.
> > >
> > > The main reason for having multiple subordinates is replication, but
> > > it's also because the three main branches are used by different
> > > applications so they require different index management, utilize
> > > different schemas, etc. (these four definitions are a consolidation
> > > from 140+ ;)
> > Ah, fun.
> > As a side note, I assume you patched BDB 4.4.20 with the two patches
> > released by sleepycat, right? :)
> Umm.. no. But I'm recompiling now.
> Maybe this is the culprit:
Also, my initial read testing showed equal performance for shm vs
non-sham (mmap?). And my write test didn't seem to be working at all,
but that could be something with how I tried to setup slamd. I will
pursue this issue a little more, and see if I can come up with an ITS.
(I'll probably just stick with non-shm, though)
Can I move away from shm without reimporting my database? Something
like delete that config and then db_recover/restart openldap?
(possibly delete my log.* and __db*)