At our site we backup about 230GB per night from our zLinux guests on VM (z/890 w/2 IFLs). The twist here is that it gets sent over a Hypersocket to Tivoli running in our z/OS LPAR, which then writes it to tape along
with everything else being backed up via Tivoli from z/OS and various PC servers. Brian Nielsen On Wed, 14 Feb 2007 13:49:20 +0000, Paul Raulerson <[EMAIL PROTECTED]> wrote: >We may be in a rather unique situation then. >I typically backup on the zLinux side, about 160BG/night, 80 gigabytes o f 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 lo t 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 i t 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 hundre d 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 th e future. >-Paul > > > > >From: "Mark Wheeler" <[EMAIL PROTECTED]> >To: IBMVM@LISTSERV.UARK.EDU >Message-ID: <OF4F1CEC24.3F325EBF-ON86257281.0050CB89- [EMAIL PROTECTED]> >Date: Tue, 13 Feb 2007 15:03:00 +0000 >Received: (qmail 25917 invoked by uid 78); 13 Feb 2007 15:33:37 -0000 >Received: from unknown (HELO ns-mr4.netsolmail.com) (10.49.16.163) by 0 with > SMTP; 13 Feb 2007 15:33:37 -0000 >Received: from listserv.uark.edu (listserv.uark.edu [130.184.5.241]) by > ns-mr4.netsolmail.com (8.13.6/8.13.6) with ESMTP id l1DFXain010083 > for <[EMAIL PROTECTED]>; Tue, 13 Feb 2007 10:33:36 -0500 >Received: from listserv (listserv.uark.edu) by listserv.uark.edu (LSMTP for > Windows NT v1.1b) with SMTP id <[EMAIL PROTECTED]>; Tue, 13 > Feb 2007 9:33:36 -0600 >Received: by LISTSERV.UARK.EDU (LISTSERV-TCP/IP release 14.5) with spool id > 37201770 for IBMVM@LISTSERV.UARK.EDU; Tue, 13 Feb 2007 09:33:35 -0600 >Received: from cavern.uark.edu by listserv.uark.edu (LSMTP for Windows N T v1.1b) > with SMTP id <[EMAIL PROTECTED]>; Tue, 13 Feb 2007 9:33:35 > -0600 >Received: from tuvok3.mmm.com (tuvok3.mmm.com [192.28.4.40]) by > cavern.uark.edu (8.13.8/8.13.8) with ESMTP id l1DFXSPN014253 f or > <IBMVM@LISTSERV.UARK.EDU>; Tue, 13 Feb 2007 09:33:29 -0600 (CS T) > (envelope-from [EMAIL PROTECTED]) >Received: from mccoy4.mmm.com ([192.28.4.41]) by tuvok3.mmm.com > (8.12.10/8.12.9) with ESMTP id l1DF3G0u009537 for > <IBMVM@LISTSERV.UARK.EDU>; Tue, 13 Feb 2007 09:03:16 -0600 (CS T) >Received: from us-mail-09.mmm.com ([169.10.11.102]) by mccoy4.mmm.com > (8.12.10/8.12.9) with ESMTP id l1DF3GEo003131 for > <IBMVM@LISTSERV.UARK.EDU>; Tue, 13 Feb 2007 09:03:16 -0600 (CS T) >X-Mailer: Lotus Notes 653HF719 September 12, 2005 >X-MIMETrack: Serialize by Router on US-Mail-09/US-Corporate/3M/US(Releas e > 6.5.5 HF567|June 12, 2006) at 02/13/2007 09:03:16 AM >X-Scanned-By: MIMEDefang 2.57 on 192.28.4.40 >X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Dat a: > 2007.2.13.71433 >X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='NO_REAL_NAME 0, > __CP_MEDIA_2_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, > __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, > __SANE_MSGID 0, __cbl.abuseat.org_TIMEOUT , > __dnsbl.njabl.org_TIMEOUT , __dynablock.njabl.org_TIMEOUT , > __sbl.spamhaus.org_TIMEOUT ' >Approved-By: [EMAIL PROTECTED] >Sender: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> >In-Reply-To: <[EMAIL PROTECTED]> >Precedence: list >List-Help: <http://listserv.uark.edu/scripts/wa.exe?LIST=IBMVM>, > <mailto:[EMAIL PROTECTED] IBMVM> >List-Unsubscribe: <mailto:[EMAIL PROTECTED]> >List-Subscribe: <mailto:[EMAIL PROTECTED]> >List-Owner: <mailto:[EMAIL PROTECTED]> >List-Archive: <http://listserv.uark.edu/scripts/wa.exe?LIST=IBMVM> >Subject: Re: zSeries Linux - How Many Users? >Reply-to: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> >MIME-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" >Content-Transfer-Encoding: 7bit > ><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 nearl y >such >> a pig...but I digress. > >Interesting... That hasn't been my experience at all. I recently migrate d >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, wi th >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 hig h >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 MIP s. > >I'm not saying this invalidates the experiences of others. Just adding m y >own to the collection. YMMV. > >Mark Wheeler, 3M Company > > >
