SUMMARY: Atrocious 3.2 performance

From: Brad Daniels <daniels_at_jabberwock.biles.com>
Date: Fri, 04 Aug 95 09:19:08 -0500

Thanks to everyone for all the help! My original problem was that the
system would become totally unusable for long periods when I had moderately
high memory usage, then added another very large process.

The consensus of the replies was that the system was swapping out processes
when all it really needed to do was page out some unused memory. It would
end up swapping in and out 60-80 MB per time slice, resulting in the virtual
standstill I observed. The solution is to tune some of the VM system's
parameters. I had already started on that track, but I didn't go far
enough, and there were some parameters I didn't know about.

I also got a note from Simon Monday <MondayS_at_logica.com> mentioning a
problem with ld which can trigger the problem. Apparently, when searching a
(non-shared) library, ld loads the entire thing into memory first. If you
have very large libraries (theirs were 600MB), you can genuinely use up all
of your available memory and swap pretty quickly. There is a patch either
available now or soon to be available, but I didn't get a patch numer.

Here's what I changed and why:

I placed the following lines in /etc/sysconfigtab:

--------------
vm:
        ubc_maxpercent=40
        ubc_borrowpercent=20
        vm_page_free_min=50
        vm_page_free_target=400
--------------

I also then invoked "dbx -k /vmunix /dev/mem", and did an "assign" for each
of the above values in order to modify the parameters for the running
kernel.

The parameters are described in the "System Tuning and Performance
Management" guide on the documentation CD (in the "System and Network
Administration bookshelf.) Here's a rough description, though:

The first parameter says that under no circumstances should the "Unified
Buffer Cache" (which handles all I/O buffering) take up more than 40% of
physical memory. The ubc_borrowpercent parameter says that the UBC is
"borrowing" any memory above 20% of physical memory, and that the memory
should be released when the system starts paging (more or less - check the
tuning guide). These two parameter changes tend to keep more memory
available for paging, thus preventing the systems from thinking it needs
to pick processes to swap entirely out of memory as often as it otherwise
might. Note that the borrowpercent change alone may often be sufficient,
but if your problems are severe, it's probably a good idea to lower
maxpercent from its default, which is 100% of physical memory.

The vm_page_free_min parameter tells the system that it should start trying
to free up more pages when the total number of free pages in physical memory
gets below 50 (about 400K). I've actually set this parameter a little
higher than it needs to be unless you run a lot of processes which typically
allocate memory in very large chunks. I may tune it down a bit, but I
wanted to make sure that the system would have time to free up pages before
any process grabbed the last bit of memory. The vm_page_free_target
parameter says that the system should try to keep 400 pages available for
processes to grow into. Once the system hits vm_page_free_min pages of
available memory, it will start releasing pages until it hits
vm_page_free_target free pages.

This combination of changes has hugely improved the system's performance. I
no longer get lengthy freezes, and even when doing large compiles, I only
see minor slowdowns. I strongly recommend trying similar changes (and
reading the "System Tuning and Performance Management" guide) if you are
seeing memory-related problems.

Thanks to:

 John P. Speno <speno_at_swarthmore.edu>
 John Richards <john_at_zyqad.co.uk>
 Allan Small (Cafeine propelled) <small_at_gidday.ENET.dec.com>
 Andrew Gallatin <gallatin_at_isds.Duke.EDU>
 Hellebo Knut <bgk1142_at_bggfu2.nho.hydro.com>
 Khalid Paden <khalid_at_FNAL.FNAL.GOV>
 Nick Hill - RAL CISD VMS Systems <NMH1_at_axprl1.rl.ac.uk>
 Simon Monday <MondayS_at_logica.com>
 Todd Acheson <acheson_at_oak.cats.ohiou.edu>
 alan_at_nabeth.cxo.dec.com
 neindorf_at_pppl.gov (Richard Neindorff)

For their help, suggestions, and useful information.

- Brad
-------------------------------------------------------------------
+ Brad Daniels | "Oh, I know you did... +
+ Biles and Associates | but let's pretend you didn't." +
+ These are my views, not B&A's | - Darkman +
-------------------------------------------------------------------
Received on Fri Aug 04 1995 - 16:49:41 NZST

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