home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20114 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  4.2 KB
  1. Path: sparky!uunet!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!usenet.ucs.indiana.edu!indyvax.iupui.edu!harvey
  2. From: harvey@indyvax.iupui.edu
  3. Newsgroups: comp.os.vms
  4. Subject: Re: $add_holder is slow...
  5. Message-ID: <1992Dec30.172938.209@indyvax.iupui.edu>
  6. Date: 30 Dec 92 17:29:37 -0500
  7. References: <1992Dec30.044645.11200@cnplss5.cnps.philips.nl> <6844364@zl2tnm.gen.nz> <C031y8.9Bz@usenet.ucs.indiana.edu>
  8. Organization: Indiana University-Purdue University at Indianapolis
  9. Lines: 76
  10.  
  11. In article <C031y8.9Bz@usenet.ucs.indiana.edu>, mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney) writes:
  12. > We've got about 40,000 users on our cluster, which consists of various newer
  13. > VAXen (the smallest being a 6500, I think).  Anyway, we still keep a separate
  14. > rightslist and uaf on each of the six nodes (I don't run these machines, so
  15. > don't blame me).
  16. >
  17. > Recently, I set about rebuilding the rightslist for the cluster, in order to
  18. > get each node in sync again, and make sure that everybody has only what they
  19. > need.  We have 5 different rights, of which everybody has at least one.  They
  20. > are:
  21. >
  22. >      UCS  -   people who work at UCS
  23. >      STAFF  - staff members
  24. >      FACULTY -faculty members
  25. >      GRAD  -  grad students
  26. >      UGRAD  - undergraduate students
  27. >
  28. > It is possible for people to have more than one, for instance STAFF and UGRAD.
  29. >
  30. > Anyway, we had a spare 8820 sitting around (VMS 5.5-2), so I'm using it.  It
  31. > has 384MB of memory, and we set up a huge cache on it.  We also made the
  32. > account that we are using have high quotas:
  33. >
  34. > Maxjobs:         0  Fillm:       100  Bytlm:        50000
  35. > Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
  36. > Maxdetach:       0  BIOlm:        50  JTquota:       1024
  37. > Prclm:           2  DIOlm:        50  WSdef:         2048
  38. > Prio:            4  ASTlm:        24  WSquo:        32768
  39. > Queprio:         0  TQElm:        10  WSextent:     65535
  40. > CPU:        (none)  Enqlm:      2000  Pgflquo:      40000
  41. >
  42. > Anyway, I copid the rest of the identifiers into the new rightslist, of which
  43. > there were only a few thousand.  Then, I used the cluster UAF to create the
  44. > username rights (using add/ident/user=* in authorize).  I made 5 files, each
  45. > containing in "rightslist" format the UIC of each person who needed that
  46. > right, and the right itself.  So, each line was like such:
  47. >
  48. > right,uic,attr
  49. >
  50. > attr is always 0.  The program loops through the file, reading each line and
  51. > using $add_holder to add the holder.  Here's the layout:
  52. >
  53. > UCS - 500 holders
  54. > STAFF- 4000 holders
  55. > FACULTY- 3000 holders
  56. > GRAD- 8400 holders
  57. > UGRAD- 30000 holders
  58. >
  59. > The amount of time it takes to add these increases rather dramatically.  The
  60. > first 50 (of any set) take maybe 10 seconds.  After around 1000, it takes 10
  61. > or 15 minutes to do 50.  I figure it's because of RMS keeping track of all
  62. > the duplicate keys.  I have everything except UGRAD added, with about 16,000
  63. > left.  At the current rate (50 every 20 minutes), it'll take another 4 days.
  64. > It will probably slow down even more, though, so the time will be longer.
  65. >
  66. > Does anyone know a way to speed this up?  Pretty much anything is possible
  67. > with the machine that we are using.  Thanks in advance.
  68.  
  69. Dramatic is indeed the word!  We had a very similar situation here about
  70. a year ago, but only with about 1/10th the users.  If you look at the
  71. organization of the rightlist file, the problem becomes clear.  With
  72. thousands of users each holding one of a small set of "user-type" i.d.s,
  73. you end up with thousands of duplicate keys in an index slot, which are
  74. searched sequentially for an update.  We ended up storing the user-type
  75. information in a separate file indexed by username (you could probably
  76. store it in the "user info" field of the UAF now, which wasn't available
  77. to us at the time).  For all logins a privileged program is run that does
  78. whatever we want with this information (it defines an executive mode job
  79. logical here at our site, however, maybe you could use it to grant the
  80. appropriate identifier to the process at yours?).
  81.  
  82. Good luck.  If you need more info call or write me (or Mark Wood) at your
  83. local friendly IUPUI campus...
  84. --
  85. James Harvey    IUPUI OIT Technical Support/Networks
  86. harvey@iupui.edu  harvey@indiana.edu  uucp:iugate!harvey  bitnet:harvey@indyvax
  87.