SUMMARY: I/O Read Performance Problem Oracle 8.1.7 Unix 5.1

From: <bob.safran_at_esca.com>
Date: Thu, 09 May 2002 13:35:31 -0700

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_at_esca.com
---------------------- Forwarded by Bob SAFRAN/ESK/SYG/TDE/GECALSTHOM on
05/09/2002 13:07 ---------------------------


brian.hunter_at_sts.co.uk_at_ornl.gov on 01/16/2002 07:35:26

Sent by: tru64-unix-managers-owner_at_ornl.gov


To: tru64-unix-managers_at_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_at_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.
Received on Thu May 09 2002 - 20:37:34 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:43 NZDT