Re: Problems reclaiming VM cache = XFree86 startup annoyance

From: Paul Mather (paul_at_gromit.dlib.vt.edu)
Date: 12/21/03 

Date: Sat, 20 Dec 2003 22:32:22 -0500
To: Matthew Dillon <dillon@apollo.backplane.com>

On Sat, Dec 20, 2003 at 06:05:20PM -0800, Matthew Dillon wrote:
=> :...
=> :> (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.

The I/O-hogging background process is probably the btlaunchmany.py I
run to serve several large filesets via BitTorrent. The system
currently has 512 MB RAM, but the filesets are several hundreds of
megabytes each (comprising SHN and FLAC files) and several are served
at the same time, so I'm not sure adding more memory would ultimately
solve the problem. (I'd conservatively estimate the total size of all
filesets combined easily to be in excess of 4 GB.) I cap my total
outgoing BitTorrent bandwidth to 500 KB/sec via a DUMMYNET pipe, so
that would also serve to put a limit on the total I/O rate of the
BitTorrent process.

The odd thing is that it is usually sufficient to "kill -STOP" the
Folding@Home client I'm also running in the background, which is most
definitely CPU bound (and which is the one that runs at a nice of 20)
and does little in the way of I/O. The BitTorrent background job runs
at normal priority. But, I suspect it is the BitTorrent client that
is the real culprit, as it is the only process doing heavy I/O.

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. :-)

I guess I should find out more about how BitTorrent is operating, to
see if there is some way of ameliorating its effects on the system.
(Or else go back to running xdm, so the X server is always running...;)

Thanks for the insight.

Cheers,

Paul.

e-mail: paul@gromit.dlib.vt.edu

"Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid."
        --- Frank Vincent Zappa
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

Relevant Pages

  • [RFC] page replacement requirements
    ... Submitting too much I/O at once can kill latency and even lead to deadlocks when bounce buffers are involved. ... Must be able to deal with multiple memory zones efficiently. ... When on completion of the write to their backing-store the reference bit is still unset a callback is invoked to place them so that they are immediate candidates for reclaim again. ... For traditional page replacement algorithms this is not a big issue since we just implement per zone page replacement; ...
    (Linux-Kernel)
  • RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)
    ... answered I disliked the dependency on defrag for reliable I/O and I ... all the memory allocations are ... the moment you need to relay on order> 0 allocations ... printf("%d usecn", usec); ...
    (Linux-Kernel)
  • Re: Forth as an operating system
    ... service to I/O events or the lowest OS overhead in general. ... We say that an interrupt cannot be the fastest because it ... We say that multiple memory operations cannot ... ISR are the fastest solution possible. ...
    (comp.lang.forth)
  • Re: Mainframe not a good architecture for interactive was Re: What is the future of COBOL? Answer:
    ... > Mainframes are MEMORY centric using ECC type memory. ... Supposing I said there are Intel I/O chips that can maintain around a GIG ... applications require fast I/O throughput for optimal performance. ...
    (comp.lang.cobol)
  • Re: memory interpretation help
    ... the last column in vmstat output: ... wa - CPU idle time during which the system had outstanding disk/NFS I/O ... > virtual memory is in the system. ...
    (comp.unix.aix)