home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / ultrix / 9065 < prev    next >
Encoding:
Text File  |  1992-12-23  |  5.1 KB  |  109 lines
  1. Newsgroups: comp.unix.ultrix
  2. Path: sparky!uunet!spool.mu.edu!agate!ames!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!dbased.nuo.dec.com!nntpd.lkg.dec.com!nntpd2.cxo.dec.com!nabeth!alan
  3. From: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  4. Subject: Re: Some buffer cache questions
  5. Message-ID: <1992Dec23.233713.6178@nntpd2.cxo.dec.com>
  6. Lines: 96
  7. Sender: alan@nabeth (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  8. Reply-To: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  9. Organization: Digital Equipment Corporation
  10. References:  <1992Dec23.022724.27844@pony.Ingres.COM>
  11. Date: Wed, 23 Dec 1992 23:37:13 GMT
  12.  
  13.  
  14. In article <1992Dec23.022724.27844@pony.Ingres.COM>, rog@Ingres.COM (Roger Taranto) writes:
  15. >
  16. >2) Can anyone explain the various stats displayed in the bufstats command?
  17. >   I assume that readhit is this number of cache hits, and that readahit is
  18. >   the number of hits for some sort of read ahead algorithm.  Is this true,
  19. >   and what is the read ahead algorithm (or at least enough information on
  20. >   how it works so that I can tune the system to take maximum advantage of it).
  21. >
  22. >   Any explanation of the rest of the stats would be useful.
  23.  
  24. The ULTRIX buffer cache code (V4+) maintains a large group of 
  25. counters in a data structure called bufstats.  This data structure
  26. is declared in /usr/include/sys/buf.h.  Because there are so many
  27. counters it is impracticle to go through them all.  In fact more
  28. than half of them are bflush() statistics.  For this discussion
  29. I'm going to limit myself to the clear read and write counters.
  30.  
  31. Other groups of counters deal with buffer allocations, blkflush()
  32. operations, binval() operations, binvalfree() operations a couple
  33. of miscellaneous counter and the host of bflush() counters.
  34.  
  35. There are four read I/O counters.  Two for direct reads and two
  36. for read-ahead I/Os.  The file system code does read-ahead when
  37. it decides that the user is doing sequential I/O.  For ULTRIX
  38. V4.2 this appears simply be when the current LBN to be read
  39. is the previous LBN + 1.  I'm not sure what the unit size of
  40. LBN is, but I'd hope that it was the file system block size.
  41. This has probably been changed with the V4.3 I/O enhancements.
  42.  
  43. The routine doing the read-ahead (breada) duplicates part of the
  44. work done in bread() to see if the block is in the cache or to
  45. start the I/O for the block if not.  If the block wasn't in the
  46. cache then it calls bread() to get it.  If there is a read-ahead
  47. block, it also starts an read for it, unless it was in the cache.
  48. This way, the odds are good that the bread() (or breada()) for 
  49. the next block will find it in the cache and not have to wait 
  50. for I/O.
  51.  
  52. The two read counters are for cache hits and misses.  If the block
  53. was in the cache then the readhit counter is incremented.  Otherwise
  54. the readmiss counter is incremented.  The read-ahead counters also
  55. count hits and misses, for just the read-ahead attempts.  This lets
  56. you compare how much read-ahead is being done and within that how
  57. often the read-ahead was in the cache.
  58.  
  59. For example; using crash(8) to examine the bufstats structure on
  60. a V4.2A system running most file system exercisers, the read
  61. stats I get are:
  62.  
  63. readhit            1319716 (99.3%)      readmiss              9597 ( 0.7%)
  64. readahit             29552 (97.7%)      readamiss              701 ( 2.3%)
  65.  
  66. For this I/O load the buffer cache is very effective for both regular
  67. reads and read-ahead reads, though very few of the reads caused read-
  68. ahead (~2%).
  69.  
  70. The next group of interesting counters are the write and error counters.
  71. There are three counters related to writes in the structure but only
  72. two of them count the actual writes.  The 3rd I'll discuss a bit later.
  73. The two writes counters are incremented in bwrite() depending on whether
  74. the B_ASYNC bit is set in the buffer flags.  It if is set, then the
  75. I/O is done asychronously and the async_write counter is incremented.
  76. If not set, then bwrite waits for the write to complete and increments
  77. the sync_write counter.  All cache writes go through bwrite() (as far
  78. as I can tell), so the sum of these two counters is all the writes.
  79.  
  80. Using the two read counters and these write counters you can quickly
  81. get an idea of the I/O balance seen by the buffer cache.
  82.  
  83. The 3rd write counter in this group counts the number of times a
  84. buffer had to be written because the B_DELWRI bit was set in the
  85. buffer flags.  This will only happen for asychronous writes.  Among
  86. the reason it can happen are dirty buffers that need to be flushed 
  87. before being read and the cache running out of buffers.
  88.  
  89. The last counter in this group is the biodone_errs counter.  This
  90. counts the number of times the B_ERROR bit is set when biodone has
  91. been called for a buffer.
  92.  
  93. Another write counter in the structure, but not with the previous
  94. three is forcewrite.  This is a subset of delayed writes that
  95. happen when getnewbuf() flushes dirty buffers.  The delwrite
  96. counter also gets incremented in this case.
  97.  
  98. If I manage to find more spare time I'll try to quickly go through
  99. some of the others.
  100.  
  101. >
  102. >Thanks,
  103. >-Roger
  104. >rog@ingres.com
  105. >
  106. --
  107. Alan Rollow                alan@nabeth.cxo.dec.com
  108.  
  109.