Hi Paul,
I have just now performed a server trace on the storage agent, but I
havent
had the time to look at it yet. I am not completely sure which trace
classes
to enable but I will experiment a little.
The disk is SAN-attached HDS lightning disks, so disk performance is not
an
issue, and it is the same disk where we see 60mb/s. Also, I get the same
performance from each session regardless of how many sessions there are in
parallel.
60mb/s is per session.. and that is what the 9840C drives should deliver
(35mb/s native, 70mb compressed). We previously had 9840B drives which
only
delivered 20mb/s native, and thus didnt really see the problem.
We have terabyte sized databases so we really need all the speed we can
get.
I am currently in the process of filling out a performance questionnaire
to
IBMs performance team regarding this issue.
-David
--
David Hendén
Exist AB, Sweden
+46 70 3992759
P Baines <paul.baines AT ECB DOT INT>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
2005-02-24 12:22
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
Re: Poor performance with TSM Storage Agent on Solaris
Have you run a client performance trace? This may give you an idea about
where the client is spending it's time. What type of disk is the data
stored on that you want to back-up from/restore to? Are these the same
type of disks where you see 60MB/sec? (How many parallel sessions do you
run to get 60MB/sec?) I also have problems getting good backup rates on
LAN-Free and my investigations are leading me to believe that the
bottle-neck is the client disk.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
David Hendén
Sent: Wednesday 23 February 2005 17:43
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Poor performance with TSM Storage Agent on Solaris
Dear all,
We are experiencing performance problems with the TSM Storage Agent for
Solaris.
This is regardless of if we are doing restores or backups. The problem
manifests itself mainly when restoring or backing data with DB2, but I get
the
same poor performance when sending gig sized files from the file system.
Performance seems to be CPU bound, and each restore/backup session takes
100%
of one CPU. So, on a 400mHz machine I can get around 10-15mb/s lanfree and
on
the faster machines with 1200mHz CPUs we're seeing speeds of around
20mb/s.
When specifying parallelism in the DB2 databases to use multiple sessions
we
get 2 * 10-15mb/s and also 2 CPUs using 100%. Truss says that almost all
of
this CPU time is spent in userland.
The native speed of the 9840C drives is 35mb/s and on AIX machines and
Slowlaris machines with Oracle we see speeds of about 60mb/s per session
over
the SAN.
At first I thought it could be the loopback interface but I didnt see any
performance gain when switching to shared memory. I have also tried all
the performance recommendations by IBM.
I am going to trace the storage agent tomorrow to see if I can shed some
light
on what all the CPU time is spent on.
On to my questions:
Has anyone experienced the same extreme CPU load when using the storage
agent
on Solaris?
Could it possibly be a patch related problem since the Solaris Oracle
machines
are more heavily patched than the DB2 ditos?
The environment:
Serverside:
TSM server 5.2.3.2 on AIX 5.2.
16 StorageTek 9840C tape drives in powderhorn libraries using ACSLS.
Everything is SAN connected with Cisco directors.
Clientside:
Solaris 5.8 64bit kernel.
Gresham EDT 6.4.3.0 used to connect to the ACSLS.
Storage Agent 5.2.3.5 on Solaris 5.8.
TSM client 5.2.3.5.
A range of different SUN hardware: different machines, different HBAs
(both
Sbus and PCI).
-David
--
David Hendén
Exist AB, Sweden
+46 70 3992759
Any e-mail message from the European Central Bank (ECB) is sent in good
faith but shall neither be binding nor construed as constituting a
commitment by the ECB except where provided for in a written agreement.
This e-mail is intended only for the use of the recipient(s) named above.
Any unauthorised disclosure, use or dissemination, either in whole or in
part, is prohibited.
If you have received this e-mail in error, please notify the sender
immediately via e-mail and delete this e-mail from your system.
|
