> Hi Christo,
>=20
> We have 7 TSM-servers at OS/390.
> In time we managed 200 millions Files. The largest db is 74 GB.
> We have no problems with the hardware. The problem is TSM =
because=20
we have no BMR or HSM from IBM. Only from "partners" =
who
part of=20
veritas or legato ...
> We backed up 5 TeraBytes per night (with osa-ge and 2
> infospeed-gateways),=20
> from 1800 clients and 800 server.
>=20
> I see the problem too by adsm 3.xxx. So we waited with =
MPTHREADING
> until
> we have 4.1. I dont=B4 see the problem in time. What Version =
of *sm
> you use ?
>=20
> I hope you understand my bad english.
>=20
> regards Helge
>=20
> van de Kraan
> IS-Rechnersysteme
> =09
> Volkswagen AG=20
> Brieffach 1883
> 38436 Wolfsburg
> =09
> Telefon +49 (5361)9-73711
> Telefax +49 (5361)9-29289
> http://www.volkswagen.de
> =20
>=20
>=20
> =20
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: Christo Heuer [SMTP:christoh AT absa.co DOT za]
> Gesendet am: Mittwoch, 20. M=E4rz 2002 11:55
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: People running OS/390 TSM servers - =
maybe
> for the development guys......
>=20
> Hi all,
>=20
> 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:
>=20
> 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.
>=20
> 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:
>=20
> 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?
>=20
> 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."
|
