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.
