On 4-May-08, at 9:45 AM, Jonathan Schleifer wrote:
anna2edw%yahoo.com@localhost 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 vm.anonmax?
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?