Re: Online Performance Tuning Question ??
--0__=CQNLSAopMAYotwufGnXR0QUl8Vh2LxD5j3KZwfTS9kAfLWIEJOo7CpHz
Content-type: text/plain; charset=us-ascii
Make your initial virtual shared memory piece larger. When this starts
acting badly, do an
onstat -g seg and count the number of V shared memory segments ("class"). This are
"dynamically" allocated as
needed, but on HP any more than two causes the system to crawl. The only
fix is to make
the initial shared memory segment as big as you think you'll need, and
the shared memory
add segment really big also, so it hopefully will NEVER have to add more
than one additional
shared memory segment.
(Embedded
image moved marks @ west.co.za
to file: 12/04/96 05:34 AM
PIC03010.PCX)
Please respond to marks@west.co.za
To: informix-list @ rmy.emory.edu
cc: (bcc: Kate Tomchik/IS/SSC/THD)
Subject: Re: Online Performance Tuning Question ??
--0__=CQNLSAopMAYotwufGnXR0QUl8Vh2LxD5j3KZwfTS9kAfLWIEJOo7CpHz
John DeSilva wrote:
> > 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.
You shouldn't be swapping at all. This is a performance killer. Why are
you running out of memory? If there is no way round this, then add more
memory.
You are mixing PDQ with OLTP access. This is always VERY difficult to
balance in terms of tuning. Remember that to increase resources and hence
performance for PDQ you should DECREASE the number of buffers. Of course
this is the opposite for OLTP, and finding the balance is always very
difficult. In your case, the situation is exacerbated by the fact that
you have already run out of memory resources.
Your reports are probably using PDQ as well. In your current situation,
you may improve things by switching PDQ off all together. This will
probably help balance resource allocation between your order entry, GQL,
and reports.
Hope this helps,
--
Mark.
+-------------------------------------------------------------------------+
|Mark D. Stock - The West Solutions Group http://www.west.co.za |
| The Informix FAQ is at http://www.iiug.org |
|mailto:marks@west.co.za +------------------------------------------------+
|Tel: +27 11 803 2151 |If it doesn't work... force it! |
|Fax: +27 11 803 2189 |If it breaks... it needed replacing anyway! |
|Cell: +27 83 250 2325 |Well, that's how I code anyway! |
+------------------------+------------------------------------------------+
--0__=CQNLSAopMAYotwufGnXR0QUl8Vh2LxD5j3KZwfTS9kAfLWIEJOo7CpHz
Content-type: application/octet-stream;
name="PIC03010.PCX"
Content-transfer-encoding: base64
CgUBCAAAAABoACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABaQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAD1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPH
E8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sT
zRPHE8MTwhPwEwzIBgzYE8wTxhPDE8IT7hPOBtcTzBPGE8MTE+wTwgbCBwbCEgbCEgbCEsUG1hPL
E8YTwxMT6hMMwgYHwgLCAwISwgfEEsMCwwbVE8sTxRPDExPpE8MGAwcCBwMCwhLDB8ISwgISwgLD
BtUTyhPFE8MTE+gTwgIHA8ICEw4DDgLDE8USwwLCEMIG1BPKE8UTwxMT5xMCAwcDAg4TDgITwgIS
D8ISD8ISBRICEcICwwbUE8oTxRPCExPmEwYCBwMCDgIOwgLDExITEhPCEg8GxgLDBtMMDAfJE8QT
whMT5hMGwwITBgMCDhLFEw8SE8ISBgIDwhIDEsMGB9MDxwwHxRPDExPlEwYHAhESAg8CwhMPwhMP
xBMPxRIQwgIDAgMCBtMDxwPEDAfDE8IT4RMHwwzCBgLCEhMCDxLIE8MSD8MSwwIQAwIDBgfSDMkD
wgPCDAfCExPbEwfGDMIDDAIHERITEhMSwxMPwxMPwxPDEgIDAgMCwwMCBgzREwfHDMYDDMITE9YT
B8UMyAMGB8ICBhLDAsYTEhMSExIPwhIHAgcCAwUQAgYRBgfSE8UTB8QMwgMMwhMT0hMHxAzLA8IM
BsISDxESExITAw4DxBMSExITwxICBwPCAsMDDMIGB9ITyRMHwwzCExPPEwfDDMkDxQwHwhMGBxIT
AhECEwMOAg7DExITDxMPwxIDAgMCBwMCDAYRBgfSE8kTwhPCDMITE8wTB8MMxwPEDMIHxxMGxBLD
Ag4DDgIGwg/IEgIDwgIDAgwCEMIGB9ITyRMHDAcMwhMTyhMHwgzGA8MMwgfMEwYHwhLCEAIOAg4C
DhDDAhIPxhIFAgXDAgUCEQYH0hPHEwfCDAcPDMITE8gTB8IMxQPDDAfQEwbDEhDEAhAOEA4QwgLG
EgcSBhIGBcMCBcIGB9ATB8UMEwfCDA8HDwwHwhMTxhMHwgzEA8MMB9MTBgfCEhADEMICDhAOEMIC
EQIDxxIGBwbCAgUCEQYHyxMHxAwHwhMHEwzCEwcPBw8MB8MTE8UTBwzEA8IMB9YTBsQSEAMCA8UC
EQIDAgPDEgcSBgfCBgUQAhDCBgfGEwfEDAfGE8INEwzCEw8HwgwHwxPCE8QTBwzDA8IMB9gTBgfE
EhACEMYCEQIDAsQSBhLDBsICEALCBgfCEwfDDAfKEwfCDRMHwhPCDAfEE8ITE8MTBwzCA8IMB9oT
DBIHwxLDDBEDxQIDAgPDEgYSBgfCBgIQAhAGDAfCEwzDE8MHyRMHwhPCBxMHxRPDExPDEwzCAwwH
3RMGxxICEQPDAgMCA8MSBhIGBwYMBhACEAIGDMMTDBPCB8YTwwfHEwfGE8MTwhPDEwwDDAfeEwYH
xxICEQPDAgMCwhIGEgYHBgwGEAIQAsIGB8MTDMYTwwfKEwzGE8MTwhPDE8IMB98TDBLCB8USAgMR
xAISB8ISBgcGDAYQBhAGEAYMB8MMB8kTwwfHEwzGE8MTwhPDEwwPwgzfEwYSB8ISB8ISAhECAwID
EgcSBwYHBgwGEAYQxgzDD8IHxRPDB8kTBwzGE8MTwhPDEwzDD8QM3BPCBhIGwxIGAhECAwIHBgcG
yAzJDxMHzRMHwwwHxxPDE8ITwxMHDMYPxwwH1BMGEgYSBhLLDM4PwwwTDMcTwgfEDAfJE8QTwhMT
xBMHwgzLD9sM0w/GDAfDEwzDEwfEDAfLE8YTwxMTxhMHxAztD8gMBgfIE8QMB84TxxPDE8ITyhMH
xwzbD8sMEAUMBcIMwgYH1RPKE8UTwxMT0RMH2wwGEAYQBhACBQwFDAUMBgwHBgfWE8sTxRPDExPu
EwYMBhAGEAIGDAYMwwYH1xPLE8YTwxMT8BPKBgfYE8wTxhPDExP1E9sTzRPHE8MTwhP1E9sTzRPH
E8MTwhMMAAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD/
/wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8A
AAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A
//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAA
AP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACA