home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / hp / 14814 < prev    next >
Encoding:
Text File  |  1993-01-13  |  2.3 KB  |  40 lines
  1. Newsgroups: comp.sys.hp
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!icaen!dsiebert
  3. From: dsiebert@icaen.uiowa.edu (Doug Siebert)
  4. Subject: What negative effects can setting filesystem asynchronous IO have?
  5. Message-ID: <1993Jan13.041153.17806@icaen.uiowa.edu>
  6. Sender: usenet@icaen.uiowa.edu (UseNet News daemon)
  7. Organization: Iowa Computer Aided Engineering Network, University of Iowa
  8. Date: Wed, 13 Jan 1993 04:11:53 GMT
  9. Lines: 29
  10.  
  11. I've got a 9000/710 running HP-UX 8.07 (9.1 in maybe a month, hopefully) and
  12. there is a fair amount of disk I/O going on on this system.  During peak loads
  13. I see the percent of CPU in the "I/O wait" state running at around 25% and
  14. idle CPU at around 25% as well.  The I/O wait CPU starts ramping up for me in
  15. a non linear fashion starting at around 10% I/O wait 55% idle, and I believe
  16. it has to do with the size of the disk cache (I'm using the standard 10% of
  17. available mem, which is 48M on this machine) not being quite large enough for
  18. the commonly accessed parts of the disk to all stay in cache.
  19.  
  20. I can increase the size of the disk cache, and am planning to, but I am
  21. wondering what effect I will see if I change the kernel parameter for the
  22. filesystem to be asynchronous in nature for writes, rather than synchronous.
  23. Will this lower that I/O wait CPU total, and give up more CPU to calculation
  24. and allowing higher loads to be placed on the system CPU-wise, ignoring the
  25. need for a larger disk cache?  Or will that not really help at all in that
  26. regard?  And are there any risks inherent in having the writes performed
  27. asynchronously?  I've heard several times Suns do this by default, so it
  28. can't be *that* risky, and the data being written to disk is not exactly
  29. "mission critical", so if a few minutes worth are lost before an unexpected
  30. power failure or the like, that's not a problem.  Any other hidden gotchas
  31. here other than that?
  32.  
  33. -- 
  34. /-----------------------------------------------------------------------------\
  35. | Doug Siebert                             | "I don't have to take this abuse |
  36. | Internet:  dsiebert@isca.uiowa.edu       |  from you - I've got hundreds of |
  37. | NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
  38. |     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
  39. \-----------------------------------------------------------------------------/
  40.