SUMMARY: syschecks tuning suggestion gotcha's?

From: Tru64 User <tru64user_at_yahoo.com>
Date: Tue, 15 May 2001 11:15:50 -0700 (PDT)

Many thanks to Jay Vlack and Tony McElhill, who came
to my rescue. Below are the responses, very
definitive, just what I wanted to know.

--- "Vlack, Jay" <Jay.Vlack_at_COMPAQ.com> wrote:
> Richard,
>
> The reason that vmstat shows the average free pages
> at around 130 is because
> you've got vm-page-free-target set to 128. If you
> change the
> vm-page-free-target kernel parameter to 1024 as
> sys_check recommends, you
> will find that vmstat now shows the average free
> pages at around 1024. This
> is because the virtual memory subsystem always
> attempts to keep the number
> of free pages at the value you've set with
> vm-page-free-target. The reason
> that sys_check is recommending this change is
> because your 4100 has 2GB of
> physical memory, and it's trying to take advantage
> of this large amount of
> memory to improve performance.
>
> With vm-page-free-target set to 128 the virtual
> memory subsystem will try to
> reclaim up to 128 pages (~1MB) of memory for the
> free list before shifting
> focus from memory management. If you set
> vm-page-free-target to 1024 it will
> try to reclaim 1024 pages (~8MB). By reclaiming more
> pages each time you get
> into a low free memory situation the system will
> page less frequently. Since
> your system has an adequately large amount of
> physical memory you can afford
> to have more pages on the free list.
>
> Below I've included a brief description of how the
> virtual memory subsystem
> works under Tru64 UNIX v4.0x, if you're interested.
> I hope this helps.
>
> --> Jay
>
>
========================================================
>
> The virtual memory subsystem maintains five lists to
> perform its tasks. Each
> existing page can be found on one of the following
> lists:
>
> Free list - Pages that are clean and available for
> use
>
> Active list - Pages that are currently in use but
> can be reclaimed for
> paging
>
> Inactive list - Virtual memory pages that are
> allocated but are most likely
> to be reclaimed when memory is needed
>
> UBC least-recently-used page list (LRU list) - UBC
> pages that are allocated
> but most likely to be reclaimed and used for paging
>
> Wired list - Pages that are currently in use and
> cannot be reclaimed (not a
> real list)
>
>
> | |
> | |
> |-----------| <-- vm-page-free-target = 128
> pages Paging ends
> | |
> | |
> free |-----------| <-- vm-page-free-optimal = 72
> pages Swapping
> begins
> list | |
> | |
> | |
> |-----------| <-- vm-page-free-min = 20
> pages Paging begins
> | |
> |-----------| <-- vm-page-free-reserve = 10
> pages
> | |
>
>
> The virtual memory subsystem tries to maintain a
> reasonable number of pages
> on the free page list so that pages are available
> for use by processes. All
> pages are shared by virtual memory and the UBC. Four
> configuration
> attributes in the sysconfigtab file define the size
> of the free page list
> and thus control when paging and swapping occur:
>
> vm-page-free-min - Minimum number of pages on the
> free page list before
> paging begins
>
> vm-page-free-target - Number of pages on the free
> page list before paging
> stops
>
> vm-page-free-optimal - Number of pages on the free
> page list that triggers
> task swapping (if below this number for five
> seconds)
>
> vm-page-free-reserved - Absolute minimum number of
> pages on the free page
> list before only privileged tasks are able to get
>
>
>
> If the number of pages on the free page list falls
> below the value
> associated with the vm-page-free-min attribute, the
> virtual memory subsystem
> first trims down the size of the UBC until the
> percentage associated with
> the ubc-borrowpercent attribute is reached. If this
> does not satisfy the
> memory deficit, it then activates two page-stealer
> routines that reclaim the
> least recently used pages from the virtual memory
> system's inactive list and
> the UBC's LRU list. This process continues until the
> number of pages on the
> free page list reaches the value associated with the
> vm-page-free-target
> attribute. If necessary, the contents of the
> reclaimed pages are moved to
> swap space.
>
> When the maximum number of pages is reached, the
> page-stealer daemon becomes
> dormant again. This procedure enables the virtual
> memory subsystem to keep
> the most recently used pages in memory and move the
> least recently used
> pages to swap space, where they can be easily
> accessed if necessary.
>
> The value associated with the vm-page-free-reserved
> attribute specifies the
> absolute minimum number of pages on the free page
> list. If the free page
> list falls below the value associated with the
> vm-page-free-reserved
> attribute, only privileged tasks can get memory,
> thus preventing deadlocks.
>
> The page-stealer daemon maintains a ratio of one
> active page to two inactive
> pages. If the inactive list becomes too small, the
> page-stealer daemon
> deactivates the oldest and least recently used pages
> and moves them to the
> inactive list.
>
> When the virtual memory subsystem maps an
> application into memory, it tries
> to anticipate which pages the task will need next.
> Using an algorithm that
> checks which pages were most recently used and the
> size of the free page
> list (as well as other factors), it passes some
> number of pages to the task
> in addition to the requested page. It tries to
> anticipate the pages that a
> ask will need, thus accelerating the execution of
> the application by
> lowering the chances that a page fault will occur.
>
> The virtual memory subsystem also attempts to
> optimize the utilization of
> the secondary cache. To do this, it uses a
> nontunable technique called page
> coloring. Essentially, it attempts to map the most
> recently referenced pages
> of a running task's virtual address space into the
> secondary cache and to
> execute the entire task, text, and data out of that
> cache. If the task is
> loaded in the secondary cache, the task does not
> have to fetch from physical
> memory and the task's execution time is decreased.
> The virtual memory
> subsystem maintains system-wide counters for all of
> the physical pages that
> it manages. The following counters, which can be
> viewed with the vmstat
> command, track the overall use of physical memory:
>
> act - The total number of pages on the active list,
> the inactive list, and
> the UBC LRU list
>
>
> free - The physical pages not currently in use
>
> wired - The physical pages currently in use and not
> pageable



And Tony McElhill said:

Hi Richard,

I guess you didn't get much of a response first time?

Personally, I take sys_check's recommendations with a
pinch of salt. To a certain extent, you can
implement some changes if they have been recommended
(e.g. for Oracle, Sybase etc.), or if you feel
performance is suffering, otherwise it may be best not
to fix what ain't broke.

Also, if you change one parameter value in a subsystem
it tends to have a knock-on affect. If you
have a "test" box, you could try making some changes,
e.g. vm-page-free-target=1024 and so on, and then run
sys_check again to see what it says. It may recommend
doing some more. <<Message truncated>>


ORIGINAL MESSAGE:
Subject: UPDATE: syschecks tuning suggestion gotcha's?


I guess I should re-word the question:
Why should sys_check suggest for example, change of

vm-page-free-target=1024 [Currently 128]
while 128 was the default?

Reason being, tuning guide (du sys admin guide) says
that: "If total # of available pages (vmstat free
field) is less than the value of the sysconfig
parameter vm_page_free_target (128 by default), the
system may be paging. Investigate paging/swapping
subsystems.Now, my free field (vmstat) averages 130.
Increasing the vm_page_free_target to 1024 as
sys_check suggests will then make free field always
less than the sysconfig parameters. What problems
might i face at that point? How should i best proceed
from
here....??
My
$ vmstat -i
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
  6 487 27 219K 170 36K 4M 503K 2M 152K 697K
19K 488400K 1K 22 24 54


Thanks in advance once again
Richard
Greenbelt, MD


=====


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
Received on Tue May 15 2001 - 18:16:51 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:42 NZDT