HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: dbc_max_pct
Operating System - HP-UX
1833874
Members
1991
Online
110063
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
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
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- 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
02-26-2007 02:18 AM
02-26-2007 02:18 AM
dbc_max_pct
I have a rp7400 with 4Gig of ram. After looking at my memory usage I found that I was extremely low on memory for users. I looked at my dbc_max_pct setting and it was set to 50. I know that this means that I was using 50% of my memory for buffcache which is not really recommended depending on the situation. I changed the kernel parameter to 13% and all my processes took longer.
I was running and capturing a sar report so that I could see if the change had done any good and it looks like I went the wrong way with my dbc_max_pct.
although my %rcache went down about 10% my bread/s went through the roof.
Is this normal?
Any comments or recommendations?
Any input would be greatly appreciated.
I was running and capturing a sar report so that I could see if the change had done any good and it looks like I went the wrong way with my dbc_max_pct
although my %rcache went down about 10% my bread/s went through the roof.
Is this normal?
Any comments or recommendations?
Any input would be greatly appreciated.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-26-2007 02:34 AM
02-26-2007 02:34 AM
Re: dbc_max_pct
Note that you were getting 100% read-cache hit rates with dbc_max_pct at 50%. This means that you were doing almost no physical reads. When you reduced the buffer cache to more reasonable values then number of physical reads increased. When you do a ratio of a moderate number to what was a very small number, that change becomes very large but it does not necessarily mean anything is wrong. It's very difficult to make meaningful comparisons without knowing the sampling interval. You numbers may simply be a small sample set. Gather your metrics over a period of at least a few minutes and make sure that you are comparing apples to apples.
One thing that really strikes me is the very high number of logical i/o's with a ralatively small number of physical i/o's. This means that your code is rereading data that it really already "knows" and suggests that better algorithms are needed. If this is SQL then some better coding should be done.
The "correct" value for your buffer cache size is "it depends" but if you can't better tune your code then your perform,ance metrics indicate that you should bump the buffer cache up to perhaps 25% but I strongly suggest that you have a look at youir application code.
One thing that really strikes me is the very high number of logical i/o's with a ralatively small number of physical i/o's. This means that your code is rereading data that it really already "knows" and suggests that better algorithms are needed. If this is SQL then some better coding should be done.
The "correct" value for your buffer cache size is "it depends" but if you can't better tune your code then your perform,ance metrics indicate that you should bump the buffer cache up to perhaps 25% but I strongly suggest that you have a look at youir application code.
If it ain't broke, I can fix that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-26-2007 02:36 AM
02-26-2007 02:36 AM
Re: dbc_max_pct
Timothy,
sadly, tuning is a slow and delicate process.
Please read:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=252307
It has a few tuning links as well.
What is your dbc_min_pct set to ?
Note: The timestamp is the same on your sar output ?
sadly, tuning is a slow and delicate process.
Please read:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=252307
It has a few tuning links as well.
What is your dbc_min_pct set to ?
Note: The timestamp is the same on your sar output ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-26-2007 02:57 AM
02-26-2007 02:57 AM
Re: dbc_max_pct
Thank you all for your quick response!
My polling on the sar -b 1 is 60. Not very long but I really didn't expect this big of an inpact on the processing time. I know that the code is in most places poorly written, but there is no way to rewrite it.
So, I guess my best option is what Clay recommended and increase my dbc_max_pct up to 25% and see what happens. If this does not help I will have to go back to 50%. This of course would only be until I can get some more memory in the machine.
Thanks again for your input!
Tim
My polling on the sar -b 1 is 60. Not very long but I really didn't expect this big of an inpact on the processing time. I know that the code is in most places poorly written, but there is no way to rewrite it.
So, I guess my best option is what Clay recommended and increase my dbc_max_pct up to 25% and see what happens. If this does not help I will have to go back to 50%. This of course would only be until I can get some more memory in the machine.
Thanks again for your input!
Tim
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP