What release of OS/390 are you on? If it's an older release without TCP having been incorporated into the USS, then you will see a lot of get/freemains. I had an issue that I actually got to talk to a developer about and we had a nice discussion about lots of things. One of them being where TSM can use the BPX socket calls instead of the standard TCP socket calls. He said that the conversion under the covers from the TCP socket calls to the BPX calls and back again was a BIG overhead. He said you could see 40% or more of CPU reduction moving to native BPX. He said you probably wouldn't see much throughput difference unless you were moving to the new Gigabit OSA cards.
We have a TSM server running on an LPAR on a 9672-R44 with OSA-2 Fast Ethernet cards. The disk is IBM ESS with 8 CHPID's to each, but the Magstar 3590B's are a bottle neck, too. Actually, I think ESCON is a bottleneck at only 15MB/sec. I see about a 10-12GB/hour backup throughput via the OSA-2's. I see about 25GB/hour tape throughput. CPU during the backup window runs high, but this is running on a test/dev LPAR so that's not much of an issue. I would like to get off this platform because of the tape throughput issues. We're starting to backup more data than I can process for COPYPOOLing in the available time before the next backup window occurs. The TSM DB is 18GB at about 70%. That backup takes almost an hour. Because of the amount of time to backup and restore the TSM DB, we are thinking of a different approach. Since we have an ESS and Flashcopy, we are concidering bring TSM down at the point where we normally do the BACKUP DB and then using Flashcopy to create full disk copies of the volumes where the DBVOLUMES reside. Then bring TSM back up. With Flashcopy, this process should only take about 2-minutes. Then the flashcopy volumes would be backed up to tape with DFDSS and sent offsite. Bill Boyer DSS, Inc. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Christo Heuer Sent: Wednesday, March 20, 2002 5:55 AM To: [EMAIL PROTECTED] Subject: People running OS/390 TSM servers - maybe for the development guys...... Hi all, OK - For those of you that does not know anything about OS/390 or don't run TSM servers on OS/390 this might be very boring and maybe a bit cryptic - ignore or just read for the fun. Now for the people that still run OS/390 TSM servers: I have always had my doubts about the scalability of OS/390 when it comes to a TSM server. Some of you might have seen me posting last year and early this year about the size of your TSM environment and if you are happy with the performance of TSM on OS/390 - only one guy answered giving me specs on the environment they run(Thanks to William Colwell), but other than that most people said they moved off OS/390 and are now running AIX or Sun or even Win2K servers. William described their environment as an 80 Mips processor box and a 166Gig db 88% used - and on top of all that he has good performance from this. Our environment is a 38 Gig db 80% used and we have crappy performance. Now in Adsm V3 a new parameter was introduced called MPTHREADING YES or NO. What this does is tell TSM that it can start multiple TCB's on multiple CP's - if you have multiple CP's on your box. Now we enabled this and noticed that TSM gets its knickers in a knot when there are too many things happening and the system is CPU constrained. In WLM it is guarenteed to get CPU and in WDM you can see that about 30% of the time it is delayed for CPU. What we have done now in Omegamon is to check how many work each of the TCB's does and then try and figure out why TSM would perform crappy even though it is getting about 50% of the total box. Now - here comes the part where development might be able to shed some light: The TCB called dsmserv (the server task), has a lmod caled IEANUC01 that has a CSECT of IGVGPVT that uses about 90-95% of all the CPU cycles - remember that this is one TCB assigned to one CP. On further investigation our IBM'er came back and said this IGVGPVT part controls getmain/freemain's for TSM. Now here comes the question: How can TSM be using 90% of a CP by just doing getmain/freemain and all the other TCB's that has a CP allocated just sit and wait for getmain/freemain's. This looks like a serious scalability issue with TSM on a multiple CP environment. According to our performance and MVS guys the only way we are going to squeeze more juice out of our OS/390 system with TSM is to split the workload of TSM and run two TSM servers on one LPAR or upgrade each CP to a more powerfull CP. Is this in line with development, and the way it should work? Thanks Christo Heuer ASBA Bank Johannesburg SOUTH AFRICA ______________________________________________ "The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. Absa is neither liable for the proper, complete transmission of the information contained in this communication, any delay in its receipt or that the mail is virus-free."
