freebsd stable - Dec 2003 - Problems reclaiming VM cache = XFree86 startup annoyance

...
> As you can probably gather, all this manual intervention is a bit of a
> hassle.  So, my question is this: is there a way explicitly to force
> the kernel to flush its VM cache (to move it to "Free").  Failing
> that, are there any sysctls to tune to help alleviate the problem?
> The only sysctls I change in /etc/sysctl.conf are as follows:
   I don't know what is causing your problem, but 'cache' pages in
FreeBSD
are free pages - they can be allocated directly in the page allocation code.
They only differ from "free" pages in that they contain cached file
data.
   So the number of pages 'cache' vs. 'free' isn't the cause
of the problem.
 
> net.inet.tcp.sendspace=65536
   You might want to use 65535 there instead to avoid the system having to
use large-window TCP extensions.
> kern.ipc.shmmax=67108864
> kern.ipc.shmall=32768
> 
> The latter two were in response to an installation message of a port I
> installed quite some time ago (xine, perhaps?).
   Uh, yeah. You might want to take that out and see if it affects the
problem. shmall of 32768 could potentially result in up to 134MB of virtual
memory being consumed, and in most FreeBSD kernel configurations, this would
cause it to run out.

-DG

David G. Lawrence
President
Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500
TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175
The FreeBSD Project - http://www.freebsd.org
Pave the road of life with opportunities.

:...
:> (Paul Mather)
:> As you can probably gather, all this manual intervention is a bit of a
:> hassle.  So, my question is this: is there a way explicitly to force
:> the kernel to flush its VM cache (to move it to "Free"). 
Failing
:> that, are there any sysctls to tune to help alleviate the problem?
:> The only sysctls I change in /etc/sysctl.conf are as follows:
:
:(DG)
:   I don't know what is causing your problem, but 'cache' pages in
FreeBSD
:are free pages - they can be allocated directly in the page allocation code.
:They only differ from "free" pages in that they contain cached file
data.
:   So the number of pages 'cache' vs. 'free' isn't the
cause of the problem.
:...

    Other disk activity can interfere with swap performance.  If these other
    background jobs Paul is running are doing a lot of disk I/O or using a 
    lot of memory, regardless of their nice value, they could be causing a
    significant reduction in swap I/O performance and/or be causing page
    thrashing.  The 'swwrt' state is waiting for an I/O to complete,
*NOT*
    waiting for a memory allocation, which implies an I/O performance issue.

    It is likely that nothing is frozen per-say, just that I/O performance
    is insufficient to handle the paging load caused by starting X *AND*
    the I/O/memory load of whatever other background processes are running.
    When you ^Z the background process, the I/O it is performing stops which
    allows the paging I/O being caused by the X startup to get 100% of 
    available disk bandwidth.  Also remember that in an I/O bound situation,
    the 'nice' value of a process becomes irrelevant because there is
plenty
    of cpu available due to all the processes being predominantly in a
    blocking state on I/O.

    The easiest solution is to add more memory to the machine.  It is fairly
    obvious to me that the machine does not have enough for the workload
    being thrown at it.  Alternatively you may wish to examine the memory and
    I/O footprint of these nice +20 processes and take steps to significantly
    reduce both.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

I know this card is supported in normal ide mode
but is it supported as a raid card.under 5.1-5.2

Kingsley

On Sat, 20 Dec 2003, Paul Mather wrote:
> Not being a Python programmer, I don't know exactly how BitTorrent is
> accessing the files (e.g., using mmap), though I do know some kind of
> random access is involved as the filesets are chunked and different
> chunks are served to different peers.  I suspect random access to such
> large files is not kind to the cache, though. :-)
BT doesn't use mmap(), just seek()/read()/write().

--
Andrew I MacIntyre                     "These thoughts are mine
alone..."
E-mail: andymac@bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac@pcug.org.au             (alt) |        Belconnen  ACT  2616
Web:    http://www.andymac.org/               |        Australia

paul@gromit.dlib.vt.edu said:
> Not being a Python programmer, I don't know exactly how BitTorrent is
> accessing the files (e.g., using mmap),
I'm no Matt Dillon when it comes to kernel guts, but I suspect if the system
is
saturating the disk, mmap() vs open()/read() is not going to make any
difference.  They all wind up at the same underlying VM machinery and banging 
on the same overloaded disk.

:I'm not sure what is overloading the disk other than the large amounts
:of paging that are initiated the moment I invoke "startx".  The last
:time I did this, I looked at the disk activity beforehand via "systat
:-vm 1".  The disks were basically idle (all < 0.05 MB/s).  As soon as
:I executed "startx" the swap volume became very active (90--96% busy;
:3--7 MB/sec) and the "SWAP PAGER" out column steadily showed paging
:activity (nothing on the "in" column).  (The 4 KB/t was a tell-tale
:sign the system was doing nothing but paging.)
:
:I guess my question is this: why so much paging?  If, as someone else
:has mentioned, "Cache" and "Free" pages are both
"free" (i.e.,
:allocable memory), with the subtle distinction being that "Cache"
:pages used to hold disk blocks now discarded, then why not allocate
:what is needed from them?  As I stated in my original thread, all the
:"Inactive" memory seems to get dumped over to "Cache" when
I run
:"startx", and there's usually almost about 400 MB of it when this
:happens.
:...
:Cheers,
:
:Paul.

   If it could, it would... my guess is that your box is using a shared
   memory video buffer and X is allocating a large swath of 
   contiguous physical memory to accomodate it, which would force it to
   pageout any preexisting dirty data using that memory.  That's all I can
   think of.


					-Matt
					Matthew Dillon 
					<dillon@backplane.com>