Re: Database server slowdown with "buff" ~= physical memory

From: Andrea Arcangeli (andrea@suse.de)
Date: Mon Jun 26 2000 - 18:36:22 EST


On Mon, 26 Jun 2000, Stephen J. Gowdy wrote:

>2GB. This was originally due to the Solaris 2.6 limitations but also now
>Linux.

2.4.x and 2.2.16aa2 can go over 2giga of filesize.

>database server process (a page server) the buffer grows to use most of
>the physical memory in the machine. The machine has 512MB and the buff
>grows to 480MB. Once this happens the machine begins to swap and the
>client's CPU utilisation drops dramatically.

This shouldn't happen in 2.2.17pre6aa2 because of the no-swapout patch
included in it:

        ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.17pre6aa2/60_no-swapout-C

> We've found the /proc/sys/vm/buffermem file which sounds like it
>should do what we want (ie limit the amount of memory the buffer will

It will help some bit but not completly. It doesn't limit the buffer
cache. Reducing the number from 40 to say 20, will only reduces the amount
of dirty data in the cache to a lower percentage. The fact is that you can
get the swapin/swapout also doing only reads.

>if I could find anywhere that used them and failed. There is one macro
>which uses the min_percent portion but that macro doesn't seem to be used.

The min_percent stuff for page cache and buffer cache (first value in the
pagecache and buffermem sysctls) does the opposite of what you want ;-),
it avoids the cache to be shrunk completly. You instead don't want the
cache to grow too much.

> The kernel on the server machine is 2.2.13 at the moment. Does
>anyone know a way to limit this buffer size? Or is it a function of file

We can add an hack for that. However I'd suggest first to give a try to
no-swapout and to make it more aggressive if necessary (to make it more
aggressive you set the variable priority in
linux/mm/vmscan.c:do_try_to_free_pages from 6 to 3 for example, note that
with no-swapout applied a value of 6 just means much more than in 2.2.x
stock).

>sizes that are opened (which will grow to n*2GB)? Could this be an

It's not a function of the file.

>application problem or only kernel? Any other advice?

only kernel issue.

Andrea

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:10 EST