Hi there,
first of all sorry for the long append but I need to explain my problem in
detail.
I was trying to optimize our backup performance for a particular node, so I got
a look at
INSTR_CLIENT_DETAIL trace output.

Server is ADSM 3.1.2.50 on OS/390 V2R6
Client is USS 3.1.0.5
Commethod is TCPIP using a CTC (Channel To Channel) connection
Client and Server are on two separate LPAR on the same 2064 machine

Here is our starting point:
Total number of objects inspected:   52,041

Total number of objects backed up:    1,554

Total number of objects updated:          0

Total number of objects rebound:          0

Total number of objects deleted:         72

Total number of objects failed:           0

Total number of bytes transferred:     8.10 GB

Data transfer time:                  256.23 sec

Network data transfer rate:        33,168.89 KB/sec

Aggregate data transfer rate:      1,396.01 KB/sec

Objects compressed by:                   55%
Elapsed processing time:           01:41:28

and trace output:

Elapsed time:  6088.402 sec

Section      Total Time(sec)  Average Time(msec)  Frequency used

-----------------------------------------------------------------
Client Setup        0.063           62.9              1
Process Dirs      108.029           47.1           2292
Solve Tree          0.000            0.0              0
Compute             2.003            0.0         768476
Transaction        46.226            0.0        2312991
BeginTxn Verb       0.007            0.0           1181
File I/O         2659.223            4.6         580646
Compression      2964.974            4.3         692721
Data Verb         255.722            1.0         266454
Confirm Verb        0.202            4.9             41
EndTxn Verb        51.560           43.7           1181
Client Cleanup      0.392          392.2              1

So,according to common tuning consideration, I decide to turn client compression
 off.
The results weer not as expected:

Total number of objects inspected:   57,067

Total number of objects backed up:    1,450

Total number of objects updated:          0

Total number of objects rebound:          0

Total number of objects deleted:        507

Total number of objects failed:           1

Total number of bytes transferred:    18.53 GB

Data transfer time:                6,941.87 sec

Network data transfer rate:        2,799.28 KB/sec

Aggregate data transfer rate:      1,858.10 KB/sec

Objects compressed by:                    0%
Elapsed processing time:           02:54:18

and trace output:

Elapsed time: 10458.494 sec

Section      Total Time(sec)  Average Time(msec)  Frequency used

------------------------------------------------------------------
Client Setup        0.766          765.9              1
Process Dirs      123.954           47.2           2625
Solve Tree          0.000            0.0              0
Compute             1.975            0.0         608333
Transaction        53.118            0.0        1831471
BeginTxn Verb       0.009            0.0           1179
File I/O         3239.495            5.3         609776
Compression         0.000            0.0              0
Data Verb        6940.654           11.4         608333
Confirm Verb       38.818          825.9             47
EndTxn Verb        59.321           50.3           1179
Client Cleanup      0.385          384.6              1

My question is; why Data Verb is so increased while data to be transferred are
only doubled?
>From dsmsched.log analisys, I found this time gap in sending data from client:

02/22/2001 02:28:57 Retry £ 1  Normal File-->       204,832,768
/ciadata/Mail_Trace.nsf  Sent
                                                                                 

02/22/2001 03:52:59 Normal File-->       338,083,840 /ciadata/StatisticheUOW.nsf
Sent

No errors detected, neither on client nor on server side.
The only thing I found is that, at 02:24, two migrationprocesses started moving
data from the
dasd stg where the client is sending its data; at 03:50 the last process
terminated its migration.
Maybe this was only a coincidence but ... I decide to add some volumes to the
stg
trying to accomodate the new data and to avoid the dasd_to_tape migration
processes.
Again, these are the results:

Total number of objects inspected:   56,890

Total number of objects backed up:    1,446

Total number of objects updated:          2

Total number of objects rebound:          0

Total number of objects deleted:         22

Total number of objects failed:           1

Total number of bytes transferred:    18.08 GB

Data transfer time:                2,091.27 sec

Network data transfer rate:        9,068.03 KB/sec

Aggregate data transfer rate:      3,619.54 KB/sec

Objects compressed by:                    0%
Elapsed processing time:           01:27:19

and trace output:

Elapsed time:  5239.620 sec

Section      Total Time(sec)  Average Time(msec)  Frequency used

------------------------------------------------------------------
Client Setup        0.680          679.9              1
Process Dirs      122.582           46.7           2627
Solve Tree          0.000            0.0              0
Compute             1.913            0.0         593671
Transaction        44.557            0.0        1787459
BeginTxn Verb       0.009            0.0           1175
File I/O         2914.685            4.9         595100
Compression         0.000            0.0              0
Data Verb        2090.089            3.5         593671
Confirm Verb        0.653           15.9             41
EndTxn Verb        64.053           54.5           1175
Client Cleanup      0.398          397.8              1

My questions:
1) why is Data Verb 8 times bigger?
2) can (I don't thing so) dasd stg migration stop client operation?
Maybe it can degrade performance but not stop completely ...

Your help will be very appreciated.
Thanks in advance.
Best regards.
Valeriano Bassi          [EMAIL PROTECTED]

Reply via email to