G'Day, On Tue, Jul 01, 2008 at 01:50:45AM -0700, Sebastian Fontaine wrote: > Hi, > > on my 1280 with sol10 u4 last patched on february I had 60 swapping Prozesses > found with vmstat. > By restarting some prozesses like apache, rpcbind etc I could eliminate 50%. > Now I have still some left: > > >vmstat 1 5 > kthr memory page disk faults cpu > r b w swap free re mf pi po fr de sr m1 m1 m1 m2 in sy cs us sy id > 0 0 62 20805336 5742656 1008 2382 4419 79 88 0 65 6 5 5 0 2343 12800 3642 7 > 6 87 > 0 0 [b]26[/b] 22054400 5503360 296 703 8 8 8 0 0 0 0 0 0 1008 6310 2273 > 2 7 91 > 0 0 [b]26[/b] 22053128 5500496 0 2 0 0 0 0 0 0 0 0 0 654 2673 1276 > 2 1 97 > 0 0 [b]26[/b] 22055576 5503752 52 86 412 0 0 0 0 0 0 0 0 1177 6516 2981 > 1 2 97 > 0 0 [b]26[/b] 22056928 5503320 139 127 651 0 0 0 0 0 0 0 0 2763 18889 7468 > 3 3 94 > > > In my opinion it is very strange that those 26 Prozesses are there now for > weeks. > And there is much memory free:
It looks strange, but for the operating system it isn't - those threads (or LWPs, as the man page reads) are waiting for an event or signal, at which point they will swap back in. They shouldn't be affecting anything while residing on swap, since they aren't running. Of course, don't ignore kthr/w altogether - if the system runs low on RAM again then some could be busy processes that are actively swapping (see vmstat -S), and us such seriously affecting performance. Once you have identified the PIDs (using mdb, as others have posted), you could run pstack on them to see why they are sleeping - which as a side effect may swap them back into RAM; I wouldn't pstack /proc/* though (to wake up all sleepers), since it stops each process for tracing and could lead to unexpected application deadlocks. Brendan -- Brendan [CA, USA] _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org