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 swapIt 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?
--
Greg A. Woods; Planix, Inc.
<woods%planix.ca@localhost>