Increasing "Long term cache hits" & LRU 1

[theripper]

5.1 SBE sp4 -

A while back, I dropped 512MB upgrade into my server [for a total of 892MB]. My main goal was to increase efficiency of my "Long term cache hits" and LRU set time.

After restarting my server, the LTCH starts at about 70% - it has slowly increased - currently at 81%

From everything I've read, this LTCH % should be above 90%. Is there another setting or resource I should be looking at? Setting change?

Thanks everyone.

 

[salserocito]

Because you have added quite a bit of memory to this Server, there are still unused Cache Buffers available that will used for disk requests of data that has not been requested before. Thats why you see the percentage residing at its current level.

Maybe this will explain it a little further...

NetWare's file caching subsystem is a pool or collection of 4 KB memory pages. After loading the OS, system NLMs, and application NLMs, NetWare initializes all remaining memory as the file cache pool. At the beginning of the list is the "list head," where new cache buffers are inserted into the list. The end of the list is the "list tail," where old cache buffers are removed from the list. Each cache buffer in the list is linked to the next cache buffer, and each one includes a time stamp indicating the time the cache buffer was inserted into the list head.

When the server receives a disk I/O request for data that is not currently in cache (a cache "miss&quot, the data is read from the disk and written into one or more cache buffers that are removed from the list tail. Each newly filled cache buffer is time-stamped with the current time and linked into the list head. A newly filled cache buffer is designated as the most-recently-used (MRU) cache buffer because it has resided in cache for the least amount of time.

A cache "hit" a frequent event in NetWare environments occurs when a disk request received by the server can be serviced directly out of cache, rather than from disk. In this case, after the request is serviced the cache buffer containing the requested data is removed from the list, time-stamped with the current time, and relinked into the list head. In this manner, MRU cache buffers congregate at the head of the list. This characteristic of the list is important to understand, because you want your MRU cache buffers to remain cached in anticipation of repeated use and repeated cache hits.

At some point in this process, the file cache pool becomes full of recently used data. This is where the least-recently-used (LRU) cache buffer comes into play. LRU cache buffers are buffers that were originally filled from the disk, but haven't been reused as frequently as the MRU cache buffers at the list head. Due to the relinking of MRU cache buffers into the list head, LRU cache buffers congregate at the list tail. When new cache buffers are needed for data requested from disk, NetWare removes the necessary number of LRU cache buffers from the list tail, fills them with newly requested data, time-stamps them with the current time, and relinks them into the list head.

The resulting NetWare file cache subsystem gives preference to repeatedly used data and holds onto less frequently used data only as long as the memory isn't needed for repeatedly used data.

Hope this helps!!!

Good Luck!

 

[theripper]

salserocito -

Very helpful and informative. So in summary, I should not be so concerned with my LRU as should be with overall MRU and the LTCH? Is that correct?

Thanks again.

 

[salserocito]

Correct! Your system is doing exactlt what it is supposed to do!

Good Luck!

 

[KA5AWP]

That was a GREAT explanation of how cache works.

Additionally, one might watch their "LRU Sitting Time" (in monitor under Disk Cache Utilization) to get a feel for how well things are going. An LRU sitting time of hours or days (during the busy part of the day) would indicate a Very healthy portion of RAM is indeed "doing the job". Times under 30 minutes or so may be your first indications that more memory is needed - SOON.