Thanks for your suggestions. Some of them we had already decided to look
into, but you gave us a few more to look at. As for attaching some DAS
or some other storage, they don't have any. Actually they outgrew the
DAS and went to iSCSI. We are trying to see if we can perhaps get some
FC attached storage on that host to see if the iSCSI is part of the
issue.
Thanks,
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Rhodes
Sent: Wednesday, May 16, 2007 6:00 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Poor TSM server performance on Sun.
Hi,
Here are some thouthgs/comments to think about and/or look at . . .
I assume you are running Gigabit Ethernet.
CHeck that the nic is indeed running at GE, and not 100mb.
The log/db/stgpool, how are they setup on the clariion? Are they all
residing on the same set of spindles? Are you really seing internal
clariion contention and/or performance issues? Pull up Navi Analizer
and see what the clariion is doing.
Is the nic also being used for backups? Can you use separate nic's for
iscsi and general traffic?
If you are running the sftw initiator, are you seeing high cpu by it?
Do you need a TOE?
Are you using jumbo packets?
4k db/log i/o = 3 std eth packets
4k db/log i/o = 1 jumbo eth packet
Not sure the blocksize for stgpool I/O, but jumbo packets would sure
help out a lot.
What are the tcp tuning parms set to? No, not TSM tcp parms, the std os
parms. ISCSI I would think is using normal os tcp parms. It won't be
using the tsm tcp parm settings.
Can you run move the db/log/stgpool to non-iscsi disk to see
performance? Ultimately, to know if iscsi is the problem will
be to bypass iscsi for a test.
Are your tape drives iscsi also? Are they on the same nic?
Can you run some benchmarks against iscsi disks and non-iscsi disks to
see performance difference? I often use a simple benchmark pgm to try
out different disk layouts and stripping systems. I've also used it to
test sata vs fc drives in a clariion (yes, sata was much slower for
random i/o).
Is the clariion using sata drives that your db/log/stg are on?
SATA is very bad for random i/o. Clariion SATA sequential performance
can be bad if too many data streams are being read from it or the wrong
raid lvl is being used.
Check clariion performance info for details.
You have a disk system, network, os and application involved in this.
The slowness could be in any one or all of them.
I would not assume TSM is the problem. My experience is that when
everything appears to be working just fine but not up to performance
level I expect, I usually look for latency issues.
I this case, that would be network/iscsi issues.
Rick
> Folks,
> I have a TSM server running on a Sun host running SOL 9, 16GB
>RAM, and TSM 5.3.4
>
> The problem is very poor performance, expire inventory goes
>extremely slowly, even archives of 20GB files going to disk or tape are
>very slow. Just slow slow slow.
> But all of the typical things I look at (the bufpool, log
>wait, accounting logs, iostat, etc) look ok. No MediaW or IdleW,
>everything seems to be in a "Run" state, but going slowly.
>
> All the storage (DB, LOG and STG) is on ISCSI out to an EMC
>Clariion. The disk ~seems~ to be OK, but running a TSM DB and LOG on
>iSCSI is a new configuration for us. At the OS side, it doesn't think
>it is waiting for I/O (with an 'iostat' command), but I'm not sure if
>the iSCSI protocol may be hiding the i/o waits from the OS, Any
>comments, good or bad, from someone running TSM DB & LOG on iSCSI?
>
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are hereby
notified that you have received this document in error and that any
review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.
|
