home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sun / admin / 5541 < prev    next >
Encoding:
Text File  |  1992-08-14  |  2.8 KB  |  68 lines
  1. Newsgroups: comp.sys.sun.admin
  2. Path: sparky!uunet!mnemosyne.cs.du.edu!aburt
  3. From: aburt@mnemosyne.cs.du.edu (Andrew Burt)
  4. Subject: Re: Amd is not perfect
  5. Message-ID: <1992Aug14.163858.8018@mnemosyne.cs.du.edu>
  6. Keywords: nfsd automount amd D
  7. Organization: University of Denver, Dept. of Math & Comp. Sci.
  8. References: <Y7BF99A9_@linac.fnal.gov> <1992Aug5.231434.20156@trl.oz.au> <13916@auspex-gw.auspex.com> <1992Aug9.184414.4765@newshost.lanl.gov>
  9. Date: Fri, 14 Aug 92 16:38:58 GMT
  10. Lines: 56
  11.  
  12. In <1992Aug9.184414.4765@newshost.lanl.gov> dlc@c3serve.c3.lanl.gov (Dale Carstensen) writes:
  13. >I think most of the responses to the original posting in this thread
  14. >have been about 2 separate problems:
  15.  
  16. > 1. nfsd's go into D status (a server-end problem)
  17.  
  18. > 2. automount (or possibly amd, and amd probably has a different
  19. >    problem than automount since amd forks child processes to
  20. >    handle new mounts) blocks, so any process requiring a new mount
  21. >    will go into D status waiting for automount (a client-end
  22. >    problem)
  23.  
  24. >...one thing I haven't seen a load factor go beyond maybe 6 or 8 due to
  25. >these 2 problems, and other messages have mentioned 400+.  But maybe
  26. >problem 2 could generate quite a lot of load -- my discussion below
  27. >involves a rather quiet Saturday morning as the peak load.
  28.  
  29. I've seen this (often) in our config:
  30.  
  31.     Pyramid 90x with OSx4.0 (aka "ancient") acting as disk server to
  32.     Sparcserver 2 with 4.1.2
  33.  
  34. The Pyramid will reboot (for other unrelated causes) and the
  35. the Sparc's nfsd will never see it come back up(?) -- instead, they
  36. get stuck in "D" and the load shoots waaaaay up (I've seen a load of >300
  37. if the Pyramid re-crashes or stays down; eventually the sparc dies too).
  38.  
  39. We don't run any automounter.  Granted the Pyramid's NFS is old, but
  40. the SunOS is new.
  41.  
  42. Note, that if the Pyramid reboots, sometimes the sparc STILL doesn't
  43. notice that it's up, BUT rebooting the P. wakes it right up.
  44.  
  45. >...  There also was a bug in 4.1 that would cause all
  46. >nfsd processes to go into D status when an exported filesystem
  47. >filled up, which was fixed by the NFS jumbo patch for 4.1, I think.
  48.  ^^^^^^^^^
  49.  
  50. Which is frequent at this site -- but note the sparc runs 4.1.2.
  51.  
  52. >Problem 2 I've had daily for 2 days, and now that I understand it,
  53. >here's what is was for me this time.  My NIS master server has been
  54. >hanging processes in D status, especially rlogin daemons.
  55.  
  56. Same here re rlogin's -- to the point that all ptys get used up
  57. until the NFS problem is resolved.
  58.  
  59. My solution is to modify the login procedure so it checks to see if the
  60. home-dir server is up via ping.  (Easy since users log into a shell script.)
  61.  
  62. However, the real problem remains unsolved -- fixes still appreciated...
  63. -- 
  64.  
  65. Andrew Burt                                  aburt@du.edu
  66.  
  67.       "And that, my liege, is how we know the Earth to be banana-shaped"
  68.