On Tue, 2012-10-30 at 12:15 -0500, Duerbusch, Tom wrote: > Don't discount the DASD system on a z box.
We don't. That's why all our database applications run on Z-Linux. We just need a super-fast cache that a virtual platform has a problem with. > > My IBM DS6800 manual states that a properly configured DS6800 can support > 330,000 I/Os per second. Obviously, no one actually has a properly > configured DS6800 (and I assume that the DS8*** boxes are even better). We use DS8800's and they work as advertised - once you get around to actually doing I/O. > > My point is that the PC I/O system really pales compared to a modern > mainframe. If your application needs to support 10,000 I/Os per second or > so, you won't need the "tricks". The real "trick" is configuring DASD ;) It's not the r/w's that are killing us - it's the latency on a small subset of our workload. Http queries that should be sub-second suddenly take 2-4 or even 30 seconds. Maybe because we have 3 or 4 JVM's and 20 virtual machines up and running. Or maybe because there's something wrong with our DS8800 configuration, I dunno. > > And, of course, a good performance monitor can, more easily, point you to > where any performance bottlenecks are. Last time I got a quote on one of those, it cost twice what an 1-u server with 256 GB memory costs. And then you have to learn to use it, and watch it. With the Intel server, I put it in, it solves the latency problem and I can get back to applications work. Roger Autodata Norge A/S > > Tom Duerbusch > THD Consulting > > On Tue, Oct 30, 2012 at 9:00 AM, David Boyes <[email protected]> wrote: > > > >But our Z enthusiast > > > says we can put Redis and memcache on Z-Linux (under VM) without any > > > loss of functionality or performance (because we have extra capacity and > > > "paging on Z doesn't cost anything"). > > > > I'd agree on functionality, but performance is a harder question. Both > > redis and memcache build and run fine on Z, no problems there. The trick is > > that memory usage in a shared environment is much trickier to calculate the > > impact of mass allocations of RAM -- depends a lot on where and how fast > > you page, whether you have XSTOR or not, etc, etc, etc,. > > > > I'd try it with a smaller database and see how it goes. XSTORE will have a > > measurable impact, as will use of VDISK for paging. > > > > ---------------------------------------------------------------------- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO LINUX-390 or > > visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > ---------------------------------------------------------------------- > > For more information on Linux on System z, visit > > http://wiki.linuxvm.org/ > > > > > > -- > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
