Date: Sun, 25 Jan 2009 09:30:22 +0000 From: Kris Kennaway <kris@FreeBSD.org> To: Dieter <freebsd@sopwith.solgatos.com> Cc: freebsd-questions@FreeBSD.org Subject: Re: swap_pager complaints but not using swap Message-ID: <497C312E.6050802@FreeBSD.org> In-Reply-To: <200901241706.RAA07150@sopwith.solgatos.com> References: <200901241706.RAA07150@sopwith.solgatos.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dieter wrote: >>> AMD64 FreeBSD 7.0 2 GiB main memory >>> >>> My console says: >>> >>> login: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 22, size: 4096 >>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 22, size: 4096 >>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 22, size: 4096 >>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 22, size: 4096 >>> >>> pstat -sk >>> Device 1K-blocks Used Avail Capacity >>> /dev/ad6s10 4590208 96 4590112 0% >>> >>> Wow, using a whole 96K of swap. I don't see any disk related >>> complaints in dmesg. >>> >>> Is this something to worry about? >> Yes, the system was *trying* to do swap I/O and timing out while doing so. >> >> Kris > > Whoops, I forgot to change the subject line after adding the k option > to pstat. Without the k it said 0 used. And this morning it occurs to > me that even if swap used was zero, it could have been trying to *start* > using swap. > > Anyway... given this timeout explaination, I'm guessing that page/swap > has to compete with user processes for disk i/o, and thus probably > suffers from the same lack of fair i/o scheduling that user processes > suffer from. E.g. one process doing disk i/o can lock out another > process for at least several minutes, probably indefinitely. :-( There is a timeout of (from memory) 60 seconds. I've not seen this timeout exceeded on properly functioning disk hardware (even heavily loaded), only on broken hardware/controllers, or on I/O devices that are intrinsically slow for some reason (USB stick, or swapping to a file). Unless you're doing something truly unspeakable to that disk's load, I'd look at the hardware. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?497C312E.6050802>