home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / admin / 6261 < prev    next >
Encoding:
Text File  |  1992-11-18  |  2.7 KB  |  57 lines
  1. Newsgroups: comp.unix.admin
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!munnari.oz.au!metro!basser.cs.su.oz.au!yar
  3. From: yar@cs.su.oz.au (Ray Loyzaga)
  4. Subject: Re: Advice on Large UNIX installations please
  5. Reply-To: yar@cluster.cs.su.oz.au (Ray Loyzaga)
  6. Organization: Basser Dept of Computer Science, University of Sydney, Australia
  7. Date: Wed, 18 Nov 1992 23:10:15 GMT
  8. Message-ID: <1992Nov18.231015.23553@cs.su.oz.au>
  9. Keywords: Resource Quotas
  10. References: <1992Nov17.154512.21468@ccsun.strath.ac.uk>
  11. Sender: news@cs.su.oz.au (News)
  12. Lines: 43
  13.  
  14. In article <1992Nov17.154512.21468@ccsun.strath.ac.uk> craa27@ccsun.strath.ac.uk writes:
  15. >At Strathclyde we are discussing the pros and cons of moving from a
  16. >many small discless machines type of setup to one with Xterminals
  17. >and a few large UNIX boxex to run applications.
  18. >
  19. >We already run a DEC VMS central service which is laughingly referred
  20. >to as our "Mainframe" installation. It has the nice feature that
  21. >resources such as memory and cpu cycles can be limited for each user.
  22. >
  23. >Our worry is that users of large packages may hog a large UNIX machine,
  24. >and we would like to be able to place quotas on the resources in a similar
  25. >fashion as on our VMS service. We would also like to be able to run a batch
  26. >queue in the evening and at weekends.
  27. >
  28. >I would be very grateful if anybody could mail me details of facilities to
  29. >place quotas on users run time resources on any UNIX systems. 
  30. >Details of any existing batch systems would be equally gratefully recieved.
  31. >
  32. >Many thanks in advance
  33. >
  34. >Steve Holmes (Strathclyde Uni Computing Service)
  35.  
  36. Easy, buy any system that people are willing to sell you that can
  37. both cope with the load and have educational source availablity.
  38. Then we will GIVE you a system that implements a hierarchical
  39. fair share scheduler (this gets rid of CPU hogs) and a rather complete
  40. set of per-user/group limits, i.e. procs/mem/disk/connect/network/printers
  41. .... 
  42. We currently use MIPS systems because they actually shipped the source
  43. before they shipped the system (this may change due to SGI) and
  44. run a system exactly like what you are thinking of moving to.
  45. 220+ Xterms, 12 CPU servers. We change the servers every 18 months or so,
  46. sell the old ones while they are worth money, and buy the next generation
  47. as soon as they are available. This has reduced our equipment budget
  48. requirements by a whole lot.
  49.  
  50. If you want more details just send me some mail.
  51. Of course we tried getting some manufacturers to run this code
  52. (it is only about 40kb worth of text) but they don't think there
  53. is a market desire for a system that doesn't grind to a halt because
  54. some bozo decided to run 50 infinite loops. I seem to remember quite
  55. a few requests along these lines lately, so maybe the tide is turning.
  56.  
  57.