[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: caching magic (was: How to trace activity on Window platform ?)
--On Thursday, June 17, 2004 12:22 PM +0200 Pierangelo Masarati
<ando@sys-net.it> wrote:
AFAIR, set_cachesize is a DB_CONFIG directive that sets the cache size in
bytes (and multiples) at the db2 layer; cachesize is a slapd.conf
directive sets the number of entries (not bytes) that are cached by the
backend. They're totally unrelated.
This is correct.
uh oh
this is beginning to seriously confuse me :)
from the set_cachesize doc on sleepycat (
http://www.sleepycat.com/docs/api_c/db_set_cachesize.html)
I learned that ".. if ncache is 0 or 1, the cache will be allocated
contiguously in memory."
There are different memory stores overall.
There is the DB memory environment, which is either on disk or in memory,
depending on how you set it up.
There is the memory pieces that slapd uses. Don't confuse the two. ;)
The above line is talking about the former.
So I figure that if, for performance reasons, I want to put my db
entirely in memory, I have two options
1) measure the size of the db (and indices) on the file system. use the
set_cachesize directive in DB_CONFIG with a larger size and ncache set to
0 or 1 (and db_recover after the changes to DB_CONFIG)
You can even set it to 2 or 4 or whatever. It'll still be cached in the DB
memory environment. Note that the difference is how many *pieces* it is in
the memory environment, not whether or not it is in the memory environment.
2) measure the number of entries in the db. use the cachesize directive
in slapd.conf to set it to something larger
Err no. The cachesize directive says how many entries should be cached.
Basically, when you have your server running, the odds are that some
entries are going to be used (hit) more often. Therefore, this allows you
to cache a certain number of the most used (hit) entries.
I understand that 1) would be a server-wide configuration and 2) is a
database specific configuration (one server can have many databases)
Actually this is not quite correct
Your (1) which is the DB_CONFIG, only applies to the database created there
(ie, /db and /db2 could each have their own DB_CONFIG)
Your (2) which is the cachesize, applies to the particular database stanza
it appears in.
So both are related specifically to a given database.
But my questions:
- in case my server only has one database: are 1) and 2) equivalent? i.e.
can I chose one of either cachsize or set_cachesize and ignore the other?
No, see above.
- if i set both, what are the effects or the caveats?
You want both set.
- what does shm_key do again?
Allocates the DB database memory to use a shared memory segment (RAM)
rather than disk-based memory environment. It dramatically improves data
load times among other things.
- why does setting shm_key fail on my RH enterprise 3.0 box (I tried
different values, the debug error is always something like shmget: key:
9: unable to create shared system memory region: Invalid argument) but
not on my Solaris 8 box (both have 2GB of memory, both are configured
identically with set_cachesize 0 214748365 0 in DB_CONFIG)?
You need to get sysctl.conf set up on RH3. What I was using was:
addline /etc/sysctl.conf "kernel.msgmni=1024"
addline /etc/sysctl.conf "kernel.shmmax=3221225472"
addline /etc/sysctl.conf "kernel.shmall=3221225472"
system /sbin/sysctl -p /etc/sysctl.conf
That allows up to 3GB of shared memory to be used, you'll want to tweak
that downwards for your server.
On Solaris, you still probably want to tweak /etc/system.
We have:
* force load the shared module kernel information.
forceload: sys/shmsys
* allow shared memory segments of up to 3 GB (default 1MB)
* See http://www.sun.com/sun-on-net/itworld/UIR960101perf.html
set shmsys:shminfo_shmmax=3221225472
* Increase memory performance when filesystem is being heavily used.
* See http://www.sun.com/sun-on-net/performance/priority_paging.html
set priority_paging=1
* autoup influences how much RAM is checked by fsflush every 5 seconds.
* Default = 30. Increase autoup to decrease mem management overhead.
* See http://docs.sun.com/db/doc/806-7009/6jftnqsin?a=view
set autoup = 60
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html