home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / sun / admin / 6328 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  3.1 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.sys.sun.admin
  4. Subject: Re: per-process descriptor table sizes?
  5. Message-ID: <14635@auspex-gw.auspex.com>
  6. Date: 15 Sep 92 01:33:05 GMT
  7. References: <BuLByM.JII@usenet.ucs.indiana.edu>
  8. Sender: news@auspex-gw.auspex.com
  9. Organization: Auspex Systems, Santa Clara
  10. Lines: 76
  11. Nntp-Posting-Host: bootme.auspex.com
  12.  
  13. (If anybody's gathering up postings for inclusion in an FAQ some day -
  14. there isn't an FAQ for any of the "comp.sys.sun" groups - this is one
  15. that belongs there.)
  16.  
  17. >On a Sparc II running SunOS 4.1.2, how does one increase the
  18. >per-process descriptor table size?  The default is 64.
  19. >
  20. >In param.h, NOFILE is defined to be 256, so I doubt it's that
  21. >value despite the comment that indicates so.
  22.  
  23. Well, the *hard* limit *is* 256.
  24.  
  25. >In user.h,
  26. >changing NOFILE_IN_U from 64 to 128 and rebuilding the kernel
  27. >has had no effect.
  28.  
  29. It wouldn't have an effect unless you recompiled those source files that
  30. use the U area table of file descriptors, and if you do that, you have
  31. to compile every *other* kernel source file that uses the U area, *and*
  32. any user-mode code that knows the shape of the U area.
  33.  
  34. (I.e., changing an arbitrary parameter in a header file and rebuilding
  35. your kernel doesn't work, unless you have full source or happen to be
  36. lucky enough to have changed a parameter that's used only by files for
  37. which you get source in a standard distribution.)
  38.  
  39. The *soft* limit is 64.
  40.  
  41. From the use of "hard" and "soft", you may suspect that this is a
  42. resource limit, just like the core dump size, the file size, etc.
  43.  
  44. You'd be correct in so suspecting; in SunOS 4.1[.x] and SunOS 5.0 (hell,
  45. in *any* SVR4 release worthy of the name), the file table size is a
  46. resource limit.
  47.  
  48. As such, you change it with:
  49.  
  50.     the "limit" command in the C shell;
  51.  
  52.     the "ulimit" command in the Bourne or Korn shells *IF* you have
  53.     a Bourne or Korn shell with a "ulimit" command that provides
  54.     access to those limits - the Bourne shell that comes with SunOS
  55.     4.1[.x], and probably most Korn shells built for 4.1[.x], don't,
  56.     but the Bourne and Korn shells that come with SVR4 do;
  57.  
  58.     the "getrlimit()" and "setrlimit()" calls in a C program.
  59.  
  60. For example:
  61.  
  62.     auspex% limit
  63.     cputime         unlimited
  64.     filesize        unlimited
  65.     datasize        524280 kbytes
  66.     stacksize       8192 kbytes
  67.     coredumpsize    unlimited
  68.     memoryuse       unlimited
  69.     descriptors     64 
  70.     auspex% limit descriptors 256
  71.     auspex% limit
  72.     cputime         unlimited
  73.     filesize        unlimited
  74.     datasize        524280 kbytes
  75.     stacksize       8192 kbytes
  76.     coredumpsize    unlimited
  77.     memoryuse       unlimited
  78.     descriptors     256 
  79.  
  80. If you have a program that should *always* have the limit cranked up, do
  81. the "getrlimit()" and "setrlimit()" calls within the program, or run the
  82. program within a C shell wrapper.
  83.  
  84. You can't raise the hard limit, at least in SunOS 4.1[.x].  It's stuck
  85. at 256 (unless, I think, you have Sun's Database Excelerator, or
  86. whatever the heck they call it, in which case I think it's cranked up to
  87. 1024).  You may be able to crank the hard limit past the default of 1024
  88. in SVR4, or at least in the SunOS 5.0 version of SVR4.
  89.