home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / wizards / 3895 < prev    next >
Encoding:
Text File  |  1992-09-11  |  3.1 KB  |  85 lines
  1. Newsgroups: comp.unix.wizards
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!ufo!parlier
  3. From: parlier@jpl-devvax.jpl.nasa.gov (Randy Parlier)
  4. Subject: RE: Dir Name Lookup Cache(dnlc) twiddling
  5. Message-ID: <1992Sep11.211440.14979@jpl-devvax.jpl.nasa.gov>
  6. Organization: Jet Propulsion Laboratory (NASA)
  7. Date: Fri, 11 Sep 1992 21:14:40 GMT
  8. Lines: 75
  9.  
  10.  
  11. >In article <1992Sep11.154227.7250@bristol.ac.uk> P.Smee@bristol.ac.uk (Paul Smee) writes:
  12. >>Anyhow, I have a vague memory of hearing that there is a parameter
  13. >>which can be fiddled when doing a vmunix build, which will increase the
  14. >>space reserved by the system for caching information about open inodes
  15. >>(or dirs, maybe?), and so might improve performance in an environment
  16. >>where the system is doing not very much (computationally), but using a
  17. >>lot of (small) files to do it.  Can anyone provide enough further info
  18. >>to help us find and twiddle this, as that describes precisely the
  19. >>situation this little box is in?
  20. >>
  21.  
  22.  
  23. and then
  24.     Terry Lambert
  25.     terry_lambert@gateway.novell.com
  26.     terry@icarus.weber.edu
  27.  
  28. writes:
  29.  
  30. >    You are talking about the directory name lookup cache (dnlc).
  31. >There are several magic incantations effecting this, most requiring source:
  32. >
  33. > .......alot of good interesting stuff deleted....
  34. >
  35. >4.    If you ask for too much cache, the dnlc will be turned off when
  36. >    the kernel alloc fails to get the memory.  If you have high
  37. >    values for NPROCS or MAXUSERS, the cache size required will be
  38. >    computed larger.  Too large, and caching goes away entirely
  39. >    (instead of scaling back, like you'd expect).  Be careful that
  40. >    you do not do this.  Since the flag is static to dnlc, you will
  41. >    not be able to tell that this is happening other than by inference.
  42.  
  43.  
  44.  
  45.     Name to inode conversion uses the DNLC.  Some things that impair
  46.     DNLC use are (a) long (greater than 14 character) names are not cached,
  47.     (b)long symbolic link names increase pathname resolution time, and
  48.     (c) deep directory structures require frequent cache access.
  49.  
  50.     If you don't have source code, about the only way you can change the
  51.     size of the cache is modify the 'MAXUSERS' parameter.
  52.  
  53.     You can determine what your DNLC hit-rate is by using 'vmstat -s'.
  54.     The last line reported by vmstat will say something like:
  55.  
  56.          78494 total name lookups (cache hits 95%  per-process)
  57.               toolong 74
  58.  
  59.     You could try modifying MAXUSERS and monitoring your cache hit rate
  60.     using vmstat to try and tune your system the way you want it.
  61.  
  62.     Note that 'MAXUSERS' also modifies the size of your inode cache which
  63.     can accelerate changes to file attributes.
  64.  
  65.     There is also a buffer cache for some kernel structures that is used
  66.     for inodes and cylinder group information.  You can examine your 
  67.     buffer cache hit rate by doing the following:
  68.  
  69.     echo "bstats,2/D" | adb -k /vmunix /dev/mem | sed -n -e '3p' |
  70.           awk '{printf("buffer cache hit rate: %8.2f%%\n",$3/$2 * 100.0)}'
  71.  
  72.     You can also use adb to change the number of pages used for buffer
  73.     cache using the nbuf parameter:
  74.  
  75.         echo "nbuf?W0t100" | adb -w /vmunix
  76.  
  77.     Then reboot your machine.
  78.  
  79.     NOTE:  This all applies to the SunOS.  Totally irrelevant to Solaris
  80.     I'm sure.
  81.  
  82.     Randy
  83.     parlier@puente.jpl.nasa.gov
  84.  
  85.