slow performance is it due to buffer cache

[sachin_25]

Hi

we have a HP Unix 9000 , ver 11 system.
users are complaining abt slow performance.
I have following details
glance o/p :
cpu utilization ~ 10%
disk utilization ~20 -40 %
memory ~60%
swap ~20 %
physical memory 8.00 gb
buf cache : 490 MB
total VM 3.4 GB
active VM 1.44 GB

sar -b shows :
average :
%rcache : 65
%wcache : 65

Also

dbc_max_pct is 6

please let me know if the perf. problem is
related to lower buffer cache.

Also is there any thumb rule to set buffer cache from physical memory.

Thanks..

[Pete Randall]

The buffer cache rule of thumb is to keep it to 300-400MB. You're actually a little higher than that. Your numbers don't seem to point to any obvious problem. What does this server do? Is it primarily a DB app? If so, perhaps you need to look into tuning the DB.


Pete

[Stefan Farrelly]

Its not buffer cache causing your poor performance. Its set to 6% of 8GB = 480MB which is around the ideal amount.

With disk utilization of 20-40% I would say this is certainly your performance problem - that is far too high.

[Mark Greene_1]

Run iostat to see which disk drives are getting the most activity. How many drives and in what sort of array and RAID configuration are they in?

mark

[Bill Hassell]

Actually, disk usage at 20-40% is quite low. Ideally, your computer usage and disk usage would be about 90-100% at peak times, which means you are getting your money's worth in terms of performance. But the critical number here is the %rcache at 65...way too low. This indicates that there is a lot of data scattered randomly across different filesystems and the cache is simply not large enough to keep enough in memory to avoid extra disk I/O's. %wcache is fine, but I would increase your buffer cache maximum to at least 800 to 1000 megs and see what happens. The ideal range is 200-800 but a lot depends on how effective the buffer cache is at keeping useful data.

But as with all database server performance issues, the main culprit is usually poor database design (not enough indexes, poor SQL statements, etc). A bigger buffer cache will tend to mask these design problems.

[Alzhy]

If this is not a DB server, try increasing your cache. You may also check if you've a hot disk in your storage pool.. "sar -d 5 10" will show you which disks are hot and giving your IO grief. If you find a disk(s) whose avserv is above 20 (for most subsystems) then you've likely a bottleneck..

And lastly, have your users qualify/quantify how slow is "slow"

[doug mielke · Accepted solution]

I have some systems that consistanly show near 100% disk util. I also have some servers with lower cache hits tha 65%. There is much room for improvement, but I would not suspect that as a huge perf. hit yet.

If the performance drop occurred suddenly, some things to check.

sar -b, for high access times, 100 ms+ ( disk going bad, doing re reads, but this should cause high disk util numbers)

time some nslookups, to look for a DNS slowness, which can bring a system t it's knees.

If users are off your local segment, run traceroute to look for a routing issue.

[sachin_25]

Hi all

thanks for the response. Just wanted to add :
1) This is a oracle database server. while looking at performance we tried to work on SGA and tuning of db buffers. Hit ratio is currently around 75% and It is not increasing even though we are adding db_block_buffers and in turn SGA size. Some oracle experts thus feels this is hardware / os issue.

2) We have MTS configuration for Oracle, though few connections 200/1500 are coming as dedicated, not sure if this is related to machine having two i/p addresses, one logical and other physical.

--

[Jean-Luc Oudart]

Hi,

If you suspect Oracle not to be tuned properly, I suggest you run statspack snapshot at good response time and at bad response time. Run the report and compare.

Regarding MTS, I was always told that was not a performant piece of code and not much improved (nothing like a real TP monitor)

anyway found this on MTS if this can help

http://www.engin.umich.edu/caen/wls/software/oracle/network.901/a90154/mts.htm

http://sales.esicom.com/sales/oracle/network.816/a76933/mts.htm

Do you have any baseline when system was running fine ?

Rgds,
Jean-Luc

[John Garrott]

If you're trying to tune your Oracle DB, there are many other areas critical to performance besides SGA and db_buffer. Other issues include indexes (do you re-build periodically?), fragmentation (do you export/import periodically, or use online-defrag tools?), i/o balancing (have you checked for 'hot' tablespaces and insured that they are not all on the same controller channels and/or disk spindles?). Another major area is if the database is set to cost-based or rule-based. If cost-based, you MUST initially run the ANALYZE command on your tables to generate EXPLAIN plans for the database to use for cost-based optimization, and again when changes made such as adding new indexes.

John Garrott