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
regards / Mit freundlichen Gruessen
Joachim Stumpf
Datev eG
Nuremberg - Germany
=20
Christo Heuer <christoh AT ABSA.CO DOT ZA> (Mittwoch, 20. M=E4rz 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."
>
|
