Thank you to Stephen, Bill Craig and David, who responded very quickly.
We changed the recomended Unix-Parameters an now our Problem of long times for
tablespaceenlargings is gone.
Here is the solution:
********************************************************************************
***********
Some insight on your issue ! Check out your advfs parameters !
This document describes the neccessary changes to the advfs parameter for
an optimal operation of Oracle. If the parameters are not set in this way
you will see poor system performance during tablespace creations, this can
even be seen as a system hang if the datafile exceeds 1.5 Gb. In using
the following parameters you'll have a smooth I/O pattern.
Here the recommendation:
AdvfsCacheMaxPercent = 1
AdvfsMaxDevQueueLength = 16 or 32
AdvfsFavorBlockingQueue = 0
The advfs parameters are necessary for a smooth I/O operation with Oracle.
Here some insight:
AdvfsCacheMaxPercent: is defining the size of the advfs buffer size. This is
in percent of the system memory. The default value of 7% (in your case 10%)
are used to buffer data. In case of a dedicated DB server this buffering
is already done by Oracle. Oracle as the DB engine is comparable to a huge
buffer cache. To buffer this data again in AdvFs doesn't make sense, so we
recommend the minimum size (1%).
In case you create a tablespace (adding a datafile) you start to fill the
advfs buffer. There is an algorithm in place to start flushing the advfs
buffer as soon as it reaches a certain usage level (90% of the advfs cache).
The flushing is actually creating a very high I/O and CPU activity.
This algorithm will be improved in the next major OS version. But if the
cache is kept small, the flushing activity will never have the same hanging
effect.
The recommendation for the AdvfsMaxDevQueueLength is based on the I/O
subsystem. We have seen the best performance results for Oracle DB servers
with values of 16 or 32.
Here an explanation:
The AdvfsMaxDevQLen sysconfig parameter was added to V4.0 to handle the
tradeoff between quick synchronous IO response times and maximizing IO
throughput to AdvFS volumes. A default value of 80 was chosen as a compromise
between these needs. Essentially, response time was favored over IO
throughput in choosing that default for general system workload enviroments.
The range is 0, 1 to 65536. from my testing a reasonable range is between
20 up to 2000. Too low a value will hurt potential IO throughput. Too high
will cause excessively long user response times for synchronous IO requests
measured in seconds to minutes.
Value 0 actually deactivates the AdvFS per-volume threshold causing any
and all IO requests to immediately be issued to the disk whenever there
is a sync request. We don't recommend you choose this value.
Since AdvfsMaxDevQLen applies to all AdvFS volumes in the system,
you need to choose the value wisely if you plan to change it from the default.
If your environment is such that hardly anyone or any application needs to
synchronously wait on IO, then you might consider higher values up to 2000.
I have seen this help for example when you have systems that generally
write asynchronous data to files, but rarely have users waiting for data.
If your system environment contains mixed user applications or is sensitive
to synchronous IO response times, then use values less than 300. In case
of a dedicated DB server this is mostly synchronous IO (e.g. Oracle is doing
all writes with the O_SYNC option)
A general and simplistic way to figure this is:
synchronous IO response time = AdvfsMaxDevQLen * average IO response time
assuming there are AdvfsMaxDevQLen IO requests already being processed
to the disk when the synchronous request is issued. The average IO
response time here means how long it takes one IO request to complete when
there is no other traffic to the disk.
Check the output from LSM volstat to see the average read and write response
times.
Another parameter worthwhile mentioning is
AdvfsFavorBlockingQueue = 0
This causes AdvFS to mix the ratio of synchronous IO data flushing with
asynchronous IO instead of the default which is to first flush
all synchronous IO then asynchronous IO. In this case, synchronous
IO means read requests, explicit user syncronous writes, and
fsync writes of modified cached data.
This parameter is useful for mixed DB/Application servers.
Received on Mon Aug 17 1998 - 16:57:45 NZST