Re: HELP! OnLine keeps grabbing virtual memory
Posted in 1997
Topics: Performance & Tuning, Storage & Space Management, SQL Development & Query Writing, Logging & Checkpoints
If the online.log shows regularly grabbing additional shared memory segments, don't look at query params, the problem lies before that. Online's memory architecture uses the RESIDENT portion (made primarily of BUFFERS) for OLTP processing, and VIRTUAL portion (controlled mainly by SHMVIRTSIZE) for DSS. You should make that portion that you need the larger. In other words, increase BUFFERS. By no means should you let online grab these additional memory segments throughout the day. Keep working with it until you rarely have processes grabbing additional memory segs. If all else fails, ensure it grabs a large amount, so it asks less often. To start with: Set BUFFERS to a LARGE VALUE (30000...+) Set LRU_MAX & MIN_DIRTY to SINGLE DIGIT VALUES (max=9 min=8) Set CHECKPOINT INTERVAL to a LOW value (~300 secs) Watch CHECKPOINT DURATION -- on oltp should be less than 2 secs. If you're not comfortable with these numbers, make small adjustments, and keep watching the system. Always keep track of original and new values in case you find you overstress a particular value. Remember, performance tuning isn't hysterical, it's historical. Good Luck ! -- "I think I have mood poisoning, it must be something I hate" --Wild Palms "Billy Wheeler" <billy@west.co.za> wrote in article <5qpket$9o2@cssun.mathcs.emory.edu>... > G'day all! > > I'm at my wit's end here (not far, I know, but still...) > > I'm working on an NCR 4100 with MP-RAS 3.0, OnLine 7.20 UC2 and > PowerBuilder 5.0 (Arabic) as the client. The damndest thing: the > system is a very straightforward OLTP system with indexes all over > the place (some of them are even correct! :-) and the system keeps > grabbing additional SHM segments. It appears that virtual segments > are not being released either (certainly not to the extent I'd > expect). > > The query which seems to be causing the bulk of the problem is a > simple 2-table join on a message/message-type combination which is > being run frequently as new users learn the new system. The set > explain shows that indexes are being used. > > Following David Williams's repeated advice, I've set OPTCOMPIND=0 and > done everything feasible to minimise PDQ, all to no avail. I now have > several questions: > 1. The PowerBuilder connection is 16-bit I-Net5 (because the Arabic PB > is only 16-bit) -- could this problem be related to PB or to the > I-Net? > 2. Is this a known bug in 7.20UC2? > 3. If so, is it fixed in a later version (and which one)? > 4. Does anyone have any other ideas? > > All comments gratefully received. > > -- > Ciao, > Billy > > Nose to the ground and ear to the grindstone in: Dubai > > "A kid asked me what happens after we die. I told him > we get buried under a bunch of dirt and worms eat our > bodies. I guess I should have told him the truth--that > most of us go to Hell and burn eternally--but I didn't > want to upset him." >