> root@backend4a:~# ifstat -b
> eth0 eth1 eth2 eth3
> eth4 eth5 eth6
> Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out Kbps in Kbps
> out Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out
> 8375.12 52575.00 0.44 0.00 4.31 0.00 43416.20
> 7713.50 0.00 0.00 43.38 31.68 300.96 26.59
> 9268.63 51068.23 0.44 0.00 3.73 0.00 40364.53
> 8733.16 0.00 0.00 13.40 15.26 8.79 12.37
> 7685.08 42964.82 0.44 0.00 3.71 0.00 45665.90
> 7254.55 0.00 0.00 1884.36 72.96 9.17 9.19
>
> U see the cpu use about 40% of the cpu but the traffic is just 3~5MB/s.
It depends on your traffic patterns, but this is arguably high. What
was it like on the machines you replaced?
> This make me doubt does the cache system Squid is suitable for
> virtualization. Or the bad performance caused by our configuration ? Has
> anyone use squid in xen can talk about ?
Virtualization _does_ add overhead, especially for
data-transmission-intensive tasks such as caching. The average
overhead of virtualization is a 5-7% performance penalty; probably
caches make it worse but even doubling the average numbers we get a
10-15% expected performance drop.
I haven't use virtualization in a performance-sensitive environment.
In general I would recommend against going virtual so if absolute
performance is important.
Also because caches in general (and squid in particular) are at most
at ease when they have very simple paths to the disks.
If you're running on a VM, a common deployment scenario is that you're
running the VM virtual disks off a RAID or (even worse) off a NAS
(which is then again on RAID) or SAN.
Squid's data access patterns are especially unfriendly to these
scenarios: you get all sorts of misaligned writes, parity
recalculations, extra read/write load.
--
/kinkie
