At what point does it make sense to split your TSM address space? I have a 28GB 80% utilized DB using TSM 4.1.5 on a 9672-x57 that is running O.K.. I know the DB is going to grow because the TSM requirements are growing. Where should I expect to see problems?
Christo, If your TSM on OS390 is spending all its time doing GETMAIN/FREEMAIN what is your REGION size and available memory? Is the system paging or is TSM trying to live in to small of an address space? Matt -----Original Message----- From: Stumpf, Joachim [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 7:27 AM To: [EMAIL PROTECTED] Subject: Re: People running OS/390 TSM servers - maybe for the development guys...... Hi Christo, we are running TSM-Server 4.1.5 on OS/390. Im not very familiar with this OS/390- MVS- Stuff, but I can tell you that we have 10 TSM-Server running at 1 LPAR. We named the tasks TADSM01-TADSM10. The issue to do so was that we only wanted small databases. Now our dbs are from 7GB - 12GB. -- regards / Mit freundlichen Gruessen Joachim Stumpf Datev eG Nuremberg - Germany Christo Heuer <[EMAIL PROTECTED]> (Mittwoch, 20. März 2002, 11:55:08, CET): > 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." >