- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: info about shared libs
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-12-2007 06:59 PM
тАО10-12-2007 06:59 PM
info about shared libs
I have an application with around 150 shared libs and when I launch the application it takes around 500MB!!!!
of course it looks logical seeing the size of the shared libs. I was wondering what part of the shared lib constitutes the space in memory when loded. Is there a way to reduce the memory consumption on launch.
I must admit that its not very much possible to reduce the number of shared libs getting loaded at launch time.
Does combining the shared libs and reducing the number help?
The binaries are built on PA_RISC 11.11 and the code is mainly made of C and C++ compiled using A03.65 with +O3 optimization
TIA
Satya
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-13-2007 08:02 AM
тАО10-13-2007 08:02 AM
Re: info about shared libs
I suspect that startup times can be quite long as well. One thing that might help is a combination of static (archive) libraries and shared libraries. That would not reduce the memory footprint but it would reduce the load times and make maintenance easier.
One thing that might help your situation is the use of shared memory and a separate initialization program. I've written a number of applications which took many tens of seconds to initialize and were quite large because each instance had to setup tons of data before actually starting to work on a given task. The fix for that class of applications is to have a separate initialization program that reads in the data and loads a shared memory segment and then exits. The "real" application then only has to attach this pre-configured segment and is ready to go. That technique turned a 3 minute startup into about 5 seconds and greatly reduced the footprint because only the initialization program needed the initialization code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-13-2007 07:39 PM
тАО10-13-2007 07:39 PM
Re: info about shared libs
What does the sum of the values of size(1) show for the executable and all of the shlibs?
Is the 500 Mb all data+bss? If text, that's shared so don't worry. Data is multiplied by the number of users running the application.
>what part of the shared lib constitutes the space in memory when loaded. Is there a way to reduce the memory consumption on launch?
There is the text space that contains code and read only data. It also contains the shlib info. Then there is the data area, which includes dld info on where each symbol is located.
By compiling with +Olit=all or +ESlit may move RW data to RO data.
>Does combining the shared libs and reducing the number help?
Possibly. Each shlib area is rounded up to 4Kb pages or larger. You could also try linking with -Wl,+mergeseg.
>with +O3 optimization
That may increase the size of text so that's not a big issue.
>Clay: The entire shared library is not loaded
But the data part takes up swap space.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-14-2007 10:17 PM
тАО10-14-2007 10:17 PM
Re: info about shared libs
Thanks for the pointes. I missed to inform you one thing, that my application is a 32bit one and if 500MB goes just to launch, then I am left with a couple of GBs (that after enabling the +q3p).
Sorry I didn't give the output of the size command in the first place
running size on all my sl files, tells that around 350 MB is the text size, 140 MB is the data and another 10MB of bss.
and currently the executable is enabled with +q3p option
I guess the +ESlit is the default and I doing a chatr +mergeseg enable on all the .sl didn't change the scenario
And using the shared memory for initialization of the app is interesting and I would see how I can make use of this idea.
Thanks again for the suggestions
Satya
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-14-2007 11:21 PM
тАО10-14-2007 11:21 PM
Re: info about shared libs
>running size on all my sl files, tells that around 350 MB is the text size, 140 MB is the data and another 10MB of bss. And currently the executable is enabled with +q3p option\
You don't need +q3p if you only need 140 + 10 Mb of data. Of course it depends on how much additional heap you use.
>I guess the +ESlit is the default
Not for C.
>I doing a chatr +mergeseg enable on all the .sl didn't change the scenario
That allows large pages to be used for performance. It could slow startup.
>And using the shared memory for initialization of the app is interesting
You can't use shared memory to store C++ objects with virtual tables.