[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: 2.1.17 performance issues
Quoting Howard Chu <hyc@highlandsun.com>:
> > -----Original Message-----
> > From: xoror@infuse.org [mailto:xoror@infuse.org]
>
> > On Wed, 16 Apr 2003, Howard Chu wrote:
> > > Since you say that the performance degradation persists past a directory
> > > restart, it sounds like your BDB environment has run out of resources.
> You
> > > should examine the statistics that db_stat provides. You should read the
> > > SleepyCat documentation on how to use the Berkeley DB library.
> >
> > I have gone through the cache settings again and now have solved my
> > problem. The DB_CONFIG needs to be set before you create anything.
> > A cache file on disk will be created. This explains why a
> > restart of slapd doesn't help a thing.
>
> > I still have a question left. Why is the cache maintained on disk? Why is
> > swapping out old pages/entries and swapping in new pages/entries so slow?
> > Does this imply when you have a large cachefile swapping out/in takes a
> > lot longer then a small cache file ?
>
> These questions about why/how BerkeleyDB works are beyond the scope of this
> mailing list. You might try finding someone at sleepycat.com to answer them
> for you. In brief, BDB with transactions is designed to support reliable
> database updates, such that changes persist and are not lost even if there
> are other failures in the software or hardware environment. If you don't
> care
> about persistence and recoverability you can leave your database environment
> in a RAMdisk/tmpfs etc. or recompile back-bdb to use shared memory instead
> of
> the on-disk cache. Doing so will leave you fairly vulnerable to power
> failures and other common mishaps.
Sorry for going a bit offtopic, but write ahead loggin is ivented for this
purpose isn't it ? so the cache ondisk would not be nessesacary. If we take a
look at PostgreSQL, (yes i and others have tested it) they don't lose data if
you pull the power plug when the db is doing a lot of transactions.