Xref: utzoo comp.unix.wizards:22782 comp.unix.i386:6573 comp.sys.att:9927 Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!dsl.pitt.edu!pitt!amanue!oglvee!jr From: jr@oglvee.UUCP (Jim Rosenberg) Newsgroups: comp.unix.wizards,comp.unix.i386,comp.sys.att Subject: Is VHANDFRAC --> VHANDL dynamic? Message-ID: <562@oglvee.UUCP> Date: 6 Jul 90 20:35:01 GMT Organization: Oglevee Computer Systems, Connellsville, Pa Lines: 25 I have seen paging behavior under AT&T UNIX V.3.2 on a 6386 where the number of free memory pages as reported by sar seems to sit forever drastically below what I had *thought* was the low-water mark. This always seems to happen after paging orgies, which continue long after processes that caused all the paging have terminated. According to the AT&T documentation: "VHANDFRAC determines the initial value for the system variable VHANDL. VHANDL is set to the maximum user-available memory divided by VHNDFRAC or the value of GPGSHI, whichever is larger." (Operations/System Administration Guide, under Paging Parameters.) This sort of implies but doesn't really say that VHANDL is computed at boot time and thereafter left alone. Is this really how it happens? Can VHANDL get recalculated? How do I find out what the "real" low-water mark is? How else can I explain a quiet system just sitting there with far fewer free pages than the low-water mark? The V.3 paging parameters mystify me. I get more JUNK in my mail about training seminars, but I would *beg* my management to go to a good one-day tutorial on V.3 paging parameters. Help! -- Jim Rosenberg #include --cgh!amanue!oglvee!jr Oglevee Computer Systems / / 151 Oglevee Lane, Connellsville, PA 15425 pitt! ditka! INTERNET: cgh!amanue!oglvee!jr@dsi.com / /