vmstat 'b' (disk busy?) field keeps climbing ...

[Jonathan Noack]

Marc G. Fournier wrote:
> On Mon, 26 Jun 2006, Max Laier wrote:
>> On Monday 26 June 2006 20:25, Marc G. Fournier wrote:
>>> I think I might have found *at least* one of the problems, and that 
>>> being
>>> the excessively high blocked states while ps isn't finding anything ...
>>>
>>> MySQL
>>>
>>> We just recently started allowing clients to run a MySQL server *within*
>>> their vServer ... in a drastic move, I just shut them all down on pluto,
>>> and blocked drop'd from ~86 down to 5 in a matter of moments ...
>>> restarting them all has it climbing once more, being up around 22 
>>> already
>>> ...
>>>
>>> I'm going to go with that theory for now, and keep an eye on things ...
>>>
>>> Just curious as to why, even with -H, its not showing any blocked states
>>> within ps though ... ?
>>
>> The "blocked" column shows also processes that have objects "paging". 
>> Most likely you are *short* on memory.  In order to relieve the 
>> pressure program .text pages are free'ed and need to be refetched from 
>> disc whenever the respective code is being executed.
> 
> 'k, but shouldn't the OS be doing any swapping, if this was the case?  
> I'm getting <1M of swappage when the blocked pages are really high ...

It makes sense when you think about it (as Matthew Fuller pointed out in 
this thread 2 days ago).  There is no point in swapping out binary pages 
as they are ALREADY stored on disk and can be re-fetched with ease 
(remember the binary is marked in use so we don't have to worry about it 
getting modified out from under us); why double disk usage by storing 
binaries on the swap partition?  In this case, binary pages are getting 
paged out under memory pressure and have to be paged back in when 
needed.  This results in high vnode pager activity but little swap pager 
activity.

Matthew pointed out that the vnode pager also handles mmap()'d files, 
which could come into play with MySQL.

-Jonathan