Mainframes do I/O exceptionally well, but when it comes to compute bound tasks, they do very poorly. If you think about a tar operation, the compression is a fairly compute-intensive operation.
We're running a 9672-R56 w/ one IFL. During our initial trial, we found the IFL to be about the same as a 300 or 400mHz PC for compute-bound tasks. The strength of the mainframe comes in for burst-type execution and I/O throughput. Things like multiple web servers running in individual Linux images. File serving. Anything where: A) The CPU isn't expected to be taxed a great deal. and B) the CPU isn't going to be utilized for long periods of time. This allows the CPU to be shared among a larger quantity of images, giving all of them the impression of a dedicated box. But, if one image starts doing compiles or compression of large quantities of data, or any other CPU bound task, everyone will suffer. ---- Robert P. Nix internet: [EMAIL PROTECTED] Mayo Clinic phone: 507-284-0844 RO-CE-8-857 page: 507-270-1182 200 First St. SW Rochester, MN 55905 ---- "Codito, Ergo Sum" "In theory, theory and practice are the same, but in practice, theory and practice are different." > -----Original Message----- > From: Alex Leyva [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, February 13, 2003 3:10 PM > To: [EMAIL PROTECTED] > Subject: URGENT! really low performance. > > Hi all, i have a problem, we have a z800, the configuration is: > 1 cp 80 MIPS > 1 IFL > 8 Gb storage > 3 partitions: > -os/390 2.6 > -os/390 2.6 > -z/vm 4.3 > 840 gb (shark) > > the cp is dedicated to both os/390, and the ifl to z/vm, 2gb to > both os/390, and 6 gb to z/vm. > > Redhat 7.2 as a z/vm guest: > > [root@linux1 root]# uname -a > Linux linux1.xxx.xxx.xxx 2.4.9-38lvm #1 SMP mii feb 12 12:25:01 CST > 2003 s390 unknown > [root@linux1 s390]# cat /proc/cpuinfo > vendor_id : IBM/S390 > # processors : 1 > bogomips per cpu: 630.78 > processor 0: version = FF, identification = 02900A, machine = 2066 > [root@linux1 s390]# cat /proc/meminfo > total: used: free: shared: buffers: cached: > Mem: 1045737472 364187648 681549824 0 15532032 317743104 > Swap: 409821184 0 409821184 > > > Default installation, the z/vm has one week installed: > > q cplevel > z/VM Version 4 Release 3.0, service level 0201 (64-bit) > Generated at 05/09/02 17:30:26 EST > IPL at 02/07/03 12:13:53 EST > > when we make a tar -gzipping it- from a directory with 100Mb, we have > that: > -the hmc indicates that the ifl is at 99% utilization. > -real time monitor indicates that the processor is at 99% utilization: > | <USERID> %CPU %CP %EM ISEC PAG WSS RES UR PGES SHARE VMSIZE TYP,CHR,STAT | > | LINUX1 99 .15 99 4.4 .00 100K 100K .0 1 50%A 1G VUS,QDS,DISP | > | SYSTEM .08 .08 .00 .00 .00 0 5060 .0 536 ..... 2G SYS, | > | VMRTM .02 .01 .01 .63 .00 462 483 .0 0 3%A 32M VUS,IAB,SIMW | > -"top" at the linux shows: > 30 processes: 27 sleeping, 3 running, 0 zombie, 0 stopped > CPU states: 97.6% user, 2.3% system, 0.0% nice, 0.0% idle > Mem: 1021228K av, 279636K used, 741592K free, 0K shrd, 14120K buff > Swap: 400216K av, 0K used, 400216K free 234992K cached > > we apply some performance related commands like: > set quickdsp linux1 on real > set share linux1 relative 300 real > set share linux1 absolute 50% real > > and the time went from 1m3.6s to 1m2.039s in the better case, the people > from ibm (they are here yet) can give me an answer about the poor > performance (i consider that its a poor performance, because a intel piii > 128Mb RAM make the tar in about 28s), so i really dont know if this is the > real performance of linux under vm, if we are doing something wrong, or> > what, when we bought the z800 they said that with this configuration we > will be able to run about 200 virtual machinnes, maybe thats a fairly > dream? > > Please, i accept any comments, sugestions, or anything that can help us. > > Thanks. > > > -- > Alejandro Leyva Rabinovich. > Jefe de la Unidad Departamental de Soporte Ticnico > (Administracisn de Mainframe). > Direccisn General de Informatica. > Secretarma de Finanzas. > Gobierno del Distrito Federal.
