home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / ultrix / 8195 < prev    next >
Encoding:
Text File  |  1992-11-09  |  4.6 KB  |  112 lines
  1. Newsgroups: comp.unix.ultrix
  2. Path: sparky!uunet!think.com!ames!haven.umd.edu!decuac!hussar.dco.dec.com!mjr
  3. From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
  4. Subject: Re: Is local caching configurable?
  5. Message-ID: <1992Nov10.013656.27999@decuac.dec.com>
  6. Sender: news@decuac.dec.com (USENET News System)
  7. Nntp-Posting-Host: hussar.dco.dec.com
  8. Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
  9. References: <776@sandia.UUCP>
  10. Date: Tue, 10 Nov 1992 01:36:56 GMT
  11. Lines: 99
  12.  
  13. >I'm using Ultrix 4.3, and have done some timing tests on
  14. >local disk access vs. nfs disk access.  Nfs seems to be
  15. >about twice as fast on writes of large files, and I am
  16. >guessing this is because the data is cached. 
  17.  
  18.     Phew. This is a can of worms. In order to answer your
  19. question accurately, I need more information. First, however,
  20. I will answer your question directly: "no, there is no caching
  21. done of NFS under ULTRIX"   Now for the "it depends" parts...
  22.  
  23. ->    Does your server have PrestoCache? This is NVRAM on
  24. the *file server* (not client) that makes NFS writes a few
  25. hundred percent faster.
  26.  
  27. ->    Are you running "biod"s on the client? These perform
  28. a form of asynchronous NFS lying that permits higher I/O
  29. thruput while giving somewhat asynchronous-like characteristics
  30. to your client-side writes.
  31.  
  32. ->    Are you measuring reads or writes? If you're measuring
  33. reads, it's often faster, and for a lot of very cool and somewhat
  34. odd reasons. When the server gets a block of a file for an NFS
  35. client, it often triggers a read-ahead of the *next* block of
  36. the file. So while the client is happily digesting the first block,
  37. the server is already getting the next one! Then the client asks
  38. for the next one, and >Zap< the server instantly replies with
  39. the block out of memory.... And pre-fetches the next. Local disks
  40. do some form of block prefetching, too, but they're contending
  41. with local I/O and whatnot, and - even though your machine may
  42. *look* like it's doing lots of things at once - it isn't. In
  43. the NFS server read case, you actually can get 2 machines
  44. working in a very sweet synchrony indeed.
  45.  
  46. ->    Are you doing lots of small writes, or are you writing
  47. reasonable sized chunks. NFS (sort of) delays writing out I/Os
  48. to a specific block until the block is full, in some situations.
  49. (otherwise writing code like:
  50.     main() {
  51.         fd = open("file",O_CREAT|O_WRONLY,0600);
  52.         while(1)
  53.             write(fd,"a",1);
  54.     }
  55.  
  56.     would be utterly amazingly crawlingly slow)
  57.  
  58.     Since you're running 4.3, there are a *lot* of NFS I/O
  59. enhancements on the server, that can make NFS service faster to
  60. begin with.
  61.  
  62.     Are the disks on your server faster than the disks on
  63. your client? If the server disks are a LOT faster than the client
  64. disks, you can get some skewed results. For BSD filesystems, if
  65. the filesystem on the client is nearly *full* the server can
  66. be a lot faster.
  67.  
  68.     See what I mean? There's a lot of gotchas.
  69.  
  70.     ULTRIX doesn't do asynchronous NFS (it's unsupported),
  71. other than with biods (read the man page) like other vendors
  72. do. Some vendors do what they call "asynchronous NFS" in which
  73. the server acks the write *before* it is written to stable
  74. storage (usually the server's volatile buffer cache). This
  75. violates the protocol but can give performance boost of up
  76. to 700%. We don't do that. In fact, we don't even have kernel
  77. support for it.
  78.  
  79.  
  80. >Are there
  81. >some parameters that can be tweaked to cause local data
  82. >to be cached, to make local accesses as fast as nfs
  83. >accesses?  (If so, would this be a bad idea?)
  84.  
  85.     accesses == reads, I assume?
  86.  
  87.     The way to improve read times on your local disk is to
  88. increase the cache size. Edit the value of bufcache in your
  89. system config file (/sys/conf/mips/MACHINENAME) and increase it
  90. to maybe 20. Be *careful* to understand what you're doing because
  91. you can make things worse if you just slap a big value in. Once
  92. you're in system tuning land, you're in the land of tradeoffs and
  93. there is NO such thing as a free lunch or performance boost.
  94.  
  95.     You can also enable cache_bufcache in param.c, which
  96. can speed things up a little as well, by allowing parts of
  97. your buffer cache table to be stored on the CPU's on chip
  98. data cache.
  99.  
  100. >Are my findings consistent with anybody else's experience?
  101.  
  102.     Yes. The problem is that you're performance analyzing a
  103. fairly complex configuration. I've seen what you're seeing several
  104. times before, and for several different reasons. (Once, for example,
  105. because I had a machine locally that was a MicroVAXII with Ra-81
  106. disks, being served by a DECSystem3100 with a load of RAM, Rz56es,
  107. a large buffer cache and [shh, don't tell Eric Schott] my kernel
  108. whacked to do asynch NFS. I/O over the network was absurdly fast,
  109. probably limited by the MicroVAX's ethernet board)
  110.  
  111. mjr.
  112.