because TSM processes on a file system basis...
since / is a single file system, it will start a single process.
Do you only want / backed up ? what about /usr and /opt & /var, etc....
they are not part of /
Now if you said
incr -subdir=yes
then you would see a process for / kick off, along with one for /usr, and
one for /opt, etc... up to 4 total (1 master & 3 slaves I believe)
Now if your / is actually some 100 GB file system annd you really want more
processes running against it, break it down using the "virtualmountpoint"
option in your option file (check the manual out for proper placement &
syntax) but you could make different subdirectories under / be virtual mount
points (ie virtual file systems to TSM) and then you could have it fire off
a separate process against each of these virtual mount points...
later,
Dwight
-----Original Message-----
From: Grems [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 4:52 AM
To: [EMAIL PROTECTED]
Subject: Re: Make Compression Client faster ??
this is my DSM.SYS
--------------------------------------------------
SErvername TSM_SERVER
COMMmethod TCPip
TCPPort 1500
TCPServeraddress 10.100.24.42
compression on
passwordaccess generate
resourceutilization 4
--------------------------------------------------
when i make a
root:>dsmc i / -sub=yes
omly one processeurs is use for compression, why ?
----- Original Message -----
From: "Gerald Wichmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 7:28 PM
Subject: Re: Make Compression Client faster ??
You sure the process is cpu bound and that it even matters? One would think
the operation is more I/O bound..
Otherwise from redbook "using the ba client" try adjusting the
resourceutilization paramater:
Resourceutilization
Authorized User
The resourceutilization option regulates the level of resources the
Tivoli Storage Manager server and client can use during processing.
When you request a backup or archive, the client can use more than
one session to the server. The default is to use a maximum of two
sessions; one to query the server and one to send file data. The
client can use only one server session if you specify a
resourceutilization setting of 1. The client is also restricted to a
single session if a user who is not authorized invokes a UNIX client
with passwordaccess=generate specified.
A client can use more than the default number of sessions when
connecting to a server that is Version 3.7 or higher. For example,
resourceutilization=10 permits up to eight sessions with the server.
Multiple sessions may be used for querying the server and sending
file data.
Multiple query sessions are used when multiple file specifications
are used with a backup or archive command. For example, if you
enter:
inc filespaceA filespaceB
and you specified resourceutilization=5, the client may start a
second session to query files on file space B. Whether or not the
second session starts depends on how long it takes to query the
server about files backed up on file space A. The client may also try
to read data from the file system and send it to the server on
multiple sessions.
The following factors can affect the throughput of multiple sessions:
6 The server's ability to handle multiple client sessions. Is there
sufficient memory, multiple storage volumes, and CPU cycles to
increase backup throughput?
6 The client's ability to drive multiple sessions (sufficient CPU,
memory, etc.).
6 The configuration of the client storage subsystem. File systems
that are striped across multiple disks, using either software
striping or RAID-5 can better handle an increase in random read
requests than a single drive file system. Additionally, a single
drive file system may not see performance improvement if it
attempts to handle many random concurrent read requests.
6 Sufficient bandwidth in the network to support the increased
traffic.
Potentially undesirable aspects of running multiple sessions include:
6 The client could produce multiple accounting records.
6 The server may not start enough concurrent sessions. To avoid
this, the server maxsessions parameter must be reviewed and
possibly changed.
6 A query node command may not summarize client activity.
Note: The server can also define this option.
Also from another section:
Note: On occasion, the aggregate data transfer rate may be
higher than the network data transfer rate. This is because
the backup-archive client has multithreading capabilities.
When multiple threads run during backup, the data
transfer time represents the sum time from all threads
running. In this case, aggregate data transfer time is
mistakenly reported as higher. However, when running a
single thread, the aggregate data transfer rate should
always be reported as lower than the network data
transfer rate.
Regards,
Gerald Wichmann
Senior Systems Development Engineer
Zantaz, Inc.
925.598.3099 (w)
-----Original Message-----
From: Grems [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 9:38 AM
To: [EMAIL PROTECTED]
Subject: Make Compression Client faster ??
HI,
When i use DSMC with client compression on, my AIX use only one
Processor for compress Data.
I have 6 processor, how can config my DSMC to use the 6 processor for
compress my data faster..
is it possible ?
Thanks,
