Re: Online Performance Tuning Question ??

If you swap it will be slow, tunning on-line will not help. Adding memory will help , but your application may still be slow , I've seen this when users perform very heavy queries via data retrieval tools. You should analyze what those GQL users are doing and a - restructure their queries so there is no severe impact on the system b - alter database to either have views or new tables which conatin the data those users need so their queries can be simple c - create indexes to avoid sequential scans Use onstat -g ses sesid to find out the SQL , grab it , put in dbaccess and run it wiith set explain on. You will probably find sequential scans , outer joins andsql that joins many tables. Doing such queries in an OLTP env is not good. Mariusz Malogrosz Performance Analyst , TECSYS inc. mariuszm@tecsys.com John DeSilva <mcsjads@longtail.ibl.bm> wrote in article <57v95n$s6n@cssun.mathcs.emory.edu>... > We are running 40 people on an HP9000 ( HPUX 9.04 ) and Online 7.11UC1 = > with 256MB. 30 of these are running Order Entry applications (RDS) = > using approx 2MB per user. The system is fine and performace is normally = > good. > Unless...... > We launch a query / reporting tool ( GQL ). We have two users that need > to use this on a regular basis. When the first starts up GQL things slow > down. When the second starts it up the whole thing grinds to a halt. > Symptoms are as follows. > With 40 normal users, the engine is is quite happy. Buffwaits > from an onstat -p show minimal if any increase. Unix swapping is running > at around 20MB. Engine is using about 100MB of memory. > When we start up GQL ( runs local on two macs and accesses data via a > DBACCESS session ) swapping jumps to 88 MB and the buffwaits go through > the roof, increasing by several 000's per minute. PDQ allows for a max = > of 5MB and is only enable for the GQL user login. > > Q. Is it possible that the initial virtual segment of shared memory > (64MB) is being swapped out ? If so would it swap out the entire > segment or only a small part ? If this the reason for the large > jump in unix swapping that we are seeing ??? > > Q. My though here is to increase the # of buffers even though I will be > increasing op sys swapping. The HP9000 seems to handle swapping quite > well. The extra 20 MB of buffers might more than offset the decrease > in performance caused by the extra swapping. ???? > > NB. We see similar problems with performance ( not as pronounced ) when > start a large / lengthy report such as sales analysis reports > or price lists. > My though is that these reports / GQL are flooding the buffers with = > data > not related to OE, and hence the dramatic performance dip and large > increase in the buffwaits statistics. > > Thanks in advance for any help you can be in resolving this. > John DeSilva. > mcsjads@ibl.bm >