home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / sys5 / r4 / 488 < prev    next >
Encoding:
Text File  |  1992-11-11  |  4.3 KB  |  79 lines
  1. Newsgroups: comp.unix.sys5.r4
  2. Path: sparky!uunet!spool.mu.edu!uwm.edu!rpi!newsserver.pixel.kodak.com!laidbak!tellab5!mcdchg!mcdphx!udc!avonruff
  3. From: avonruff@urbana.mcd.mot.com (Al Von Ruff)
  4. Subject: Re: Unix System Crashing!! Why?
  5. Message-ID: <1992Nov9.195145.8863@urbana.mcd.mot.com>
  6. Sender: news@urbana.mcd.mot.com (News)
  7. Nntp-Posting-Host: predator.urbana.mcd.mot.com
  8. Organization: Motorola Computer Group, Urbana Design Center
  9. References: <1992Nov3.130757.20385@cbfsb.cb.att.com> <1992Nov5.140301.20874@urbana.mcd.mot.com> <900@dsbc.icl.co.uk>
  10. Date: Mon, 9 Nov 1992 19:51:45 GMT
  11. Lines: 66
  12.  
  13. In article <900@dsbc.icl.co.uk> mbm@dsbc.icl.co.uk (Malcolm Mladenovic) writes:
  14.  
  15. >>1) strthresh is tuned too low for your system use. If your machine
  16. >>   crashes at approximately the same time of day (i.e: during backups,
  17. >>   while sending/receiving news, during high UUCP traffic, running heavy
  18. >>   networking loads), then this is probably the case. strthresh is a
  19. >>   kernel tunable which designates the maximum number of bytes which
  20. >>   the STREAMS subsystem is allowed to use. This parameter has a
  21. >>   notoriously low default setting (around 2 Megabytes). I would recommend
  22. >>   setting strthresh to a value of 50 percent of physical memory.
  23. >
  24. >This seems an unnecessarily high a value for large configurations - the machine
  25. >that I'm posting from has strthresh set to 4MB.  It is a dual processor sparc
  26. >running svr4 with 128MB of physical memory.  The machine is regularly running
  27. >with large amounts of networking traffic but no STREAMS resources problems.
  28. >This ought to be sufficient unless you are running with many TCP connections
  29. >doing bulk data transfer at the same time.  [It doesn't actually do any harm
  30. >to have a large value, if you do have a problem it will increase the length
  31. >of time the system stays up, though performance will degrade over time since
  32. >less and less memory will be available for the buffer cache and other uses.]
  33.  
  34. I have found that the strthresh setting required for a particular installation
  35. depends greatly on the type of use encountered. The 50 percent setting is 
  36. actually quite close to USL's suggested setting:
  37.  
  38.     "STRTHRESH should be set to about 1/4 to 1/2 of the total system
  39.     memory. The default of 2000000 (approximately 2 megabytes) is a
  40.     good maximum for a 4 megabyte system."
  41.  
  42. The above is from the "Tunable Parameters" section of the SAG (chapter 10).
  43.  
  44. In practice, I have found that 2 Meg is sufficient for single user systems,
  45. or systems with light multi-user loads. I have found that 4 Meg is sufficient
  46. for most other multi-user systems  - but I have seen several notable exceptions.
  47.  
  48. For instance, our main source configuration backbone (A quad 88K with 64 MB of
  49. physical memory) has a typical average load of 300 to 600 processes, about 80 
  50. to 100 users, with file systems NFS mounted via T1 link to somewhere between 
  51. 40 to 60 remote hosts. This system has an extremely high STREAMS usage profile, 
  52. and 4 Meg of STREAMS buffers is simply inadequate.
  53.  
  54. I have also observed a dual CPU system with 128 MB with four modems (lots of
  55. ldterms and STREAMS-based tty drivers) connected to uunet (serving as
  56. a UUCP hub) die of resource starvation unless strthresh was boosted well 
  57. past 8 MB.
  58.  
  59. As you stated, there isn't any penalty for configuring "too much" STREAMS
  60. resources (as long as you stay well below physical memory limits). The real
  61. drawback that I have seen is that it prolongs system death in cases where
  62. real problems exist, dragging out the debug time for that particular problem.
  63. As you also stated, these systems are usually pretty easy to identify due
  64. to their dog-slow performance.
  65.  
  66. >    ....  If Strcount increases over time
  67. >with no corresponding change in the system workload you probably have a
  68. >memory leak in either the STREAMS subsystem itself or in one of the STREAMS
  69. >modules or drivers.   If this is the case you need to report the problem
  70. >to your vendor.  It may also aloow you to do planned, clean reloads at a more
  71. >convenient time than just when the system locks up.
  72.  
  73. Agreed.
  74.  
  75. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  76. Al von Ruff             Motorola Microcomputer Division, Urbana Design Center
  77. Voice:  217.384.8553        1101 East University Avenue, Urbana, IL 61801 USA
  78. Internet:  avonruff@urbana.mcd.mot.com         UUCPnet:  uiucuxc!udc!avonruff
  79.