Extreme console latency during disk IO (8.0-RC1, previous
releases also affected according to others)
ivoras at freebsd.org
Tue Oct 13 14:26:06 UTC 2009
Robert N. M. Watson wrote:
> On 13 Oct 2009, at 14:33, Ivan Voras wrote:
>>> If (1) is highly variable during I/O, it's almost certainly a
>>> property of
>>> the VM technology you're using, and there's nought to be done about
>>> it in
>>> the guest OS.
>> Here's an example of a ping session with 0.1s resolution during a few
>> seconds-stall in ssh:
>> 64 bytes from 18.104.22.168: icmp_seq=1576 ttl=64 time=0.383 ms
>> 64 bytes from 22.214.171.124: icmp_seq=1577 ttl=64 time=0.405 ms
>> 64 bytes from 126.96.36.199: icmp_seq=1578 ttl=64 time=0.360 ms
>> 64 bytes from 188.8.131.52: icmp_seq=2304 ttl=64 time=4.194 ms
>> 64 bytes from 184.108.40.206: icmp_seq=2305 ttl=64 time=0.454 ms
>> 64 bytes from 220.127.116.11: icmp_seq=2306 ttl=64 time=0.376 ms
>> note huge packet loss. It looks like it's VM fault or something like it.
> It sounds like the VM is failing to execute the guest during certain
> types of I/O. A bit of scheduler tracing in the host OS probably
> wouldn't go amiss to confirm that the VM really is suspending the guest
> at about the same time ICMP latency goes up. However, given the above I
> think I you can reasonable assume that the 4ms jump you're seeing there
> is due to global host OS/VM scheduling, and not FreeBSD scheduling.
Btw. it's not a "4 ms jump" - there are 726 lost packets in between.
More information about the freebsd-stable