I received many replies to my question. To wrap it up, I would say that the 98-99% usage of memory
is actually just fine. It seems to be the behavior of a DU system using it's VM. The majority of the
responses pointed me to 'sys_check', which I have downloaded and run. Be careful, if you run it
without arguments - it's a 'tree killer' to print out ! There was also a suggestion to download and
run 'vmubc' as well, which I still plan to do. I have actually reduced my max ubc percentage down
to 30%, and changed other settings based on the sys_check report, but honestly, since I wasn't
doing benchmarking, it's hard to tell any performance change.
It's curious that the sys_check told me that with my 4.0B version, I should have 'new-wire-method'
must be '0', when I never changed it form the original install over a year ago. Why would it default
to '1' when it MUST be '0" ?
Here's the URL for 'sys_check' : ftp.digital.com:/pub/DEC/IAS/sys_check
Anyway, thanks to the following:
Rich Frank
Larry Magnello
Russ Fish
Alan
Mark Ray
Joe Fetcher
Serguei Patchkovski
John Speno
Paul O'Sullivan
Trevor Stott
Paul Watson
Here's some of the responses I received, to give some variety of responses...
----------------------------
Using vmstat or sar if you have it and check the UBC usage. This may not be fully used, so reduce the cache size. This will reduce UBC but increase free memory!
regards,
paul o'sullivan
---------------------------
You need not be concerned with only having 1MB free as long as the system is not doing any page outs. DU will use all its memory to house all pages active and inactive. If you take a look at vmstat it'll look like this:
vmstat 1
Virtual Memory Statistics: (pagesize = 8192)
procs memory pages intr cpu
r w u act free wire fault cow zero react pin pout in sy cs us sy id
3605 18 107K 232 19K 103M 6M 13M 2M 13M 157K 100 691 690 15 2 83
3607 17 107K 198 19K 3088 522 1574 111 270 0 85 1K 921 14 17 69
4606 17 107K 169 19K 618 0 606 0 0 0 71 695 822 10 9 81
3607 17 107K 176 19K 651 0 635 32 0 0 121 1K 970 25 10 64
3607 17 107K 141 19K 730 0 655 89 2 0 77 750 818 17 9 74
Going from act across to pout:
act = actual number of pages available to the system
free = number of free pages
wire = number of pages used by the O.S. (not reclaimable)
fault = number of address translations made by V.M.
cow = number of pages copied from parent (fork)
zero = number of NEW pages (not on active or inactive)
react = number of pages requested that reside on inactive list
pin = number of pages that are on the swap disc
pout = number of pages sent to swap disc
So on the system above I would say the memory is fine. Due to the nature of the machine I would say that having more memory would decrease the number of zeros and increase the number of reacts but spending money on that isn't a luxury we can afford at this point. :} I would not ever expect to see more than a few hundred pages free after the system is fully booted.
Hope this helps.
------------------------------------------------------------------------------
Trevor Stott
It isn't uncommon to have little free memory when the buffer cache is left to itself. All of available memory is readily usable by the cache. Unless you have a write heavy load, most of it is easy to get back if other things need memory. I'm not sure why you didn't get more free when you lowered ubcmaxpercent, but it could be that Oracle adapts to how much it thinks is free.
You can use ps(1) to see where the real memory usage is. And it may be useful to get a copy of vmubc. It should be the same neighborhood as Monitor on gatekeeper.dec.com.
If the system isn't paging, is performing well enough and you're not having a lot of memory sitting idle I'd be inclined to say you don't have much to worry about. When you start getting paging I/O is when you have something to worry about.
If you do not see page-in/page-out activity and do not observe any performance problems, you do not have to change anything. Having about 1Mbyte of free memory is about right and indicates an optimally functioning VM subsystem (it aims for having vm-page-free-target free pages, which is 128 by default). Depending on the applications memory requirements, the unified buffer cache (UBC) will expand or shrink so that the number of free pages is close to optimal. As long as UBC is not squeezed down to ubc-min-percent (at which point you will start to experience paging) you are functioning fine.
Or, at least, this is how I understand it ;-)
Regards,
/Serge.P
Here's the original message I sent out...
-----Original Message-----
From: Wayne Sweatt [SMTP:sweatt_at_dps.state.nm.us]
Sent: Tuesday, March 16, 1999 9:38 AM
To: 'DU Mail List'
Subject: Any Memory Tuning Experts.
I've got a couple of Alpha 2100 Servers running DU 4.0B. They are running all Advfs filesystems. They both run an Oracle instance with around 100 users connected via Sql*Net at a time. There are no other production applications running besides Oracle Server. The "problem" is, that although they are running OK - No user complaints, Our newly installed Unicenter CA-TNG Enterprise manager sees the DU OS agent reporting right at 100% Memory usage on both AlphaServers. A vmstat -P and monitor both report an average of 1M free memory. Watching monitor run for a couple of minutes, I don't see any page outs going on. So, in a nutshell, The systems seem to be running satisfactorily, but it looks like memory free is critical. Are there any common, frequently overlooked default vm kernel settings that I should change? Are there any kernel settings I should look at since I'm running Oracle(7.3.3)/Advfs ? I did catch an earlier Summary suggesting lowering the UBC maxpercent. I did try it on one of the two servers - from 100% down to 30%... no change.
Before I make my best guess and modify sysconfigtab and reboot over and over, I thought I would solicit some more experienced suggestions. I've been the victim of more programming that Sys. Admin the past year or so, and may have neglected my OS's performance in light of increased usage.
Thanks,
***********************
Wayne Sweatt
Principal Software Analyst
Litton / PRC
505.827.9288
***********************
Received on Tue Mar 23 1999 - 18:04:40 NZST