Ben, Sorry! Not trying to be a pain in the ass!
I guess I would worry about the overall performance since this is adding another protocol to the mix: SCSI on TCP/IP, and a somewhat slower (and that is the debate, isn't it) 1 Gb/sec path. TSM is such an I/O pig (and I mean that in a good way) that I'm skeptical about it being able to tolerate the additional overhead of iSCSI. I like the idea of using it for a remote copy pool, but for the main data structures, DB and LOG, I'm thinking not. I think it will work, but I doubt that it will fast. Now, back to you: if you learn differently, I'm all ears! I would love for this to work well as it will provide another good option for storage in a TSM environment. Kelly J. Lipp VP Manufacturing & CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Ben Bullock Sent: Monday, May 14, 2007 3:30 PM To: [email protected] Subject: Re: [ADSM-L] Poor TSM server performance on Sun. What gives you such pessimism about the configuration? Which piece of the set-up do you think is the issue? The iSCSI? Sun OS? The alignment of the planets? ;-) Ben -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Lipp Sent: Monday, May 14, 2007 1:38 PM To: [email protected] Subject: Re: Poor TSM server performance on Sun. I'll be very interested in the outcome of this one! I guess I'm not surprised that it's slow. I will be surprised if it ever works well. But that's just me! Kelly J. Lipp VP Manufacturing & CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Ben Bullock Sent: Monday, May 14, 2007 12:01 PM To: [email protected] Subject: [ADSM-L] Poor TSM server performance on Sun. 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? I ran a little instrumentation on the host for less than a minute and the final output looks like this: TOTAL SERVER SUMMARY Operation Count Tottime Avgtime Maxtime InstTput RealTput Total KB ------------------------------------------------------------------------ ---- Disk Read 435 58.100 0.134 0.963 281.2 1068.6 16340 Disk Write 97 14.632 0.151 0.504 1128.7 1080.2 16516 Tape Read 1 0.039 0.039 0.039 Tape Write 129 28.167 0.218 0.547 1154.2 2126.3 32512 Data Copy 127 0.080 0.001 0.000 Network Recv 2094 107.587 0.051 5.923 152.3 1071.5 16384 Network Send 198 0.021 0.000 0.000 39647.0 54.9 840 Acquire Latch 91 44.514 0.489 2.019 Acquire XLatch 359 148.127 0.413 4.327 Thread Wait 2192 106.077 0.048 5.958 Instrumentation output complete. I'm going to open a performance case with Tivoli, but it looks like most of the time is spent in "Acquire Xlatch", anybody have an idea what that is? Any wild guesses are welcome. Thanks Ben
