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

Thanks Art!!!!!!!! mickey dono where you come from maybe aix ibm.... AIX does not support that feature if i recall correctly... maybe they do now dono, ayways some years ago i had an aix customer who did a lot of filesystem i/o and ran an informix database who would have committed a crime to get that feature.... it is/was hard to make the other apps to back off regarding mem consumtion specially fs io Superboer. On 1 mrt, 17:04, "Art S. Kagel" <k...@BLOOMBERG.NET> wrote: > 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

I've had this same problem on AIX 5L due to the filesystem cache that is turned on by default. This was not and issue on AIX 4.3.3 and during initial testing on 5L I actually managed to get a box to completely freeze up after running out of paging space. The only way out of the problem was to do a hard reboot (yepp, that's the power button!). This was caused by a small application that was massive IO on large files on a filesystem. After extensive reseach I did found a way to turn off the filesystem cache by mounting the filesystems with a special option (mount -o rbrw <filesystem>; can also be set in the /etc/filesystems file or via smitty). Another way to avoid filesystem data to fill up physical memory and to protect application shared memory segements (i.e. Computational Memory) on AIX 5L is to lower the maxperm/minperm/ maxclient OS parameters or, as now recommended, to set the lru_file_repage parameter to 0. It seems as though Linux won't let you do these kind of things. I'll continue with posting this on a linux user group to hear if anyone there has had any experience with it. Thank you all for you input. RoB