|
HP OpenVMS Systemsask the wizard |
|
The Question is:
We have a vms cluster with 3 members that access a shared indexed file via
cobol application with 10 proccess simultaneosly. When a process tries to
read/write to the file the action is very slow and i use anal/system utility
with command: show proc/chann
els, the channel asigned to the files appears "Busy".
The fdl is:
FILE
ALLOCATION 100000
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 2
CLUSTER_SIZE 4
EXTENSION 10000
FILE_MONITORING no
GLOBAL_BUFFER_COUNT 0
ORGANIZATION indexed
PROTECTION (system:RWED, owner:RWED,
group:RWED,world:RWED)
RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL carriage_return
FORMAT fixed
SIZE 85
AREA 0
ALLOCATION 100000
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 2
EXTENSION 10000
KEY 0
CHANGES no
DATA_KEY_COMPRESSION no
DATA_RECORD_COMPRESSION yes
DATA_AREA 0
DATA_FILL 100
DUPLICATES no
INDEX_AREA 0
INDEX_COMPRESSION no
INDEX_FILL 100
LEVEL1_INDEX_AREA 0
NAME ""
NULL_KEY no
PROLOG 3
SEG0_LENGTH 18
SEG0_POSITION 0
TYPE string
My questios in how to improve the i/o performance and reduce the "Busy" state
in a file. Take in mind that this file manage around 46 millions of records.
Thanks.
The Answer is :
It would appear that this application is seriously overdue for a
detailed examination and for tuning related to RMS and OpenVMS.
Please consider engaging your prefered services organization or
the customer support center for consulting, and please consider
reading through the OpenVMS Guide to File Applications details
on buckets and buffers.
What has been shown is an FDL for an indexed file that was either
recently created or recently. The specified FDL certainly appears
inadequately structured for the proposed 46 millon records.
Assuming a modest level of compression, the OpenVMS Wizard would
expect this file will occupy roughly 6,500,000 blocks and will
have an index root level of 4 or 5. This mean that each record
lookup will that at least 5 IO operations, and quite probably more.
You will want to use ANALYZE/RMS/FDL/STATISTICS on the target file
-- or potentially even on a backup copy of the file if file contention
is a factor -- and then use EDIT/FDL/NOINTERACT and finally -- when
the file and application activity can be quiesced -- the DCL command
CONVERT/FAST/NOSORT/STATISTICS to convert the data file using the
optimized FDL.
With a bucket size of 5 or more, you will reduce the index to level
3, which will reduce the I/O required to access a record. With a
bucket size of 24 or more, you will reduce the index to 2 levels,
which is likely provide the best performance in most cases. (The
saient exceptions to this being a rare few high-update, low memory,
slow-disk situations.)
As you have several concurrent users of this file, you will also want
to enable global buffers. Start with 100 or so buffers, and enable
and use the MONITOR RMS file statistics to measure activities.
If you wish to guess or gamble or blindly trust the OpenVMS Wizard,
you perform a full BACKUP/VERIFY of your file and can then skip all
of the intermediate steps listed above and use the FDL below:
FILE
FILE_MONITORING yes
GLOBAL_BUFFER_COUNT 100
ORGANIZATION indexed
PROTECTION (system:RWE, owner:RWE, group:RWE,world:RWE)
RECORD
FORMAT fixed
SIZE 85
AREA 0
ALLOCATION 7000000
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 24
EXTENSION 60000
KEY 0
DATA_KEY_COMPRESSION yes
DATA_RECORD_COMPRESSION yes
DATA_AREA 0
DATA_FILL 90
DUPLICATES no
INDEX_AREA 0
INDEX_COMPRESSION no
INDEX_FILL 90
LEVEL1_INDEX_AREA 0
PROLOG 3
SEG0_LENGTH 18
SEG0_POSITION 0
TYPE string
|