home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / hp / 9681 < prev    next >
Encoding:
Text File  |  1992-08-25  |  8.1 KB  |  154 lines

  1. Newsgroups: comp.sys.hp
  2. Path: sparky!uunet!news.uiowa.edu!icaen.uiowa.edu!dsiebert
  3. From: dsiebert@icaen.uiowa.edu (Doug Siebert)
  4. Subject: Re: Shared libraries have me very confused!
  5. Sender: news@news.uiowa.edu (News)
  6. Message-ID: <1992Aug25.213925.6840@news.uiowa.edu>
  7. Date: Tue, 25 Aug 1992 21:39:25 GMT
  8. References: <1992Aug25.053800.24067@news.uiowa.edu> <7371254@hpfcso.FC.HP.COM>
  9. Nntp-Posting-Host: grind.isca.uiowa.edu
  10. Organization: ISCA
  11. Lines: 141
  12.  
  13. In article <7371254@hpfcso.FC.HP.COM> mjs@hpfcso.FC.HP.COM (Marc Sabatella) writes:
  14. >In comp.sys.hp, dsiebert@icaen.uiowa.edu (Doug Siebert) writes:
  15. >
  16. >> I've got an application running on an HP 9000/710 with 48M of RAM under HP-UX
  17. >> 8.07 that is run by up to 80 users at a time (and adding more would always be
  18. >> an advantage) each running a separate copy of the application.
  19. >
  20. >When you say "running a separate copy", do you literally mean a separate copy
  21. >of the executable file?  If so, step one is to make sure everyone runs the same
  22. >copy of the application, so you can shared text.
  23.  
  24. No, I meant each runs in a separate process.  They are all run from the same
  25. i-node (except at times when the software is updated and there is a transition
  26. period during which two copies are running, but that's not a major concern I
  27. don't think)
  28.  
  29. >> I recompiled
  30. >> again, this time with the option "-Wl,-a,archive" to the linker, which should
  31. >> use the archive libraries instead of the shared libraries.  I figured I would
  32. >> be using up more real memory by not using the shared libraries, but am in fact
  33. >> using less!  How can this be?!
  34. >
  35. >How did you measure real memory usage?  I don't think any of the available
  36. >tools like "ps", "monitor", "glance", or anything using "pstat" are
  37. >particularly smart about shared libraries.  I can easily imagine that they
  38. >would think each instantiation of the program was using its own copy of the
  39. >library.
  40.  
  41. I used 'monitor' to get this information.  I went by what it told me both by
  42. analyzing processes individually and giving me their RSS size, and by the
  43. global statistics giving the overall amount of memory usage.  With 75 users
  44. I would dig into the first couple megabytes of swap space, though beforehand
  45. none was used.  I assume this means that at that point physical memory has
  46. been exhausted and inactive pages are being swapped out.  At some point pages
  47. that are just *less* active will be swapped out, and then I'll see performance
  48. decrease, correct?
  49.  
  50. >If you are counting swap space, then you should *not* expect to see usage go
  51. >down with shared libraries.  Swap is never used for text segments (it is paged
  52. >in directly from the filesystem), so only data is an issue.  With archive
  53. >libraries, a program will have swap reserved/allocated for all the data in the
  54. >program, plus all the data copied out of archives libraries.  A typical Motif
  55. >program accesses only 60% (or some other relatviely small amount) of the data
  56. >in the libraries it is linked with, so only that amount of data is copied into
  57. >the program.  With shared libraries, however, you are allocated swap for all
  58. >the data in all the libraries you are linked with.  Plus, you are allocated
  59. >swap for the data structures used by the dynamic loader.  Thus, a program
  60. >typically needs more swap space when linked with shared libraries than archive
  61. >libraries.  This does not mean it needs more real memory, however - most of
  62. >the swap is allocated "just in case", but still only those pages that are used
  63. >are allocated in memory, so a given process would use almost exactly the same
  64. >amount of memory with shared as archive libraries.  Possibly a little more due
  65. >to fragmentation of the data it is using (the 60% of the data it uses from a
  66. >library may be scattered over 80% of the library's pages).
  67. >
  68. >> 1)  How come NOT using shared libraries allowed my application to use up less
  69. >> real memory per process?  If this is so, what is the point of shared libraries?
  70. >
  71. >Possibility number one is that the program really isn't using less real memory
  72. >with archive libraries - the tools that report memory usage may be flawed, or
  73. >you may have been measuring the wrong thing (swap space).  As I observed above,
  74. >any given process will appear to need slightly more (due to fragmentation, and
  75. >dynamic loader overhead) real memory with shared libraries than with archive
  76. >libraries.  The savings comes as soon as there is sharing - memory pages used
  77. >for library text can be shared processes.  But note that program text is shared
  78. >anyhow.  If your program is linked against libfoobar, and it is the only
  79. >program linked against libfoobar, then its text pages will be shared among all
  80. >users regardless of whether it is a shared library or not.  The shared library
  81. >is only a win if some other program is also linked against libfoobar - then
  82. >the pages will be shared among all users of both programs, rather than having
  83. >one set of pages for users of one program and another set for users of the
  84. >other.
  85. >
  86. >To recap, you should expect any individual process to need significantly more
  87. >swap when using shared libraries, and slightly more memory.  If you have
  88. >several invocations of the same program at once (as you do), this only
  89. >magnifies those differences.  The savings come when you also have *other*
  90. >programs that use the same libraries.
  91.  
  92. OK, I think I understand what I was missing about shared libraries.  Since this
  93. application is the major usage of this machine, and I'm not really concerned if
  94. it is a couple hundred K larger in size, I should compile with the archive
  95. libraries instead of the shared libraries, to avoid the overheard of swap, real
  96. memory, and speed associated with shared libraries, which are intended to save
  97. disk space over the many applications over the whole system.
  98.  
  99. >> 2)  How can I compile my application so as to make it share memory better among
  100. >> the 80 copies of it that may be simultaneously running?  Is there something
  101. >> big I'm missing?  Or would I have to tear it apart and put most of its
  102. >> functions in a library of my own creation?  (And would I then want to make that
  103. >> shareable or not?)
  104. >
  105. >Assuming the application really is shared - all 80 users are running from the
  106. >same i-node, I think you've done all you can.  If you're wondering just how
  107. >much difference the libraries are making, try the following experiment:
  108. >
  109. >1. link your application normally, with something that presumably looks like:
  110. >
  111. >    cc -o program.shared $(OBJS) $(LIBS)
  112.  
  113. 107889 + 1852 + 18964 = 128705
  114.  
  115. >2. link it with archive libraries:
  116. >
  117. >    cc -o program.archive $(OBJS) -Wl,-a,archive $(LIBS)
  118.  
  119. 191028 + 12220 + 43712 = 246960
  120.  
  121. >3. link it with no libraries (result will not be executable):
  122. >
  123. >    cc -o program.none $(OBJS)
  124.  
  125. 105692 + 1524 + 15468 = 122684
  126.  
  127. >Now run "size" on each of the resultant executables, and compare.  #2 and #3
  128. >should be similar - #2 should be slightly larger due to shared library
  129. >overhead.  #1 should be larger.  If it is "a lot" larger, it means you are
  130. >using a lot of library code, and any tuning should indeed be in your use of
  131. >libraries.  If is "only a little" larger, then most of the memory you are using
  132. >is in your application code, and the libraries don't really make much
  133. >difference.
  134.  
  135. I'm guessing you mistyped and meant #1 and #3 should be similar, since #2 has
  136. the extra overheard of *not* using shared libraries.  But #2 does take up less
  137. memory, according to monitor (though you say that may be flawed)  The only
  138. library other than libc I am using is the curses/termcap library, so there is
  139. not much tuning I can do in that respect.  I do use the -DMINICURSES option
  140. when compiling/linking, so I guess I'm cutting that library down as much as
  141. possible as it is.
  142.  
  143. Thanks for your help!
  144.  
  145.  
  146. -- 
  147. /-----------------------------------------------------------------------------\
  148. | Doug Siebert                             | "I don't have to take this abuse |
  149. | Internet:  dsiebert@icaen.uiowa.edu      |  from you - I've got hundreds of |
  150. | NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
  151. |     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
  152. \-----------------------------------------------------------------------------/
  153. Hi, I'm a .signature worm.  I've already copied myself into your .signature.
  154.