VSAM CA Splits, still a performance problem?
Barry Jones
In the old days,CA splits were quite detrimental to performance of VSAM
applications.
In today's world with lots of cache in modern DASD systems, are CA splits
still a concern?
Or should I just allocate KSDSs with FREESPC(00 00) and save the space?
All thought appreciated.
Barry.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Ted MacNEIL
still a concern?
>Or should I just allocate KSDSs with FREESPC(00 00) and save the space?
It's discussed in the RedBook "VSAM DeMystified", but the general concern is no longer applicable, even though some old-timers here disagree.
In general, the remaining concern is when the split actually happens.
There is still a performance impact at that time, but with today's processors and equipment, it's rarely an issue.
-
Too busy driving to stop for gas!
Joel C. Ewing
overhead - like typically an extra Data CI write and Index CI write. A
CA split on the other hand means you have to physically move half the
Data CIs in the old CA to another CA. For a 3390 cylinder CA and 4KiB
Data CISIZE, that means an extra 90 blocks read into and 90 blocks
written out of your application buffer pools, which can still affect
on-line response if this happens too often.
Prior to DASD subsystems with large amounts of cache, you could also pay
a read-performance hit when reading areas that had undergone CI or CA
splits, but modern caching subsystems do a good job of hiding that penalty.
Everything depends on how the dataset will be used and the pattern of
update activity to it. I would be inclined to suspect there are few
cases today where CI-freespace makes sense, but we still have cases
where we specify CA-freespace because it seems to help.
JC Ewing
On 11/10/2009 06:55 AM, Barry Jones wrote:
> Hello,
>
> In the old days,CA splits were quite detrimental to performance of VSAM
> applications.
>
> In today's world with lots of cache in modern DASD systems, are CA splits
> still a concern?
> Or should I just allocate KSDSs with FREESPC(00 00) and save the space?
>
> All thought appreciated.
>
> Barry.
...
--
Joel C. Ewing, Fort Smith, AR jREMOVEc...@acm.org
Hal Merritt
Your determination of free space should include your expected (or observed) insert activity, the initial population, and the distribution of new records. That said, I wouldn't spend a lot of time on the estimates.
My $0.02
Hello,
All thought appreciated.
Barry.
NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
Gene Hudders
The considerations for CI/CA splits varies with either on-line or batch
processing. Here is some information from the CICS TS Performance Guide and
VSAM Demystified manuals that may be useful. Free space provides a tool for
deferring splits to occur.
From CICS TS 4.1 Performance Guide
From Pg 29 related to information in LISTCAT
Whether and how often control interval (CI) or control area (CA) splits
occur
(splits should occur very rarely, especially in CA).
From Pg 112 related to reducing I/O operations
Minimize CI/CA splits by:
– Allocating ample free space (free space can be altered by key range
during
load)
– Timely reorganizations of disk storage.
From Pg 124 related to CICS VSAM tuning considerations
File control requests for NSR files are done asynchronously, however, and
still
cause the CICS main task or subtask to stop during a split.
From Pg 152 related to specifying free space
Other VSAM definition parameters
Free space parameters need to be selected with care, and can help reduce
the
number of CI and CA splits. Where records are inserted all over a VSAM
data set,
it is appropriate to include free space in each CI. Where the inserts are
clumped,
free space in each CA is required. If all the inserts take place at just a
few positions
in the file, VSAM should be allowed to split the CA, and it is not
necessary to
specify any free space at all.
From Pg 160 related to the TCB subtasking (CO TCB)
Effects of permitting VSAM subtasking
The objective of subtasks is to increase the maximum throughput of a
single CICS
system on multiprocessors. However, the intertask communication increases
total
processor utilization.
When I/O is done on subtasks, any extended response time which would cause
the CICS region to stop, such as CI/CA splitting in NSR pools, causes only
the
additional TCB to stop. This may allow more throughput in a region that
has very
many CA splits in its file, but has to be assessed cautiously with regard
to the
extra overhead associated with using the subtask.
----------------------------------------------------------------------------
-----------------------------------------------------------------------
From VSAM Demystified:
From Pg 124 related to I/Os associated with a CA split
I/Os associated with CA splits
These I/Os should be avoided. CA splits generate many I/O operations. CA
splits
occur in a KSDS or VRRDS along inclusions and increase the logical record
size
during an update. CA splits may be minimized by the use of CA free space.
Refer
to “Splits” on page 15. However, a CI splits is not a real performance
problem
because it needs less than five I/Os.
From Pg 57 related to Free Space
Too little free space can result in an excessive number of CI and CA splits
(depending on the key pattern of the records to be inserted), with
consequences
such as:
The CA splits are resource consuming, due to the overhead (during the
split),
since approximately half of the CIs from the CA are moved to the end of the
data set.
CI and CA splits may also affect the sequential processing because the
DASD
controller, to better use the cache, only detects 3390/3380 tracks physical
sequence. Splits make the logical sequence different from the physical
sequence.
From Pg 131 related to lowering connect time
Less free space in the CIs:
The existence of a significant amount of free space in a CI, may increase
the
I/O connect time. This free space may be caused by an excess in the
definition of the data set, or by CI and CA splits. Remember that any CI
with a
logical record is moved to storage in a sequential read. This is not true
with
totally free CIs, where no I/O operations are executed towards them.
Pg 208 related to CA splits may increase free space
CI/CA splits causing free space increase
After CI and or CA splits the free space per CI (excluding the totally
freed) tends
to increase. In sequential read processing there is some impact on
performance
because more free bytes are moved to storage. Refer to 2.7.4, “I/O service
time
(connect) for VSAM data sets” on page 129.
Regards,
Gene