From: young_r@eisner.decus.org Sent: Thursday, June 08, 2000 12:55 PM To: Info-VAX@Mvb.Saic.Com Subject: Re: system slow In article <6L$nJg9RlTr8@eisner.decus.org>, young_r@eisner.decus.org (Rob Young) writes: > In article , "Jim Kozlowski" writes: >> We have an Alpha 200 running openVMS 6.1 >> System running fine until 2 months ago...at that time we replaced a 1gb >> drive with a 2gb drive (i do not know drive model off hand) new drive was >> not system disk. >> We added the disk space to accomodate a software upgrade which has us >> running two different version of synergy concurrently. >> It seems, that since that time, the system runs much slower. At times it >> will suspend all activity for 20-30 seconds at a time. Processes will be >> suspended. >> I need some troubleshooting help. What can I monitor to determine if the >> hesitation is disk or software or something else related. >> Thank you >> Jim K >> > This doesn't add much to the other thread and this was version 1. Version 2 is currently lost to Deja.com. It was easy to find as I was mistakingly referring to the "ticker" as the "tickler". Also, this version didn't have in the "kinder" ticker that kicks in and quits trimming when free gets above 8 x FREEGOAL or so. Let us know what you discover about your performance problem. Rob --- Date: Fri, 16 Jan 1998 17:26:15 -0500 (EST) I got an idea to improve memory management. Here is the scenario... currently I have 1 Gig and I get many processes using hefty WSEXTENT as applications are large. Mem gets down to 2 x FREEGOAL, tickler comes along and tickles and now I have MWAIT as mucho pages are being written to backing store. Of course very shortly folks fault back in, free memory slinks back down to 2 x FREEGOAL, etc. This is annoying because: 1) CPU is being chewed by SWAPPER 2) Cycle is repeating 3) Long Dormant folks in applications are still holding onto (in several cases) many pages. Looking at 3 makes me want to swap them out but I can't force that. Raising LONGWAIT to 300 is helping a bit overall but is still getting me. [This last statement is misleading, if a process hasn't performened any activity in LONGWAIT seconds (default 30) then it is considered idle. By raising to 300 seconds, this helps to sort out the truly idle from the people that stopped to take a sip of their coffee. Also, this isn't examined until the "troller" comes into play at 1 x FREEGOAL pages free so is not an accurate statement.] So, why not solve 3 by adding a new bit to MMG_CTLFLAGS? Pay attention to the new bit 2 below . . . Parameters MMG_CTLFLAGS MMG_CTLFLAGS is a bit mask used to enable and disable proactive memory reclamation mechanisms. The following values are defined: Bit Description 0 Reclamation enabled by trimming from periodically executing, but otherwise idle processes. This occurs when the size of the free list drops below two times FREEGOAL. 1 Reclamation enabled by outswapping processes that have been idle for longer than LONGWAIT seconds. This occurs when the size of the free list drops below FREEGOAL. 2 Reclamation enabled by outswapping processes that have been idle for longer than LONGMIN minutes. This occurs when the size of the free list drops below three times FREEGOAL. 3-7 Reserved for future use. And the associated LONGMIN and MMG_CTLFLAGS at my site would be set to: $ mcr sysgen show longmin Parameter Name Current Default Min. Max. Unit Dynamic -------------- ------- ------- ------- ------- ---- ------- LONGMIN 1200 65535 5 65535 Mins D $ mcr sysgen show mmg_ctlflags Parameter Name Current Default Min. Max. Unit Dynamic -------------- ------- ------- ------- ------- ---- ------- MMG_CTLFLAGS 7 7 0 255 Bit-mask D In other words, anyone idle for 20 hours is probably out for the day... swap their backside out and give me that 10000+ pages so I don't have to tickle. If things really get tight, tweek LONGWAIT to 60 minutes, resetting to 20 hours at 6 p.m. Comments? Rob