NFS Performance Tuning for HP-UX 11.0 and 11i Systems

nfs performance tuning for hp-ux 11.0 and 11i systems page 82

Notes:

Page 82July 22, 2002

cachefs

Application Binary Caching Dilemma

• Most CacheFS customers want to use CacheFS to

distribute NFS applications to their clients

• In order to remain cached, a cached file must be loaded

in 32 or fewer non-contiguous chunks

• The UNIX loader usually loads application binaries in

more than 32 non-contiguous chunks because of

demand paging, which means that CacheFS is usually

ineffective at fronting application binaries

Since CacheFS is designed to work best with NFS filesystems that contain read-only

data that does not change frequently, one of the most common uses for CacheFS is

to manage application binaries. The behavior expected by most customers is that

when the binary is executed the first time via a CacheFS mount it will be cached on

the client, and subsequent accesses will be satisfied from the local cached copy,

thus avoiding the need for an NFS read request. Another expectation is that these

binaries would remain cached following an unmount or a reboot. Unfortunately,

CacheFS rarely behaves this way on either HP-UX or Solaris platforms.

CacheFS uses a 32-slot allocation map to represent every file it caches. Each slot

consists of a starting offset and a length value, which means that a cached file can

only be represented in 32 non-contiguous chunks. Any attempt to access more

than 32 non-contiguous regions of the file causes CacheFS to mark this file as

invalid – effectively disabling caching for this file. The “demand paging” algorithm

used by the HP-UX (and Solaris) loader typically results in application binaries

being loaded in more than 32 non-contiguous regions, which limits CacheFS’

effectiveness when fronting NFS-based applications.