You know it is a z800 IFL. ;) And yes a z9 is much faster, but not so much
faster than it will make that much of a difference. Much as it pains me to say
it, it is not just folklore that xSeries chips can do a whole lot of
processing, enough to make them serious contenders now for scientific
processing or relatively large data crunching tasks.
A z/9 IPF is at least 2.4 times the speed of a 2066 IFL, but in terms of sheer
data crunching, the xSeries chips we are using here are about 6x the data
crunching power. (Heck, a blade here they will *emulate* over 240 Mainframe
MIPS running z/Linux with Hercules, which is quite portable but at teh expensse
of efficiency. They are at least an order of magnitude faster running native
code, and probably two or possibly even three magnitudes faster.)
TSM is really *really* due for an overhaul in terms of efficieny and speed.
In comparison; z/Linux running under z/VM on on a z IFL sharing with other
systems (and at a lower priority!! <grin>) can back up the same files to the
same tapes using tar in a little over two hours. TSM on the same hardware, same
Linux instance, and same tapes backing up the exact same files - 21 hours when
the database is full. About 12 when it is empty. Something just "ain't" right
there.
For comparision, tar on the blade will max out in terms of I/O and take about
2.4 hours to backup those same files to the same tape. It varies with TSM, but
four to six hours is the normal now I think, but that is with only 10 days oif
rentition! NOT 45.
A final point - an IFL costs $125K and up; a blade costs $11K, all other
things being equal. Two IFLs to run TSM is a quarter of million dollars, while
even 5 blades is only about $55K. Not saying those five blades can do what the
IFLs can do of course, but in this one task, with this one ornery hunk of
software, I believe they are a btter solution. At least until the TSM peopel
get off their duffs and do something about the bloated out of date ill executed
... oh well, you get the idea.
-Paul
--- Begin Message ---
Ok, I had to ask. But also, which flavor IFL are you running? A z800 might be
considered
slow (or very slow) by some and not competitive, and a z9 might be considered a
"rocket
ship".... Personally, the z9 IFL makes us competitive on a CPU basis (except
for weather
modeling and things like that).
Paul Raulerson wrote:
> Nope, but I sure wish it were so Barton. We need a performance monitor
> anyway, and that would be just more fuel for the fire. :)
> What blew us away was a very simple desire to backup around 4 to 6 million
> files per night, store them on tape, and keep about 45 days of them on hand.
> Yes, this is perhaps "primitive" compared to what TSM can do, but we figured
> that was all the more to the better- it would be able to do it without any
> trouble.
> The sheer number of the files brought the machine here to it's knees - not
> because of the I/O, but because of the database transactions and the really
> huge size of the database after about of, three weeks. Tried it on bare metal
> as well, eliminating z/VM and every thing other possible source of any kind
> of overhead. Zang... BTW: That hugh size of te database was only a coupe
> hundred gigabytes, but the IBM TSM people goggled in horror at it... That was
> worth the trip to see! :)
> The blades have not even a fraction of the I/O throughput of the mainframe,
> but with four cores cranking on the database, we actually get four to five
> times higher throughput. I'm thinking of tossing a second blade at it if I
> can get 'em t share the TS1120s.
> Sometimes, no matter how clever or intelligent you are about using CPU
> resources, you just near to pour enormous numbers of cycles at a problem. At
> least, that is the TSM way... ;)
> -Paul
>
>
>
> Paul, any chance you are having an easily fixable performance problem with
> TSM backups
> that a decent performance monitor will point out?
>
>
>
> Paul Raulerson wrote:
>
>
>>What are you running on Mark? And how much are you backing up. I really need
>>some GOOD
>
> examples of TSM working! :)
>
>>I do have a large number of document images to back up each day, so what
>>happens to us
>
> is the database gets really large, well over a hungred gigabytes. At htat
> point, it
> cannot expire information before new backups are being added, and it *all*
> goes downhill
> from there. I blame the ancient version of DB/2 that is embededed it in, and
> the Linux
> kernel version that is required to run a TSM server on z/Linux on an IFL.
>
>>-Paul
>>
>>
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>Subject:
>>Re: zSeries Linux - White Paper for Management
>>From:
>>"Mark Wheeler" <[EMAIL PROTECTED]>
>>Date:
>>Thu, 27 Sep 2007 19:23:00 +0000
>>To:
>>IBMVM@LISTSERV.UARK.EDU
>>
>>To:
>>IBMVM@LISTSERV.UARK.EDU
>>
>>
>>Really? That hasn't been my experience at all. Runs like a rocketship here.
>>
>>Mark L. Wheeler
>>IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144
>>Tel: (651) 733-4355, Fax: (651) 736-7689
>>mlwheeler at mmm.com
>>
>>“Extraordinary claims require extraordinary evidence." Carl Sagan
>
>
>
--- End Message ---
