We may be in a rather unique situation then.
I typically backup on the zLinux side, about 160BG/night, 80 gigabytes of which
consist of a few million wee little images. (80K is the average size.) On top
of that, I backup 30 Gigabytes from a Microsoft Exchange Server, and 60
Gigabytes of PC file storage, which again consists of a lot of small files. Our
projected load is between 400gb and 700 gb per night.
These are going to two TS1120 tapes connected via Fibre Channel to their own
little Ficon port on the zSeries machine. On an IFL, just doing a simple 'dsmc
archive "/cti/*"' for say, the 80 gigabytes of images, will easily soak up 200
mips, and take over 20 hours. You don't wat me to tell you how long a selective
backup takes... Obivouisly, either something is drastically wrong in the the
zLinux, the tape drivers, or most likely, that pesky database is too damn slow.
(The Database is over 60 gigs at this point.) We are running SuSE 9 at the
required kernel level, and 5.3 on TSM.
I moved the server to (shudder) Windows on an IBM blade with dual processor
dual core AMD chips and plenty of memory - on the theory that it was processor
lock causing the problem. The same command now on the same machine will backup
the 80 gigs of images in about an hour. And that is using the network, not even
touching LAN free operations. I did think about trying Linux on the xSereis
blade, but there are more people here who can handle Windows than can handle
Linux, so...
The end result is that I can do a simple archive each night, which makes people
here happy since the offsite tape rotation is simpler, and it completes in
about 4 hours, which is what I predicited when I bought the things, and is well
within my backup window. We don't have an automated tape library here at this
point, so I really go for simplicity.
Now, on the other hand, we have several interactive applications on zLinux that
we wrote, and they are easily shown to support several hundred users while only
sipping gently at the available MIPS. In theory, we should be able to support
around 3000 simultaneous users on a single instance, but since that application
runs on 31bit Linux, memory limiations would probably hold that to about 1100
users per instance.
We look at out stuff, which is doing quite as much as TSM is doing application
wise, albeit with a different signature for the I/O, and then at TSM, and
wonder how the devil TSM every got out the door for zLinux... I'm glad your
expereince is different, that means there may be hope in the future.
-Paul
--- Begin Message ---
<snip>
>
> > Take Tivoli Storage Manager for instance...
>
> Please do take it -- as the play says: "God bless and keep the Tsar...
far
> away from us!" That's a good example of an inefficient and poorly
> application on ANY platform. Funny thing, the CMS version wasn't nearly
such
> a pig...but I digress.
Interesting... That hasn't been my experience at all. I recently migrated
from ADSM/VM to TSM on zLinux and didn't see a significant difference in
MIPs consumption. I haven't had any problems keeping multiple STK 9940
tapes busy at 30-40 MB/sec each. I back up about 30 GB/night, on average.
Morning housekeeping activities (expiration/migration/dbbackup) averages
30-50 MIPs for an hour or so. DB is 38 GB, 62% full, 38 million objects, 12
TB storage. Backups at night consume an average of less than 20 MIPs, with
exception of one 40-50 MIP spike for an hour or so. I have seen initial
backups of large clients run at 1.5+ TB/day. The only time I've seen high
I/O rates to the DB was when I ran a GENERATE BACKUPSET of a 4 TB node. For
brief periods I would see as many as 2500 IOs/sec and as much as 200 MIPs.
I'm not saying this invalidates the experiences of others. Just adding my
own to the collection. YMMV.
Mark Wheeler, 3M Company
--- End Message ---
