Joined: 05 Jun 2009 Posts: 185 Location: Planet Earth
Hello,
I am working on a batch application that is built on VSAM KSDS files. One of the programs that consumes less than 1 CPU second runs for about 30 minutes. We decided to setup APA profiling to see the time distribution and observed a very high Wait time on one of the VSAM files used in the same. This program reads the VSAM file sequentially. However there is a high time associated with VSAM POINT.
Following is the Wait time by category report,
Code:
W01: WAIT Time by Task/Category (0853/CVACY04D) Row 00001 of 00024
Command ===> Scroll ===> CSR
Name Description Percent of Time in WAIT * 10.00% ±0.3%
*....1....2....3....4....5....6....7....8.
PROGNAM-001 TCB=009B8168 91.03 ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
¸ DATAMG Data Mgmt 90.85 ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
Processing
¸ VSAM01 VSAM 76.69 ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
¸ POINT VCSVSAM1+106 68.62 ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
6
¸ IDA019L1 Virtual 68.62 ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
I/O (VIO)
and VSAM
¸ ERASE VCSVSAM1+FDE 5.50 ßßß
¸ GET VCSVSAM1+B0A 2.04 ß
¸ GET VCSVSAM1+F7E 0.52
¸ GET VCSVSAM1+B26 0.00
The dataset attributes of this file is as follows,
Code:
% Free Bytes in CI 10% Initial Last
Volume Serial H92445 CI Splits 24,900 24,900
CI Size 12,288 CA Splits 1,186 1,186
Record Size (LRECL) 1,559 Logical Records 672,683 625,579
Number of Extents 3 Deleted Records 3 47,107
SHAREOPTIONS (2 3) Insrted Records 47,350 47,350
Organization KSDS Retrved Records 3,903,057 5,248,449
CIs per CA 60 Updated Records 1 3
Free CIs per CA 3 Bytes Free Space 53,756 54,369
Free Bytes per CI 1,228 Number of EXCPs 322,370 777,366
% Free CIs in CA 5%
Strings 1 String Waits 0
DATA Buffers 5 String Waits HWM 0
INDEX Buffers 10
Avg Response Time 0.0640 Avg Pending Time 0.0000
Avg Disconnect Time 0.0000 Avg Connect Time 0.0384
Avg Queued Time 0.0000 Total I/Os 455,013
Cache Candidates 49,823 Cache Hits 49,800
Write Candidates 47,118 Write Hits 47,118
An average response time of 64 milliseconds seems large to me. However I am not sure how I can identify the reason for this slow response time. Any pointers that can guide me towards reducing the run time of this job would be of great help. Thanks !
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
A few questions come to mind:
1. Why CI free space? 10% of 12,288 bytes is not enough for a record of 1,559 bytes -- so why specify free space at all?
2. If you're doing sequential processing, where are the POINTs coming from?
3. If you're doing sequential processing, you don't need 10 INDEX buffers.
4. If you're doing sequential processing, you don't have nearly enough DATA buffers.
5. Are there other tasks (started or batch or online) that are hitting the same disk volume(s) while this job is running?
6. How is the channel utilization at the time the job runs, compared to other times of day?
7. Have you ruled out VIO issues since VIO is explicitly mentioned in what you posted from APA?
I'm curious about the ERASE statement in the code, what is that doing? If this invokes some sort of erase that can have a big effect as it writes binary 0's and requires additional I/O. It could explain why the 'Data Management' element is so high in APA. Erase should be disabled if it is not required.
ERASE VCSVSAM1+FDE 5.50 ßßß
There's also a large number of CI splits occuring. If you made CI freespace 13% that would allow for at least one record to be inserted. But it would be interesting to know if your file has key clustering going on where you have many records with similar keys. Sometimes altering the freespace while loading certain keys can allow you to make more freespace available where it is needed for inserts later.
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
Robert / Pete,
I was led to believe that by specifying CI free space, VSAM would adjust the setting internally if the free space was insufficient for one record, and load the file so that enough free space was retained for at least one insert into the CI.
I may be wrong, it has been known to happen in the past
Pete also brings up a great point about the index clustering. HAve come across this in the past and used the same actions as Pete suggests.
It certainly will automatically insert freespace into a CI during insert/load even where the file was originally defined without freespace. Maybe it's at this point it works out what that freespace needs to be to ensure it can contain at least one record?
But if you explicitly code free-space it leaves that percentage of CI/CA as freespace during the load. Once that freespace gets used up by subsequent inserts etc and a split occurs I can't recall if the explicitly coded freespace value will apply across the split CI's or if it will just insert what it needs.
