Re: DB2 direct i/o question
We are moving away from DB2 - to Oracle LoZ. Gerard -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Barton Robinson Sent: Friday, July 30, 2010 2:57 PM To: LINUX-390@vm.marist.edu Subject: Re: DB2 direct i/o question But, Oracle is VERY virtual friendly, and DB2 is VERY virtual HOSTILE. From a system performance perspective, I REALLY LIKE Oracle. Mark Post wrote: >>>> On 7/30/2010 at 12:03 PM, Marcy Cortes >>>> wrote: >> Does this make Oracle a better fit on Linux on z than DB2? > > That depends on how much you care about newer versions being certified > sometime within your life time. > > > Mark Post > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: DB2 direct i/o question
But, Oracle is VERY virtual friendly, and DB2 is VERY virtual HOSTILE. From a system performance perspective, I REALLY LIKE Oracle. Mark Post wrote: On 7/30/2010 at 12:03 PM, Marcy Cortes wrote: Does this make Oracle a better fit on Linux on z than DB2? That depends on how much you care about newer versions being certified sometime within your life time. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: DB2 direct i/o question
Mark wrote: >That depends on how much you care about newer versions being certified >sometime within your life time. Very good point. That's a concern too. Marcy -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: DB2 direct i/o question
>>> On 7/30/2010 at 12:03 PM, Marcy Cortes >>> wrote: > Does this make Oracle a better fit on Linux on z than DB2? That depends on how much you care about newer versions being certified sometime within your life time. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: DB2 direct i/o question
Klaus wrote: "This is a DB2 limitiation which others, e.g. Oracle on zLinux, do not have." Yes. What is up with that IBM? Does this make Oracle a better fit on Linux on z than DB2? Marcy -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: DB2 direct i/o question
On Mon, 26 Jul 2010 10:17:51 -0500 Marcy Cortes wrote "After reading some more, it turns out you cannot do direct i/o on linux for z if you are using ECKD dasd, only FCP." This is a DB2 limitiation which others, e.g. Oracle on zLinux, do not have. Klaus Bergmann -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: DB2 direct i/o question
On Tue, Jul 27, 2010 at 2:24 AM, Shane G wrote: > Short answer, no. > > On Tue, Jul 27th, 2010 at 1:17 AM, Marcy Cortes wrote: > >> Is there a way to limit the amount of memory used for page cache? Longer answer: only by not giving Linux a lot of memory in the first place... by avoiding larger swappiness for low utilized servers the drop from queue, or if that does not work, by driving CMM based on perceived resource requirements. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: DB2 direct i/o question
Short answer, no. This was discussed earlier in the year - see: http://www.mail-archive.com/linux-390@vm.marist.edu/msg55911.html Shane ... On Tue, Jul 27th, 2010 at 1:17 AM, Marcy Cortes wrote: > Is there a way to limit the amount of memory used for page cache? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: DB2 direct i/o question
After reading some more, it turns out you cannot do direct i/o on linux for z if you are using ECKD dasd, only FCP. Which I guess is why the default is off on this platform but not on Intel. Is there a way to limit the amount of memory used for page cache? Marcy "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Rob van der Heij Sent: Saturday, July 24, 2010 1:58 AM To: LINUX-390@vm.marist.edu Subject: Re: [LINUX-390] DB2 direct i/o question On Sat, Jul 24, 2010 at 4:28 AM, Shane G wrote: >> Does this imply that the best setting for Linux on z is to use the FILE >> SYSTEM CACHING (Direct i/o disabled)? Now that DB2 can, that's probably a good motivation for doing measurements... I have mixed feelings about their defaults... We do see frequently that in a memory constrained Linux system, pulling all data through page cache actually causes things to be swapped out (or dropped from memory) that the application needed to work on (insert picture of dog chasing his tail). When the application is doing its own data cache, it does not help if Linux also caches it. > I won't presume to be able to answer that, but I will observe that Linus has > made some very harsh comments about database developers and their insistence > on using direct I/O. > In a virtualised environment their desire for total control of everything > would appear to be even more pointless. > I have also sat in on talks by said developers - they insist they can't > possibly get any performance without direct I/O. About the pot calling the kettle black... with Linux running in a virtual machine, attempts of Linux memory management to optimize the usage of "all its resources" is not really productive when those resources are virtual. I think we all agree that it's rarely a good thing to have multiple managers. If you can't avoid that, then it is best when most of them do nothing. If it were clear and obvious which ones to cut out, we'd done so. Objective is both to reduce the cost of management and increase effectiveness. If you manage resources on a low level, the cost of management is low. But if that management layer is unaware of the application requirements, it is not very effective... So z/VM paging is cheap and fast, but if we're paging the wrong things, then it is not productive. Having the application do its own cache may be effective, but it's much more expensive. A differentiating factor is the application duty cycle: 2% average utilization does not tell you all. When the application has one period of 30 min activity per day, that's different from 1.25 second of work every minute. In the first case you'd expect z/VM to page out the guest, in the 2nd case you want Linux to manage memory. One of the complications is that Linux lazy write is inside page cache too. That's good as long as you have plenty of memory, but in a constrained environment you may find the application block on reads because the flush daemon is pacing the writes. In that case the application would rather have managed both himself. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: DB2 direct i/o question
On Sat, Jul 24, 2010 at 4:28 AM, Shane G wrote: >> Does this imply that the best setting for Linux on z is to use the FILE >> SYSTEM CACHING (Direct i/o disabled)? Now that DB2 can, that's probably a good motivation for doing measurements... I have mixed feelings about their defaults... We do see frequently that in a memory constrained Linux system, pulling all data through page cache actually causes things to be swapped out (or dropped from memory) that the application needed to work on (insert picture of dog chasing his tail). When the application is doing its own data cache, it does not help if Linux also caches it. > I won't presume to be able to answer that, but I will observe that Linus has > made some very harsh comments about database developers and their insistence > on using direct I/O. > In a virtualised environment their desire for total control of everything > would appear to be even more pointless. > I have also sat in on talks by said developers - they insist they can't > possibly get any performance without direct I/O. About the pot calling the kettle black... with Linux running in a virtual machine, attempts of Linux memory management to optimize the usage of "all its resources" is not really productive when those resources are virtual. I think we all agree that it's rarely a good thing to have multiple managers. If you can't avoid that, then it is best when most of them do nothing. If it were clear and obvious which ones to cut out, we'd done so. Objective is both to reduce the cost of management and increase effectiveness. If you manage resources on a low level, the cost of management is low. But if that management layer is unaware of the application requirements, it is not very effective... So z/VM paging is cheap and fast, but if we're paging the wrong things, then it is not productive. Having the application do its own cache may be effective, but it's much more expensive. A differentiating factor is the application duty cycle: 2% average utilization does not tell you all. When the application has one period of 30 min activity per day, that's different from 1.25 second of work every minute. In the first case you'd expect z/VM to page out the guest, in the 2nd case you want Linux to manage memory. One of the complications is that Linux lazy write is inside page cache too. That's good as long as you have plenty of memory, but in a constrained environment you may find the application block on reads because the flush daemon is pacing the writes. In that case the application would rather have managed both himself. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: DB2 direct i/o question
On Sat, Jul 24th, 2010 at 10:20 AM, Marcy Cortes wrote:
> Does this imply that the best setting for Linux on z is to use the FILE
> SYSTEM CACHING (Direct i/o disabled)?
I won't presume to be able to answer that, but I will observe that Linus has
made some very harsh comments about database developers and their insistence
on using direct I/O.
In a virtualised environment their desire for total control of everything
would appear to be even more pointless.
I have also sat in on talks by said developers - they insist they can't
possibly get any performance without direct I/O.
> Trying to figure out where all this memory is used...
> ceztv14222:~ # free -m
> total used free sharedbuffers cached
> Mem: 15085 14947137 0 26 13835
> -/+ buffers/cache: 1086 13999
> Swap: 3662 3662 0
The memory is (almost) all being used for {disk,page} cache.
If you're concerned about the swap usage, have a look in /proc//smaps.
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu 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/
DB2 direct i/o question
>From the DB2 9.5 doc Prior to Version 9.5, the keyword FILE SYSTEM CACHING was implied if neither NO FILE SYSTEM CACHING nor FILE SYSTEM CACHING was specified. With Version 9.5, if neither keyword is specified, the default, NO FILE SYSTEM CACHING, is used. This change affects only newly created table spaces. Existing table spaces created prior to Version 9.5 are not affected. This change applies to AIX, Linux(r), Solaris, and Windows with the following exceptions, where the default behavior remains to be FILE SYSTEM CACHING: * AIX JFS * Solaris non-VxFS * Linux for System z(r) * All SMS temporary table space files * Long Field (LF) and Large object (LOB) data files in SMS permanent table space files To override the default setting, specify FILE SYSTEM CACHING or NO FILE SYSTEM CACHING Does this imply that the best setting for Linux on z is to use the FILE SYSTEM CACHING (Direct i/o disabled)? Trying to figure out where all this memory is used... ceztv14222:~ # free -m total used free sharedbuffers cached Mem: 15085 14947137 0 26 13835 -/+ buffers/cache: 1086 13999 Swap: 3662 3662 0 Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
