home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20173 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  3.9 KB
  1. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!spool.mu.edu!agate!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: Re: $add_holder is slow...
  5. Message-ID: <9212312136.AA06438@uu3.psi.com>
  6. Date: 31 Dec 92 20:23:41 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 71
  11.  
  12.  
  13.     [M Darrin Chaney writes:]
  14.     We've got about 40,000 users on our cluster, which consists of various
  15.     newer VAXen (the smallest being a 6500, I think).  Anyway, we still
  16.     keep a separate rightslist and uaf on each of the six nodes (I don't
  17.     run these machines, so don't blame me).
  18.  
  19.     Recently, I set about rebuilding the rightslist for the cluster, in
  20.     order to get each node in sync again, and make sure that everybody has
  21.     only what they need.  We have 5 different rights, of which everybody
  22.     has at least one.... 
  23.  
  24.     Anyway, we had a spare 8820 sitting around (VMS 5.5-2), so I'm using
  25.     it.  It has 384MB of memory, and we set up a huge cache on it.  We
  26.     also made the account that we are using have high quotas....
  27.  
  28.     Anyway, I copied the rest of the identifiers into the new rightslist,
  29.     of which there were only a few thousand.  Then, I used the cluster UAF
  30.     to create the username rights (using add/ident/user=* in authorize).
  31.     I made 5 files, each containing in "rightslist" format the UIC of each
  32.     person who needed that right, and the right itself.  So, each line was
  33.     like such:
  34.  
  35.     right,uic,attr
  36.  
  37.     attr is always 0.  The program loops through the file, reading each
  38.     line and using $add_holder to add the holder....
  39.  
  40.     The amount of time it takes to add these increases rather
  41.     dramatically.  The first 50 (of any set) take maybe 10 seconds.  After
  42.     around 1000, it takes 10 or 15 minutes to do 50.  I figure it's
  43.     because of RMS keeping track of all the duplicate keys.  I have
  44.     everything except UGRAD added, with about 16,000 left.  At the current
  45.     rate (50 every 20 minutes), it'll take another 4 days.  It will
  46.     probably slow down even more, though, so the time will be longer.
  47.  
  48.     Does anyone know a way to speed this up?  Pretty much anything is
  49.     possible with the machine that we are using.  Thanks in advance.
  50.  
  51.     [James Harvey responds:]
  52.     Dramatic is indeed the word!  We had a very similar situation here
  53.     about a year ago, but only with about 1/10th the users.  If you look
  54.     at the organization of the rightlist file, the problem becomes clear.
  55.     With thousands of users each holding one of a small set of "user-type"
  56.     i.d.s, you end up with thousands of duplicate keys in an index slot,
  57.     which are searched sequentially for an update.  We ended up storing
  58.     the user-type information in a separate file indexed by username (you
  59.     could probably store it in the "user info" field of the UAF now, which
  60.     wasn't available to us at the time).  For all logins a privileged
  61.     program is run that does whatever we want with this information (it
  62.     defines an executive mode job logical here at our site, however, maybe
  63.     you could use it to grant the appropriate identifier to the process at
  64.     yours?).
  65.  
  66. Mr. Harvey's solution is a nice one, though it does mean that such services
  67. as $FIND_HELD will not work as expected.
  68.  
  69. I'd suggest that Mr. Chaney's problem calls for stepping a bit outside the
  70. pale of officially supported steps for a simple solution.  The format of the
  71. RIGHTSLIST file is quite trivial.  Create a couple of sample entries covering
  72. all the kinds of types you'll be adding.  Then use CONVERT to create a
  73. sequential file from the resulting RIGHTSLIST.  Use the entries you have to
  74. create all the rest of the entries you need.  Finally, CONVERT back to the
  75. original format.  CONVERT builds the index structures intelligently; it
  76. doesn't add the records one at a time.  It should run quite quickly.
  77.  
  78. (You may want/need to sort on the primary key before converting back - it's
  79. been too long since I did this kind of thing for me to remember....)
  80.  
  81.                             -- Jerry
  82.  
  83.