Cache lock parameter

David Gerstl wrote:
> 
> I've been playing with cbf on my OpenIngres instalation
> (fun fun fun) and I've noticed that the cache_lock
> parameter is not determined by the shared_cache parameter.
> 
> If cache_lock is, as I originally thought, determining whether
> any locks are held on the cache during page modification then this
> does not make sense. Anyway my cd-rom does not explain the function
> of the cache_lock parameter. Anyone have any ideas?

I understand that the cache_lock parameter relates to locking the DMF cache in
memory so that it will not be swapped to disk. However, if you are running
with cache_lock set to "ON" in Unix, the server must be started by the
superuser (root). We received a "setuid()" error when trying to start the
server (OpenIngres 1.2/00 on Solaris 2.4) with cache_lock set "ON" using
the ingres userid. 

The 1.1/04 release notes state that locking the cache in memory - "may help
server performance in some circumstances".

Andrew Parsons
Common Sense Consulting 
andrew@comsense.com

> David S. Gerstl
> gerstl@cs.sunysb.edu

======

The only time locking down the DMF cache helps is if a DMF cache page is
chosen by pageout (your SVR4 variant may call this something else).

This only happens when the DMF cache is MORE inactive than other 
major memory users on the system.  This should not happen, but if it
does it's because of:

   1) The DMF pages that were swapped out were NOT being
      referenced, so WHY are you caching them!  The idea behind
      a cache is a small amount of fast memory that keeps frequently
      used pieces of slow memory hanging around.  If they aren't 
      frequently used, there are two reasons:

          1) Your cache is TOO big
          2) Your cache is TOO big

   2) If they are being used, yet being paged out, then the system is 
      DRASTICALLY low on memory (if your average scan rate ("sr" in 
      the ps -ef output) is > 100, you are memory poor).  This can be 
      solved two ways:

          1) Buy more memory
          2) Buy more memory

   3) If your boss won't buy more memory there are three reasons:

          1) She doesn't value your time (have you had a raise?)
          2) He doesn't understand how slight the increase in 
             performance one gets by trimming 1K of memory out of
             the RDF cache
          3) She hasn't picked up a trade rag to realize the cost
             per MB for RAM is 1/10th that of the cost per MB of
             disk when he last checked.

Before you start trying to squeeze 5% more performance out of a 
Solaris box do three things:

   1) Buy the book "Sun Performance and Tuning" by Adrian Cockcroft,
      Sunsoft Press, ISBN 0-13-149642-5.  After you are done reading
      this book, you should be convinced all natural bottlenecks are
      I/O.

   2) Buy the book "The Magic Garden Explained - The Internals of 
      UNIX System V Release 4", Goodheart and Cox, Prentice Hall,
      ISBN 0-13-098138-9.  Read Chapter 3, Memory Management Subsystem.

After doing that you will realize that keeping up on the changing 
algorithms of UNIX variants from version to version is SO COMPLEX, 
there are only two things to do:

   1) Learn to write purchase reqs for memory
   2) Learn to tell when you need to (monitoring UNIX memory is quite
      straightforward, unlike managing it).

Want HUMONGOUS PERFORMANCE gains that get you sent to the Bahamas in
January?  Redesign the database architecture.

Cheers,

|---------------------------------------------------|
| Michael Leo              York & Associates, Inc.  |
| mal@visi.com             (612) 921-8083 (voice)   |
|                          Minneapolis, MN, USA     |
|---------------------------------------------------| 
| NAIUA = North American Ingres Users Association   |
|            http://www.naiua.org                   |
|   Ingres FAQ is at ftp.naiua.org in /pub/ingres   |
|---------------------------------------------------|



From: Richard Yates 

Cache lock (on|off) is a new feature in OpenIngres after 6.4 on UNIX (at
least Solaris 2.x) which takes advantage of the mlock/munlock C library
function to lock iidbms DMF cache pages into memory (the pages can still
be over-written by the iidbms, though!). This avoids page I/O faults
("swapping") when the memory is accessed. Locking memory *might* lead to
a performance increase on memory-rich systems, but might have an adverse
effect, depending on "normal" memory usage. It would be very nice if
particular tables could have their cache locked, whilst others took their
chances of being swapped (paged), but this is not possible.

If you want to use it, you'll have to guesstimate the opportunity cost of
having a lump of memory soley for the iidbms server on other processes.

N.B. if your D/B tables are large and your cache is small, the iidbms
server will require I/Os anyway, as the locked cache will be swamped.
The DMF cache manager may have to work hard.

I find this an interesting feature and hope to do some experiments with
it soon. Don't mention STAR!

Richard.
~~~~~~~~
Ingres Q & A
To William's Home Page
Email William