high load system do not take all CPU time
bonomi at mail.r-bonomi.com
Sun Dec 18 19:05:33 UTC 2011
<kes-kes at yandex.ru> wrote;
> can I get interrupt limit or calculate it before that limit is
You can extrapolate from the current cpu time spent in interrupt handling
and the current interrupt rate to a situation where roughly 100% of the
cpu capacity is spent in interrupt handling.
> interrupt source is internal card:
> # vmstat -i
> interrupt total rate
> irq14: ata0 349756 78
> irq16: ehci0 7427 1
> irq23: ehci1 12150 2
> cpu0:timer 18268704 4122
> irq256: re0 85001260 19178
> cpu1:timer 18262192 4120
> cpu2:timer 18217064 4110
> cpu3:timer 18210509 4108
> Total 158329062 35724
> Have you any good I/O tuning links to read?
Since the 'issue' is the _network_ card, you are being limited by the
rate at which the RealTeK chipset, and the device driver software, can
transfer data to/from the Ethernet. This -may- be the 'wire speed' limit,
or the hardware simply may not be capable of performing _at_ 'wire speed',
or (theoretically) it might be a performance limit in the driver software.
In your case, the driver software can be eliminated as the limiting factor
because there is lots of 'idle' cpu time.
This means that either the 'wire' is saturated, or the hardware (at *either*
end of the link) is not capable of operating at full "wire speed". Or one
is getting bit by the 'bAndwidth delay product' on TCP connections. This
describes a situation where the limit on 'un-ACKed' packets transmitted is
reached -before- the ACK for the first packet is returned.
If the application that use the nentwork are generating lots of 'small'
packets, modifying the protocol to use a smaller number of larger packets
can make for a -significant- performance increase. Network devices have
limits on the number of 'packets per second' they can handle, as well as
the bit-rate they can support.
Note: If you are doing long-distance, high-latency, 'connections', one
may be limited to well below wire speeds by the 'bandwidth delay product'.
This issue can be ameliorated by increasing the TCP window size.
More information about the freebsd-questions