- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- Physical Memory management - Performance problems
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
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
тАО11-16-2006 03:37 AM
тАО11-16-2006 03:37 AM
Physical Memory management - Performance problems
My software run some java applications (everything on the server) sending them to several X clients (pc workstations running Exceed, linux workstations, ...).
I am monitoring the system activity with 'dxsysinfo'.
I have noticed that when I start to launch java applications, "In-use memory" starts to grow (as it would be expected).
But when "In-use memory" reaches 50%, then it suddenly drops and get stuck to around 25 %, starting to use swap a lot more!
After that moment, the java applications behaviour in the workstations drops in terms of performance (freezing for a long time), I believe because of the greater swapping.
Why does the system don┬┤t allow a greater occupancy of physical memory? Why at some moment it drops to 25% usage, and get stuck to that value?
Is it possible to change that policy, for instance, changing some kernel parameters?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-16-2006 04:57 AM
тАО11-16-2006 04:57 AM
Re: Physical Memory management - Performance problems
sysconfig -q vm vm_swap_eager
sysconfig -q vm |grep free
And when the "problem" starts:
swapon -s
vmstat 5 (At least 20 samples)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-17-2006 07:49 AM
тАО11-17-2006 07:49 AM
Re: Physical Memory management - Performance problems
Thank you for the help.
Hugo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-21-2006 12:07 AM
тАО11-21-2006 12:07 AM
Re: Physical Memory management - Performance problems
Set vm_swap_eager to 0, to do that, do the following. Create a file called /tmp/sysconfig.stanza like this:
vm:
vm_swap_eager = 0
Run the command:
sysconfigdb -m -f /tmp/sysconfig.stanza
Reboot the system.
From the output I can see that your system is swapping, if your system continues swapping after this modification, probably you don't have enough RAM memory to support your load, or some application is using more memory than normal.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-21-2006 05:50 AM
тАО11-21-2006 05:50 AM
Re: Physical Memory management - Performance problems
It looks like dxsysinfo is confused or gives confusing output (I never use the tool). Try alternatives: collect+collgui; the vmstat you show; or vmubc perhaps.
The VMSTAT output clearly shows a system which ran out of free memory, and the performance knee you describe matches that.
Free pages dropping to a fre hundred, and pout starting at the same time indicated overcommited memory.
You can probably gain a little room by lowering vm: ubc_min from the 10 it appears to be down to 3 or 4, but that in turn may hurt performance.
You need either to - buy more memory! - reduce the load, or - reduce the java memory usage by setting lower per process upper limites and chosing a more aggressive garbage collecting method/setting.
Normally I like lazy swapping (eager=0), but here I don;t think it will help, and it may put the system stability at risk if the memory remains overcommited.
Hth,
Hein van den Heuvel
HvdH Performance Consulting