home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sun / admin / 5632 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  2.4 KB
  1. Path: sparky!uunet!pmafire!news.dell.com!swrinde!elroy.jpl.nasa.gov!ucla-cs!ucivax!megatek!randy
  2. From: randy@ninja.megatek.uucp (Randy Davis)
  3. Newsgroups: comp.sys.sun.admin
  4. Subject: Re: Amd is not perfect
  5. Message-ID: <1992Aug18.210041.18928@megatek.uucp>
  6. Date: 18 Aug 92 21:00:41 GMT
  7. References: <1992Aug5.231434.20156@trl.oz.au> <aegl.713467376@ossi.com> <cornell.714092734@vivaldi>
  8. Sender: randy@megatek.uucp (Randy Davis)
  9. Reply-To: megatek!randy@uunet.uu.net
  10. Organization: Megatek Corporation, San Diego, California
  11. Lines: 37
  12.  
  13. In article <cornell.714092734@vivaldi> cornell@syl.dl.nec.com writes:
  14. |Jumping into this thread a little late but just wanted to contribute
  15. |a "me too".  I'm running SunOS 4.1.1 on a network of Sun4s.  I'm using
  16. |a combination of regular NFS mount and Sun's automount to mount file
  17. |systems from a Sun 4/470 w/128M RAM.  Every few days, I see the problem
  18. |of the load average going up to around 6-12 and hanging there for a
  19. |while.  A look at 'top' shows nfsd's sitting up at top.  After a bit
  20. |it all goes back to normal.  I can't reproduce it but it happens
  21. |quite often.
  22.  
  23.   That's not a problem with any of your mounts or NFS, most likely, but
  24. more likely one of your client machines doing a recursive directory/file
  25. search like a "find", "rm -r", etc. over NFS...  Another likely culprit is
  26. someone doing high-speed small-size writes to a file (such as from a C-program)
  27. over NFS - this can take over all of your NFS daemons also, and can really
  28. cause trouble if it is writing into a partition that has quota's enabled
  29. and/or the filesystem is close to full.
  30.  
  31.   Next time it happens, fire up any network monitor utility (I use "ethertop")
  32. that will show you where packets are coming from that are destined for and
  33. originating from the machine that shows the NFS deamons taking up a high load.
  34. Once you locate the culprit machine, log into that machine and do a "w" or a
  35. "ps -agxu" (sometimes "w" won't show it) to find out who is running the
  36. offending program.
  37.  
  38.   Then tell them to "QUIT IT"... :-)
  39.  
  40.   Of course, you might want to make sure that *you* aren't doing it via a cron
  41. job that is improperly constructed - like a "find" without an "-xdev" option
  42. or somesuch.
  43.  
  44.   It used to happen all the time, here, and we have a network of about 140
  45. Sun4s (all flavors) and sun3s.
  46.  
  47. Randy Davis                UUCP: randy@megatek.com
  48. Network and System Administrator          megatek!randy@uunet.uu.net
  49. Megatek Corporation, San Diego, California    ucsd!megatek.uucp!randy
  50.