Re: Oracle 9.2 on Suse 7.2 S390
David Boyes wrote: Historically, I guess I'm somewhat suspicious of compatibility modes like the mixed mode 31/64-bit stuff. None of the implementations of such code I've ever worked with was sufficient (DEC Alpha, Cray, HP) for production level reliability. Perhaps you folks are better programmers...8-). Compat mode should work well enough; some people are running a full 32-bit userland environment under a 64-bit kernel, and I think some of the IBM middleware is actually certified for 32-bit compat layer on SLES-7 (64-bit) for example. If you know of specific problems, we are always happy to receive bug reports ;-) I also still find that the algorithms used in Linux for buffer management are quite a bit less efficient than the ones used in VM -- that's no slight to the Linux folks, it's what they have to work with Could you be more specific here? If your application issues a read (either buffered or non-buffered) in the VM case and MDC has pre-cached the response by doing a fulltrack read or has previously cached the record, the response time for I/O completion is significantly better than going direct to disk. Well, if the block is already in the page cache, response time will be even more significantly better, as we save the round-trip through CP, SIE intercepts and all ... Simplistic, until you consider that if the same database table is active for multiple database machines, you can do quite a bit of I/O avoidance that isn't possible in the Linux-only scenario. Net win. As soon as you have multiple guests accessing the same disk, shared caching will provide benefits, no arguments about that. However, I'd still consider shared read/write access to be a rare scenario, only exploitable from a few specialized applications at the moment. You also gain the early I/O completion notification from virtualizing DASDFW, although that's more a hardware feature than a VM feature. It does have an impact on write performance in that the write I/O completes much more quickly, and is guaranteed via the NVRAM. And how is that different from Linux using the DASDFW feature directly (actually, we don't even need to do anything, the hardware uses DASDFW by default unless you specifically switch it off)? Is it better? Maybe not. It does however give you a lot more knobs to manipulate the performance of the process. I'm of the opinion that the I/O optimization code in VM has had more time to get optimized, and I find that to be more tunable than the Linux code. It is true that the Linux philosophy generally views lots of tuning knobs with suspicion -- the system is supposed to tune itself, with the existing knobs having more something of a debugging function. Is there anything specific you'd like to be able to tune but cannot? It also has some very inspired hardware feature exploitation code in in that Linux hasn't inherited yet. Time will tell -- you've got plenty of work to keep you busy nights...8-). Is there anything specific you have in mind? (Things that are applicable to modern storage subsystems -- we are not particularly interested in supporting all the quirks of real 3390 devices at this point ...) Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
Re: Oracle 9.2 on Suse 7.2 S390
On Thu, 20 Mar 2003, David Boyes wrote: On Fri, Mar 21, 2003 at 08:12:27AM +0800, John Summerfield wrote: On Thu, 20 Mar 2003, David Boyes wrote: 31-bit systems are limited to 2G storage). Is that actually true if you're running a 2.4 kernel and glibc 2.2? 2048M is the largest virtual machine you can define on a 31-bit OS. As others have said, I had another kind of storage in mind: disk storage and files. Triggered in part from quite a while ago when someone did make a similar comment about files. Another day, I'd have got it right first go. -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Oracle 9.2 on Suse 7.2 S390
In fact, Oracle was one of the folks who lobbied the most for getting 'raw' (uncached by the Linux kernel) device access, and this did in fact turn out to improve Oracle performance (on Linux/Intel). Well, How do i get this done om Linux 390?
Re: Oracle 9.2 on Suse 7.2 S390
Oracle uses only a trivial amount of floating point. I would be *very* surprised if you could measure the amount of CPU time wasted in simulating the Hex Floating point. Oracle requires raw devices only for the Real Application Cluster (RAC) support. Most Oracle on zLinux shops use normal file system I/O. There is no doubt that putting the databases on a striped logical volume gives the best performance. As for the 100% CPU, I suspect it has more to do with the speed of your machine. The G4 is definitely vintage hardware. Most Oracle performance problems are solved by looking at STATSPACK data and tuning. Tom Russell Stay calm. Be brave. Wait for the signs. -- Jasper Friendlybear
Re: Oracle 9.2 on Suse 7.2 S390
On Thu, 20 Mar 2003, Nilson Vieira wrote: What do i to get a better performance ? Even I know that one;-) Get a computer with floating point. Wich software should i use to monitor performance (with documentation)? How much a no float point processor can influence in a negative performance ? Enormously. What are my options ? Get a computer with floating point. -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Oracle 9.2 on Suse 7.2 S390
I've been pondering these questions for some time now. I have a 9672 G4 running Suse Linux 7.2 Lpar mode with Oracle 9.2. We have 1.5 GB of RAM, 115 Mips processor/no float point, with 100% utilization almost all the time. [...] My questions: What do i to get a better performance ? 0) Consider a upgrade to at least a G5-class system. Lack of IEEE FP is probably not completely the problem, but it's not helping your cause here. 1) Move this to a VM environment. The I/O caching and optimization in the VM environment significantly helps Oracle performance. Giving this about .5G of XSTORE for MDISK cache and VDISK helps immensely. 2) The CPU utilization will be high, no matter what. Expect it. 3) Make sure the disks holding the database are striped across as many physical and logical devices as possible, even if the database will fit on a single volume. Performance will be much improved with more spindles to work with. Wich software should i use to monitor performance (with documentation)? In an LPAR, you're pretty much stuck with RMF-PM and the native Linux tools, which probably aren't very helpful for you. If you have a VM system somewhere, look at IBM's FCONX or Velocity Software's ESAMON with the ESALPS addon. Both do a much better job of breaking down the usage data from both VM and Linux into a comprehensive picture. How much a no float point processor can influence in a negative performance ? Quite a bit. Floating point math appears in really strange places. That's probably not the whole story here, but there is an impact. You need more measurements to tell you exactly where, and in an LPAR, you don't have a lot of tools to help you find the problem. What are my options ? #1 best option is to get this thing running as a VM guest. That will give you a lot of ability to find out what's wrong.
Re: Oracle 9.2 on Suse 7.2 S390
David Boyes wrote: 1) Move this to a VM environment. The I/O caching and optimization in the VM environment significantly helps Oracle performance. Giving this about .5G of XSTORE for MDISK cache and VDISK helps immensely. This strikes me as odd, seeing as databases usually want all the layers below them to get out of the way as much as possible; they perform all the caching they need themselves. In fact, Oracle was one of the folks who lobbied the most for getting 'raw' (uncached by the Linux kernel) device access, and this did in fact turn out to improve Oracle performance (on Linux/Intel). Do you have performance data comparing the scenarios? Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
Re: Oracle 9.2 on Suse 7.2 S390
This strikes me as odd, seeing as databases usually want all the layers below them to get out of the way as much as possible; they perform all the caching they need themselves. Except in the case of really large databases where the 31-bit ceiling is significant, or when the system is running in a virtual environment that does not expose all it's capabilities to the database engine. With 64-bit clean code, this may be different, but I haven't gotten to beat on the 64-bit Oracle for Z code yet. The database level caching approach quickly runs into the process size/disk buffer utilization problems that grow the virtual machine WSS (even with raw I/O, you've just traded the system queuing the buffers for the application queuing the buffers), and tends to generate the problem of getting stuck in the bottom of E3 with nowhere to go; symptom: database goes non-responsive. This approach keeps the Linux image smaller, and makes the resource starvation problem less common. It also allows 31-bit guests to take some advantage of large physical storage sizes indirectly (remember, 31-bit systems are limited to 2G storage). In fact, Oracle was one of the folks who lobbied the most for getting 'raw' (uncached by the Linux kernel) device access, and this did in fact turn out to improve Oracle performance (on Linux/Intel). I would expect it to do so on Intel where there's no effective system level disk cache. Since MDC allows Linux I/O to effectively return asynchronously (even without async io in the linux driver and is active even during the Linux raw disk io) you win some nice gains, esp if the disk controllers also have the NVRAM DASDFW turned on. Do you have performance data comparing the scenarios? Since it involves specific customers, we'll discuss that privately off-list, but yes, at least in 1 case so far. -- db
Re: Oracle 9.2 on Suse 7.2 S390
On Thu, 20 Mar 2003, David Boyes wrote: 31-bit systems are limited to 2G storage). Is that actually true if you're running a 2.4 kernel and glibc 2.2? My 32-bit system hasn't had such a limit for quite some time, and I regularly create files larger than that. -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Oracle 9.2 on Suse 7.2 S390
He's talking real storage, not disk. I suspect he's talking _virtual_ storage. -- Phil Payne http://www.isham-research.com +44 7785 302 803 +49 173 6242039
Re: Oracle 9.2 on Suse 7.2 S390
David Boyes wrote: Except in the case of really large databases where the 31-bit ceiling is significant, or when the system is running in a virtual environment that does not expose all it's capabilities to the database engine. With 64-bit clean code, this may be different, but I haven't gotten to beat on the 64-bit Oracle for Z code yet. OK, I can see the benefit of increasing the total amount of memary available for cache. However, note that even without having a 64-bit Oracle, you could still have an equivalent effect by running a 31-bit Oracle under a 64-bit Linux kernel, and giving that kernel lots of memory (to be used as page cache). The database level caching approach quickly runs into the process size/disk buffer utilization problems that grow the virtual machine WSS (even with raw I/O, you've just traded the system queuing the buffers for the application queuing the buffers), and tends to generate the problem of getting stuck in the bottom of E3 with nowhere to go; symptom: database goes non-responsive. Well, this is kind of an unfair comparison. Of course you'll have to make the memory that you use for MDC cache in the one scenario available in full to the guest for its use as cache in the other scenario. In any case, the original poster was running in LPAR where this issue doesn't even come up ... In fact, Oracle was one of the folks who lobbied the most for getting 'raw' (uncached by the Linux kernel) device access, and this did in fact turn out to improve Oracle performance (on Linux/Intel). I would expect it to do so on Intel where there's no effective system level disk cache. Since MDC allows Linux I/O to effectively return asynchronously (even without async io in the linux driver and is active even during the Linux raw disk io) you win some nice gains, esp if the disk controllers also have the NVRAM DASDFW turned on. How is the Linux page/buffer cache any less asynchronous (or any less an 'effective system level disk cache') than VM's MDC? Do you have performance data comparing the scenarios? Since it involves specific customers, we'll discuss that privately off-list, but yes, at least in 1 case so far. Thanks for the reference. In any case, the point I was trying to make is that while VM is of course great for running many guests (and provides a lot of advantages w.r.t. configuration and system administration etc.), in the usual case I would not expect a *single* Linux workload to perform *better* when running under VM as compared to running under LPAR ... If you can find examples that contradict this, I'd be very interested to hear about them, as this would to me imply that there's either a problem in the setup or else a deficiency in the Linux kernel that we'd need to fix. Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
Re: Oracle 9.2 on Suse 7.2 S390
On Fri, Mar 21, 2003 at 01:39:07AM +0100, Ulrich Weigand wrote: 64-bit clean code, this may be different, but I haven't gotten to beat on the 64-bit Oracle for Z code yet. OK, I can see the benefit of increasing the total amount of memary available for cache. However, note that even without having a 64-bit Oracle, you could still have an equivalent effect by running a 31-bit Oracle under a 64-bit Linux kernel, and giving that kernel lots of memory (to be used as page cache). True. As I said, I don't have any data on operating in that type of configuration. For 31-bit code and 31-bit OS, there's a demonstrateable advantage. Since he's got a 9672, that's the environment he's in. Historically, I guess I'm somewhat suspicious of compatibility modes like the mixed mode 31/64-bit stuff. None of the implementations of such code I've ever worked with was sufficient (DEC Alpha, Cray, HP) for production level reliability. Perhaps you folks are better programmers...8-). The database level caching approach quickly runs into the process size/disk buffer utilization problems that grow the virtual machine WSS (even with raw I/O, you've just traded the system queuing the buffers for the application queuing the buffers), and tends to generate the problem of getting stuck in the bottom of E3 with nowhere to go; symptom: database goes non-responsive. Well, this is kind of an unfair comparison. Of course you'll have to make the memory that you use for MDC cache in the one scenario available in full to the guest for its use as cache in the other scenario. In any case, the original poster was running in LPAR where this issue doesn't even come up ... Although he correspondingly loses significant manageability and instrumentation capability, which was part of his trouble in the first place. Again, I'm looking at 31-bit only environments; can't tell you whether it would work better in a mixed-mode environment or in a native 64-bit environment. I also still find that the algorithms used in Linux for buffer management are quite a bit less efficient than the ones used in VM -- that's no slight to the Linux folks, it's what they have to work with -- and that getting VM to do something more efficiently than Linux can is pretty much always a net win. I would expect it to do so on Intel where there's no effective system level disk cache. Since MDC allows Linux I/O to effectively return asynchronously (even without async io in the linux driver and is active even during the Linux raw disk io) you win some nice gains, esp if the disk controllers also have the NVRAM DASDFW turned on. How is the Linux page/buffer cache any less asynchronous (or any less an 'effective system level disk cache') than VM's MDC? Think about this way: In the Linux case, you have: application -- system cache -- disk or application -- disk (in the case of raw disk io) This is all fine and good, subject to the fairly weak buffer management capability in the stock Linux environment. In the VM case, you have: application -- Linux system cache -- MDC (read) -- cntl unit -- disk DASDFW or application -- MDC -- cntl unit -- disk (in the case of raw io) DASDFW with a stronger cache and I/O optimization algorthm managing the real disk I/O over multiple machines, which would be needed in a HA situation (I don't know of anyone running Oracle for real that uses a single server to host a critical database. If they do, they've got other problems bigger than this one). If your application issues a read (either buffered or non-buffered) in the VM case and MDC has pre-cached the response by doing a fulltrack read or has previously cached the record, the response time for I/O completion is significantly better than going direct to disk. Simplistic, until you consider that if the same database table is active for multiple database machines, you can do quite a bit of I/O avoidance that isn't possible in the Linux-only scenario. Net win. You also gain the early I/O completion notification from virtualizing DASDFW, although that's more a hardware feature than a VM feature. It does have an impact on write performance in that the write I/O completes much more quickly, and is guaranteed via the NVRAM. Is it better? Maybe not. It does however give you a lot more knobs to manipulate the performance of the process. I'm of the opinion that the I/O optimization code in VM has had more time to get optimized, and I find that to be more tunable than the Linux code. It also has some very inspired hardware feature exploitation code in in that Linux hasn't inherited yet. Time will tell -- you've got plenty of work to keep you busy nights...8-). In any case, the point I was trying to make is that while VM is of course great for running many guests (and provides a lot of advantages w.r.t. configuration and system administration etc.), in the usual case I would not
Re: Oracle 9.2 on Suse 7.2 S390
On Fri, Mar 21, 2003 at 08:12:27AM +0800, John Summerfield wrote: On Thu, 20 Mar 2003, David Boyes wrote: 31-bit systems are limited to 2G storage). Is that actually true if you're running a 2.4 kernel and glibc 2.2? 2048M is the largest virtual machine you can define on a 31-bit OS. -- db
Re: Oracle 9.2 on Suse 7.2 S390
He's talking real storage, not disk. Mark Post -Original Message- From: John Summerfield [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2003 7:12 PM To: [EMAIL PROTECTED] Subject: Re: Oracle 9.2 on Suse 7.2 S390 On Thu, 20 Mar 2003, David Boyes wrote: 31-bit systems are limited to 2G storage). Is that actually true if you're running a 2.4 kernel and glibc 2.2? My 32-bit system hasn't had such a limit for quite some time, and I regularly create files larger than that. -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
