The first thing I would look for are file sizing issues. Try to identify
some of the critical and most used data files; don't forget code files,
cross references and the like. For a quick check run GROUP.STAT against the
files. Look for these conditions: (1) modulo dramatically too small, (2)
bad record distribution, (3) non prime number modulos. For code files and
other shared files, check for modulos of 1 or very small values possibly
causing lock bottlenecks. Here are a couple small GROUP.STAT samples
illustrating the three conditions mentioned:
Too small modulo: (numbers in left column much larger than sep x 512)
> GROUP.STAT TTT
Type description= Hashed, entire keys are full range of ASCII characters.
Bytes Records File= TTT Modulo= 7 Sep= 1 Type= 18
3944 103 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
4064 109 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
4356 123 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
4560 110 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
3844 106 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
4144 118 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
3904 115 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
====== ====
28816 784 Totals
4116 112 Averages per group
241 6 Standard deviation from average
5.9 5.4 Percent std dev from average
Bad record distribution: (This one isn't too bad, but look for a few huge
groups with lots of records amongst many small, sparse groups)
Type description= Hashed, keys begin in full range of ASCII characters.
Bytes Records File= TTT Modulo= 53 Sep= 1 Type= 9
512 16 >>>>>>>>>>>>>>>>
988 28 >>>>>>>>>>>>>>>>>>>>>>>>>>>>
92 3 >>>
320 12 >>>>>>>>>>>>
1560 27 >>>>>>>>>>>>>>>>>>>>>>>>>>>
772 19 >>>>>>>>>>>>>>>>>>>
148 5 >>>>>
496 14 >>>>>>>>>>>>>>
2120 49 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
452 13 >>>>>>>>>>>>>
652 17 >>>>>>>>>>>>>>>>>
260 9 >>>>>>>>>
428 12 >>>>>>>>>>>>
488 14 >>>>>>>>>>>>>>
780 23 >>>>>>>>>>>>>>>>>>>>>>>
220 8 >>>>>>>>
Non-prime modulos: (Won't always be a problem, but can be, as shown here)
Type description= Hashed, keys are letters.
Bytes Records File= UNPOSTED.TRANSACTIONS Modulo= 20 Sep= 4 Type=
12
0 0
15008 108 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
0 0
0 0
0 0
13284 88 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
0 0
0 0
0 0
13608 97 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
0 0
0 0
0 0
13368 102 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
0 0
0 0
0 0
15428 105 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
0 0
0 0
====== ====
Hope this helps. You can find a number of tech papers about file sizing on
our website at www.fitzlong.com.
Jeff Fitzgerald
Fitgerald & Long, Inc.
mailto:[EMAIL PROTECTED]
(303) 755-1102
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Kevin Vezertzis
Sent: Thursday, April 08, 2004 9:02 AM
To: [EMAIL PROTECTED]
Subject: Performance
We are looking for some insight from anyone that has experienced performance
degradation in UV, as it relates to the OS. We are running UV 10.0.14 on
AIX 5.1.we are having terrible 'latency' within the application. This is a
recent conversion from D3 to UV and our client is extremely disappointed
with the performance. We've had IBM hardware support and Universe support
in on the box, but to no avail..we are seeing high paging faults and very
highly utilized disk space. Any thoughts or suggestions?
Thanks,
Kevin
Kevin D. Vezertzis
Project Manager
Cypress Business Solutions, LLC.
678.494.9353 ext. 6576 Fax 678.494.9354
[EMAIL PROTECTED]
Visit us at www.cypressesolutions.com
--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users
--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users
