- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Low Buffer cache Hit Ratio's & I/O bottlenecks
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
тАО05-19-2002 04:22 PM
тАО05-19-2002 04:22 PM
Reviewing the previous weeks performance stats, I have noticed that Cache Hit % is only averaging about 75%.
Today the DBAs are copying large oracle datafiles from 1 filesystem to another. Cache Hit % is now averaging about 50%.
System is connected via a SAN to an EMC Symmetrix.
System is configured with a fixed Buffer cache of 200M. (System has 6GB of phys memory) and we have no memory or CPU bottlenecks.
As a result of the all the copies the system appears to be bottlenecked on I/O (Processes blocked on resources averaging about 6-8). It takes a long time to login and even running simple 'bdf', takes about 20-30secs.
Is there likely to be any benefit in increasing the Buffer Cache or is there anything else I should be looking at??
Thanks for any help.
Cheers
Con
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-19-2002 04:48 PM
тАО05-19-2002 04:48 PM
Re: Low Buffer cache Hit Ratio's & I/O bottlenecks
These two links provide some good information. I generally use the buffer cache somewhere over 300Mb, but not a fixed value.
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x6752a22831ebd5118ff40090279cd0f9,00.html
and
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xf49203bbece8d5118ff40090279cd0f9,00.html
HTH
~Michael~
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-19-2002 05:13 PM
тАО05-19-2002 05:13 PM
Re: Low Buffer cache Hit Ratio's & I/O bottlenecks
I have read alot of the discussions in the past on buffer cache sizing, however I guess what im really trying to ask is if the current cache hit %'s are a cause for concern (especially since we are using a EMC symmetrix with its own cache.). Also I presume any disk to disk copies will stil use the buffer cache.
Cheers
Con
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-19-2002 11:19 PM
тАО05-19-2002 11:19 PM
Re: Low Buffer cache Hit Ratio's & I/O bottlenecks
"Your system appears to be blocked on I/O while doing large databse copies" - of course its going to be blocked on I/O !! What else would it be blocked on ? Doing large file copies is going to max out the I/O interface to your EMC for certain - thats the bottleneck. If youre running fibre then the speed of the copy will be limited by the speed of the fibre card on the HP. The EMC with tons of cache and quick disks can go a lot faster - but its designed to cope with multiple hosts all doing copies at the same time.
Your buffer cache hit ratio only being about 50% is absolutely fine, nothing to worry about - because the copy is constantly loading new data into the cache before it goes to the new disk(s) and the cache is designed to have a high hit ratio if it has the same data kept in it (ie. an application program - once loaded into cache if multiple users access it then its always in cache after the first load).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-20-2002 01:03 AM
тАО05-20-2002 01:03 AM
Re: Low Buffer cache Hit Ratio's & I/O bottlenecks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-20-2002 01:17 AM
тАО05-20-2002 01:17 AM
Re: Low Buffer cache Hit Ratio's & I/O bottlenecks
interesting info. I find it wierd that Informix dont like using LVM (and buffer cache) for DB consistency reasons yet Oracle dont mind at all. Most places ive worked use Oracle and always they use LVM (not raw). So Oracle must have a safe way around a crash in case the buffer cache wasnt flushed yet - in the event of a crash it simply rolls back to the last point where writes were committed. And lets face it, Oracle is used in a lot more companies than Informix. I guess now that IBM own it theyre going to merge with DB2 or close down informix altogether ?
How is it still down at FE ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-20-2002 05:26 AM
тАО05-20-2002 05:26 AM
Re: Low Buffer cache Hit Ratio's & I/O bottlenecks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-20-2002 06:07 AM
тАО05-20-2002 06:07 AM
SolutionA new parameter has been introduced with recent patches: disksort_seconds. Note that the SAM Help on Context file and a section 5 man page are still missing but the patch documentation has the details. Here is an excerpt from the 11.00 patch:
PHKL_21768:
The system sometimes takes a very long time to respond to a disk read/write request (could be up to several hundred seconds) while it is busy processing other I/O requests on the same disk, especially when there are sequential file accesses going on.
This is a fairness problem with the disk sort algorithm. The disk sort algorithm is used to reduce the disk head retractions. With this algorithm, all I/O requests with the same priority are queued in non-descending order of disk block number before being processed if the queue is not empty. When requests come in faster than they can be processed, the queue becomes longer, the time needed to perform one scan (from smallest block number to largest block number of the disk) could be very long in the worst case scenarios.
It is unfair for the request which came in early but has been continuously pushed back to the end of the queue because it has a large block number or it just missed the current scan. These kind of unlucky requests could line up in the queue for as long as the time needed for processing a whole scan (which could take a few minutes). This situation usually happens when a process tries to access a disk while another process is performing sequential accesses to the same disk.
Resolution:
To prevent this problem from happening, we have to take the time aspect into consideration in the sorting algorithm. We add a time stamp for each request when it is enqueued, which is used as the second sorting key for the queue (1st key: process priority; 2nd key: enqueued time; 3rd key: block number). The granularity of the time stamp value is controlled by a new tunable "disksort_seconds".
If we set "disksort_seconds" to N (N>0), for all the requests with the same priority, we can guarantee that any given request will be processed earlier than those which come in N seconds later than this request. Within each N second period (requests have the same time stamp), all requests are sorted by non-descending block number order. By choosing the right "disksort_seconds" value, we can balance the maximum waiting time of requests and the efficiency of disk accesses. The tunable parameter can be set to 0, 1, 2, 4, 8, 16, 32, 64, 128 or 256 second(s). If "disksort_seconds" is 0 (default value), the time stamp is disabled, which means that time aspect is not taking effect.
Bill Hassell, sysadmin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-21-2002 01:52 AM
тАО05-21-2002 01:52 AM
Re: Low Buffer cache Hit Ratio's & I/O bottlenecks
Hi Stefan - yes things are fine - You still hanging around with Richard S ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-23-2002 05:41 PM
тАО05-23-2002 05:41 PM
Re: Low Buffer cache Hit Ratio's & I/O bottlenecks
mincache=direct
convosync=direct
nodatainlog
These option will not exist without the Online JFS product installed. The fstab entry would look like:
/dev/vg02/lvol3 /u03 vxfs rw,nosuid,delaylog,mincache=direct,convosync=direct,nodatainlog 0 3
This means that every write to the filesystem is unbuffered. This is often desirable for Oracle data directories (but not for rollback logs, archives, etc) when the Oracle SGA defines a large data cache.
Bill Hassell, sysadmin