vmstat 'b' (disk busy?) field keeps climbing ...
Marc G. Fournier
scrappy at hub.org
Sun Jun 25 04:16:15 UTC 2006
'k, this has gotta be a leak somewhere ... I'm now up to 6 blocked:
0 8 0 7449224 236552 213 2 1 0 109 0 101 0 475 2890 2143 2 6 92
0 6 0 7481104 247704 578 0 0 0 1196 0 262 0 808 8901 3049 5 16 79
0 6 0 7450820 253576 1385 3 2 3 1379 0 13 0 303 4742 1703 13 13 73
0 6 0 7478168 248372 295 0 0 0 160 0 57 0 428 1900 2616 2 7 92
0 6 0 7473064 249072 1 0 0 0 23 0 6 0 273 822 845 1 2 97
1 6 0 7479000 243164 275 17 7 0 144 0 17 0 317 1572 2180 2 6 92
But there don't appear to be any processes reporting itself as being blocked:
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
0 30418 30416 6 8 0 4916 2624 ppwait Ds pa 0:00.13 -csh (csh)
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
0 30418 30416 137 8 0 4916 2624 ppwait Ds pa 0:00.14 -csh (csh)
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
pluto# ps axlww | awk '$10 ~ /^D[^L]/'
Or is there something else I should be looking at/for?
In the case of this system, its kernel sources from ~May 25th ...
On Sat, 24 Jun 2006, Marc G. Fournier wrote:
> On Sat, 24 Jun 2006, Kostik Belousov wrote:
>
>> 2. 2 Giant holders/lockers. Is it constant ? Are the processes
>> holding/waiting
>> for Giant are the same ?
>
> Mostly appears to be 'clock' ...
>
> pluto# ps axlww | grep Giant | grep -v grep
> 0 12 0 0 -32 0 0 8 Giant LL ?? 3:07.03 [swi4:
> clock]
> pluto# ps axlww | grep Giant | grep -v grep
> 0 12 0 0 -32 0 0 8 Giant LL ?? 3:07.03 [swi4:
> clock]
> pluto# ps axlww | grep Giant | grep -v grep
> 0 12 0 0 -32 0 0 8 Giant LL ?? 3:07.03 [swi4:
> clock]
> pluto# ps axlww | grep Giant | grep -v grep
> pluto# ps axlww | grep Giant | grep -v grep
> 0 12 0 0 -32 0 0 8 Giant LL ?? 3:07.03 [swi4:
> clock]
> pluto# ps axlww | grep Giant | grep -v grep
> pluto# ps axlww | grep Giant | grep -v grep
> 0 12 0 0 -32 0 0 8 Giant LL ?? 3:07.03 [swi4:
> clock]
> pluto# ps axlww | grep Giant | grep -v grep
> pluto# ps axlww | grep Giant | grep -v grep
> 0 92517 46540 114 110 0 5032 2412 Giant LV+ p4 0:00.00 -csh
> (csh)
> pluto# ps axlww | grep Giant | grep -v grep
> 0 12 0 0 -32 0 0 8 Giant LL ?? 3:07.04 [swi4:
> clock]
> 1001 14098 1 0 96 0 3308 1324 Giant LsJ ?? 0:04.98
> /usr/local/libexec/postfix/master
> pluto# ps axlww | grep Giant | grep -v grep
> pluto# ps axlww | grep Giant | grep -v grep
> 0 12 0 0 -32 0 0 8 Giant LL ?? 3:07.04 [swi4:
> clock]
> pluto# ps axlww | grep Giant | grep -v grep
> pluto#
>
> And I suspect that the master is disk i/o, since the iir driver is listed as
> still GIANT-LOCKED:
>
> iir0: <Intel Integrated RAID Controller> mem 0xfc8f0000-0xfc8f3fff irq 30 at
> device 9.0 on pci1
> iir0: [GIANT-LOCKED]
>
>> Ah, and does dmesg show anything ?
>
> Anything (other then the iir driver) that I'd be looking for in there? Or
> could that be what is compounding the problem? Too many things trying to
> acquire GIANT over the drive(s), creating a deadlock? Long shot there ... ?
>
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email . scrappy at hub.org MSN . scrappy at hub.org
> Yahoo . yscrappy Skype: hub.org ICQ . 7615664
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy at hub.org MSN . scrappy at hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
More information about the freebsd-stable
mailing list