[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Using swap though there's plenty of mem free
On 4-May-08, at 9:45 AM, Jonathan Schleifer wrote:
Programs that are asleep is the cause just thank your computer. At
least it dosn't slow your computer when sleeping programs are in swap
It does, as already stated in the thread before. Important stuff is
swapped out, mainly one of the python threads and then it can happen
that the user has to wait a loooong time if that thread is used again
(again: it's random which thread is used)
First off, you need to be much more careful about your use of terms as
you're tending to mislead people. In NetBSD "swapped" refers to the
situation where an entire process is put out on the swap device
wholesale. NetBSD actually uses what's called a "demand paged virtual
memory system" (it will show up with a "W" in the state field given by
ps(1)). Otherwise only individual memory pages are considered for
copying out to the paging device(s).
Second, you have to be very careful about where you put the blame for
your system's performance. It is just as likely that you have chosen
the size of RAM and configuration of your secondary storage devices
(including especially the swap device(s)) poorly. Blaming the VM
algorithms naively isn't going to get you anywhere. You need to
provide some very carefully considered and accurate measurements if
you would hope to show that some other algorithm or implementation is
providing better throughput or better responsiveness, etc.
For example if your system responds poorly while and after you've made
it do a large amount of file I/O the problem may be just as much
related to disk I/O contention as it is to VM tuning. Move your swap
partition to another disk or set of disks and perhaps even a separate
controller. If you've got one or more processes trying to do disk I/
O, and another process trying to access a page that's still out on
swap, and both swap and the disk I/O are going through the same path,
then you've got contention and something will suffer.
Do you think you understand the meaning and implications of all the
sysctl vm.* settings? Have you tried increasing vm.anonmin and
Have you kept a screen or window running with "systat bufcache" while
at the same time creating conditions which cause your system to
exhibit poor responsiveness and have you paid attention to the "systat
bufcache" numbers and how they change during such situations? Have
you then tried tuning the sysctl vm.* settings one at a time to see if
any of the "systat bufcache" results change, and if so how, and if so
whether system responsiveness changes at the same time?
Have you tried adding more RAM to your system?
Greg A. Woods; Planix, Inc.
Main Index |
Thread Index |