From: bob.safran@esca.com
Date: Thu May 09 2002 - 16:35:31 EDT
All,
I'm running OPS Oracle 8.1.7.3.0 on a couple of DS20's, 1GB Mem, HSG80's,
Tru64 5.1 patch 3 and have an application that seems to be running a bit
slower than when it ran on a 2100 OPS, VMS 7.1cluster. The note below
refers to a kernel parameter fifo_do_adaptive.
Is this parameter still relevant for my configuration?
Can I add this parameter to sysconfigtab? Where? Which subsystem?
Any other Tru64 performance tips would be appreciated. The DS20's were
built using Tru64 5.1 from scratch.
FYI: The database is distributed across 6 RAID 0+1 domains, 99% buffer
cache and no lock or latch contention. The problem I'm seeing is that it
takes 4 seconds to get the nextval from a user sequence - not cached
because of OPS. Sorry for being slightly off topic.
TIA - Bob Safran
bob.safran@esca.com
---------------------- Forwarded by Bob SAFRAN/ESK/SYG/TDE/GECALSTHOM on
05/09/2002 13:07 ---------------------------
brian.hunter@sts.co.uk@ornl.gov on 01/16/2002 07:35:26
Sent by: tru64-unix-managers-owner@ornl.gov
To: tru64-unix-managers@ornl.gov
cc:
Subject: SUMMARY: I/O Read Performance Problem Oracle 8.1.7 Unix 5.1
Thanks to replies ...
Corinne Haesaerts
Fletcher Joe
Danny Petterson
alan@nabeth.cxo.cpqcorp
we have resolved the I/O problem and now have the full PK4 applied.
The I/O problem was due to multi-volume 'V4' AdvFS file domains. We
backed these up, applied the full PK4 fixes, recreated the file
systems as 'V5' and restored the data. (no I/O error's so far...)
As a result performance has improved but read I/O time is still a slow
18ms (compared with <10ms on 4.0D)
Elapsed job time is now about 30-60% worse than that under 4.0D
It has been suggested ...
"do not use your V4.x /etc/sysconfigtab in V5".
apart from changing 'fifo_do_adaptive = 0' we are running it unchanged
...a review of settings is underway.
The other suggestion is that Oracle is using direct I/O (new with Unix
V5) and that this performs badly.
We attempted to switch this off by setting the ORA_INIT parameter
'DISC_ASYNC_IO' to false. The theory being that Oracle avoids using
direct I/O if it's not allowed to do asynchronous I/O. This did not
affect performance as far as we could tell.
At 8.1.7.2 Oracle have introduced a 'hidden' ORA_INIT parameter which
allows one to explicitly disable Oracle's use of direct I/O.
We are investigating the upgrade (8.1.7.0 to 8.1.7.2) and plan to test
this out.
Summary of original report:
Upgraded from 4.0D to 5.1PK4
Random I/O error when copying a file between file systems.
The problem was 'fixed' by removing 5 patches 653, 494, 232, 230 and
226.
Batch jobs took 2 to 3 times longer than at 4.0D,
due to Read I/O time from the database, previously <10ms now about
26ms. Copying large files between file systems also seemed slower.
Applying the missing patches from PK4 reduced the Read I/O time to
18ms and jobs ran at less than twice the elapsed time of 4.0D
BUT the I/O problem caused jobs which wrote to flat files to fail.
We removed the 5 patches again and changed the kernel parameter
'fifo_do_adaptive = 0' as per a previous summary (Thanks Rob Pieters)
This gave us a 15% improvement in elapsed time but the longer Read I/O
remained (>20ms).
Brian Hunter
**********************************************************************************
This message has been sent via the Internet. Internet communications
are not secure against interception or modification. Severn Trent
Systems therefore can not guarantee that this message has not been
modified in transit, and this message should not be viewed as
contractually binding.
This message and any files transmitted with it are confidential and
intended solely for the use of the addressee. If you have received
this message in error please notify the sender and destroy your
copies of the message and any attached files.
***********************************************************************************
Severn Trent Systems Ltd : a part of Severn Trent plc.
Registered in England and Wales Registration No. 2394552
CONFIDENTIALITY: This e-mail and any attachments are confidential and may
be privileged.
If you are not a named recipient, please notify the sender immediately and
do not disclose the
contents to another person, use it for any purpose or store or copy the
information in any medium.
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:40 EDT