Re: onmode -F: is it just HP-UX?

> > >>onstat -g aft may give you a clue (by the address) as to what is being used in the virtual segments which cannot be released.> doh! onstat -g afr > > I'll do that, thanks. I'll also set SHMADD to 64Mb (up from 8) in > future. >

And in my travels, I always felt that the cleaning up with "onmode -F" is done in a LIFO fashion...(last in first out). Never tested it nor proved it, but seemed to be the case, although I have to admit, I haven't used nor worried about using this onmode flavor for a long time since most engines have very large segments by the time i leave the site. In other words, I DO find that most clients under-configure the virtual segments....my last site had about 16G of memory on a box, and one engine. It's memory footprint when I got there was 900M - when I left it about about 11G. Currently onsite w/ an 8G box...and then engine so far is around 2G only. I know there are times that this makes sense....it's jjust that when I arrive clients have very similar complaints about performance, and growing the memory footprint (whether virtual or resident...) in most cases helps tremendously. I don't think we have explained well enough over the years how many very common (and critical) operations benefit from a large footprint - whether it be in the buffer cache or sort pools or PDQ stuff. When I finish the current white paper, I'll start on that one. Mark Scranton Informix 1995-2006 TBP (The Big Potato) wrote: > > > > > >>onstat -g aft may give you a clue (by the address) as to what is being used in the virtual segments which cannot be released.> > > > doh! > > onstat -g afr> > > > > I'll do that, thanks. I'll also set SHMADD to 64Mb (up from 8) in > > future. > >

Mark, I don't think it always applies that more shared memory is the best thing for performance. I am currently investigating a situation where we have found that 1 Gbyte of shared memory does not get used at all. I am trying to reduce high levels of paging and that 1 Gbyte might alleviate the symptom. However, I would agree that in general many systems are under-configured. Could this be due in any small part to the defaults supplied with onconfig.std? They were set when we were lucky to have a few hunded Mbytes of Ram and don't appear ever to have been changed. Oh hiow I wish that more people would attend training before implementing IDS..... Regards Malcolm -----Original Message----- From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] On Behalf Of mark.scranton@gmail.com Sent: 17 October 2006 02:08 To: informix-list@iiug.org Subject: Re: onmode -F: is it just HP-UX? And in my travels, I always felt that the cleaning up with "onmode -F" is done in a LIFO fashion...(last in first out). Never tested it nor proved it, but seemed to be the case, although I have to admit, I haven't used nor worried about using this onmode flavor for a long time since most engines have very large segments by the time i leave the site. In other words, I DO find that most clients under-configure the virtual segments....my last site had about 16G of memory on a box, and one engine. It's memory footprint when I got there was 900M - when I left it about about 11G. Currently onsite w/ an 8G box...and then engine so far is around 2G only. I know there are times that this makes sense....it's jjust that when I arrive clients have very similar complaints about performance, and growing the memory footprint (whether virtual or resident...) in most cases helps tremendously. I don't think we have explained well enough over the years how many very common (and critical) operations benefit from a large footprint - whether it be in the buffer cache or sort pools or PDQ stuff. When I finish the current white paper, I'll start on that one. Mark Scranton Informix 1995-2006 TBP (The Big Potato) wrote: > > > > > >>onstat -g aft may give you a clue (by the address) as to what is> >>being used in the virtual segments which cannot be released. > > > > doh! > > onstat -g afr> > > > > I'll do that, thanks. I'll also set SHMADD to 64Mb (up from 8) in > > future. > > _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list

malcolm weallans wrote: > Mark, > I don't think it always applies that more shared memory is the best thing > for performance. I am currently investigating a situation where we have > found that 1 Gbyte of shared memory does not get used at all. I am trying > to reduce high levels of paging and that 1 Gbyte might alleviate the > symptom. However, I would agree that in general many systems are > under-configured. Could this be due in any small part to the defaults > supplied with onconfig.std? They were set when we were lucky to have a few > hunded Mbytes of Ram and don't appear ever to have been changed. Oh hiow I > wish that more people would attend training before implementing IDS..... <SNIP> Then what would you do all day Malcolm? ;-( Art S. Kagel

malcolm weallans wrote: > Mark, > I don't think it always applies that more shared memory is the best thing > for performance. I am currently investigating a situation where we have > found that 1 Gbyte of shared memory does not get used at all. I am trying > to reduce high levels of paging and that 1 Gbyte might alleviate the > symptom. However, I would agree that in general many systems are > under-configured. Could this be due in any small part to the defaults > supplied with onconfig.std? They were set when we were lucky to have a few > hunded Mbytes of Ram and don't appear ever to have been changed. Oh hiow I > wish that more people would attend training before implementing IDS..... <SNIP> Then what would you do all day Malcolm? ;-( Art S. Kagel