Re: Question about Linux VM tuning for IDS

Ian Michael Gumby wrote: > > If Informix acts the way you say, either one of two things. > > 1) You don't have enough memory. > 2) Informix was poorly designed. Not an Informix issue Mickey. Modern UNIX style OS's regard IO cache as primary for performance and feel free to steal memory from other purposes in order to increase cache to speed IO operations. In the case, as Superboer mentions, of an ontape -s -L 0 to a disk file that's cooked. Linux in particular is aggressive about increasing the percentage of memory dedicated to cache dynamically and is less nice about returning cache to the global memory pool. Although Solaris is not much better at least it lets you set a maximum on the percent of memory it will steal. I don't think that Linux has such a parameter (Linux gurus feel free to comment). Reducing the global memory pool will have effects, even if Linux abides by the memlock() call, such as: o Increased swapping of other memory will eat IO bandwidth and OS-CPU resources o Increased swapping of non-resident Informix memory segments (makes RESIDENT -1 important) o Reduced task scheduling efficiency within the OS - IDS threads are peripherally affected when an oninit takes longer to get timeslices from the OS > The size of the level 0 back up should not effect the amount of memory > being used to the point that it will swap out the IDS engine. What > you're implying is that during the IO process, you're filling up all the > pages in memory and forcing the system to swap as it writes to disk. Indirectly yes. When the OS sees the cache being used by many dirty pages it will, at some point, decide to increase the size of the cache and that WILL 'fill up pages in memory' with cache and force other memory to swap out. > That should not or never be the case if you have enough memory for the > system the way you've tuned your system. SOlaris by default allows up to 70% or memory to be dynamically allocated to the buffer cache. For a database server like IDS with it's own cache this is rediculous, so yes, such machines should be tuned down to something like 10-15% of memory max (especially when that is 10-15% of multiple GBs or main memory). However, as I said, some OSes, Linux as an example, don't allow you to limit their innate intelligence about how to manage the buffer cache and that's where you get into trouble. > Note that you can see a slowdown of performance due to I/O issues as you > read from disk and write to tape. True. But only part of the problem. > If you're I/O bound, that will have a negative hit on performance. Also true. But only part of the problem. <SNIP> Art S. Kagel

Under Solaris, the mechanism used to 'steal' pages becomes more aggressive as the amount of 'free' memory decreases, the two thresholds are tuneable and I believe can be changed while the system is running. If you are swapping under Solaris as opposed to paging then you are totally screwed and you need more memory. Paul Watson Tel: +44 1414161772 +1 913-400-2620 Mob: +44 7818003457 +1 913-636-2858 Web: www.oninit.com Failure is not as frightening as regret. Attend IDUG 2007 San Jose, North America May 6-10, 2007 Visit http://www.iiug.org/conf for more information. > -----Original Message----- > From: Art S. Kagel [mailto:kagel@bloomberg.net] > Posted At: 01 March 2007 10:05 > Posted To: comp.databases.informix > Conversation: Question about Linux VM tuning for IDS > Subject: Re: Question about Linux VM tuning for IDS > > > Ian Michael Gumby wrote: > > > > If Informix acts the way you say, either one of two things. > > > > 1) You don't have enough memory. > > 2) Informix was poorly designed. > > Not an Informix issue Mickey. Modern UNIX style OS's regard > IO cache as primary for performance and feel free to steal > memory from other purposes in order to increase cache to > speed IO operations. In the case, as Superboer mentions, of > an ontape -s -L 0 to a disk file that's cooked. Linux in > particular is aggressive about increasing the percentage of > memory dedicated to cache dynamically and is less nice about > returning cache to the global memory pool. Although Solaris > is not much better at least it lets you set a maximum on the > percent of memory it will steal. I don't think that Linux > has such a parameter (Linux gurus feel free to comment). > > Reducing the global memory pool will have effects, even if > Linux abides by the memlock() call, such as: > > o Increased swapping of other memory will eat IO > bandwidth and OS-CPU resources > o Increased swapping of non-resident Informix memory > segments (makes RESIDENT -1 important) > o Reduced task scheduling efficiency within the OS - > IDS threads are peripherally affected when an oninit takes > longer to get timeslices from the OS > > > The size of the level 0 back up should not effect the > amount of memory > > being used to the point that it will swap out the IDS engine. What > > you're implying is that during the IO process, you're > filling up all > > the pages in memory and forcing the system to swap as it > writes to disk. > > Indirectly yes. When the OS sees the cache being used by > many dirty pages it will, at some point, decide to increase > the size of the cache and that WILL 'fill up pages in memory' > with cache and force other memory to swap out. > > > That should not or never be the case if you have enough > memory for the > > system the way you've tuned your system. > > SOlaris by default allows up to 70% or memory to be > dynamically allocated to the buffer cache. For a database > server like IDS with it's own cache this is rediculous, so > yes, such machines should be tuned down to something like > 10-15% of memory max (especially when that is 10-15% of > multiple GBs or main memory). However, as I said, some OSes, > Linux as an example, don't allow you to limit their innate > intelligence about how to manage the buffer cache and that's > where you get into trouble. > > > Note that you can see a slowdown of performance due to I/O > issues as > > you read from disk and write to tape. > > True. But only part of the problem. > > > If you're I/O bound, that will have a negative hit on performance. > > Also true. But only part of the problem. > > <SNIP> > > Art S. Kagel