Some additional info: Example output from the "SHRLIBRGN contents" rexx is given below:
Usage Meg Used-Unused-Pgs Pathname 44 1 40 216 /CTQ131/usr/lpp/java/J5.0/bin/libnet.so 44 1 142 114 /CTQ131/usr/lpp/java/J5.0/bin//libjclscar_23.so 44 1 63 193 /CTQ131/usr/lpp/java/J5.0/bin//libj9vrb23.so 44 1 81 175 /CTQ131/usr/lpp/java/J5.0/bin//libj9jvmti23.so 44 1 67 189 /CTQ131/usr/lpp/java/J5.0/bin//libj9dyn23.so 44 2 260 252 /CTQ131/usr/lpp/java/J5.0/bin//libj9gc23.so 44 7 1562 230 /CTQ131/usr/lpp/java/J5.0/bin//libj9jit23.so 44 1 73 183 /CTQ131/usr/lpp/java/J5.0/bin//libj9dmp23.so 44 1 89 167 /CTQ131/usr/lpp/java/J5.0/bin/libj9prt23.so 44 1 92 164 /CTQ131/usr/lpp/java/J5.0/bin/libjava.so 44 1 173 83 /CTQ131/usr/lpp/java/J5.0/bin/libj9vm23.so Usage is the number of tasks that are making use of that particular entry. Meg is the number of 1Mb slots in SHRLIBRGN that this entry is using (yes, even a 4Kb object will use a 1Mb slot!) Used & Unused pages, indicates how many 4Kb pages are used/unused within that entry. Pathname gives the last 64 characters of the pathname, thus may need a bit of detective work to establish the exact pathname, if it comes from a particularly deep directory nesting. Having refreshed my memory a little, I think one of my 'plans of attack' to maximise the effectiveness of SHRLIBRGN was to target small objects (in terms of turning their shrlib 'bit' off), as little objects would use little extra storage in an address space's private if it were to be loaded there (where a 4Kb object would really only use 4Kb). But as previously mentioned, my plans to try & micro-manage this environment, all went out the window. Something else to be aware of, is that even if EXACTLY the same shareable object binaries are being used, if they are being loaded from different paths (as can be the case for websphere installs for example), then they are treated as separate SHRLIBRGN entries. On 5 November 2011 21:26, Mike Schwab <[email protected]> wrote: > On Sat, Nov 5, 2011 at 3:25 PM, Graham Harris <[email protected]> wrote: > <deleted> > > Would be nice if IBM could allow this to be managed a little better than > > the first-come-first-served principle, although I cant think right now > how > > it could easily be done any different, I must admit! > > Moving SHRLIBRGN above the bar would make this a non-issue of > > course.......that would definitely get my vote! > <deleted> > > Maintain a Peak User count for each module in a file on the system > (directory or ZZCOUNTS of that library?) Don't put into shared region > unless peak was >= 2 (or higher). Total of modules with peaks above > each value could be displayed. > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
