I know this question has been asked before, but maybe not in this particular context:
I have a setup with a couple of MS2008R2 HyperVisor servers running a number of Ubuntu guests.
Our webproxy runs Ubuntu 12.04 LTS and has a lot of packets pruned. We are using the synthetic LAN driver, and configured with 5 ethernet alias interfaces (eth0:1 - eth0:5).
I have tuned the kernel according to various tips given here (extending buffer memory from 128KB to 16MB) - and no changes whatsoever to the symptom.
I have extended the amount of RX (and TX) descriptors (256 -> 512 resp. 512 -> 1024) on the LAN-card in the HyperV server - still no sign of improvement. Max no of descriptors is 2048 according to Intel (Intel Pro 1Gbps 4 port card). The physical network is based on 1G switches.
The funny thing is that we do not have the impression that anything is performing poorly - every webserver behind the webproxy (reverse proxy/gateway) seems to work as expected.
Here are some key parameters from sysctl:
net.core.wmem_max = 12582912 net.core.rmem_max = 16777216 net.core.wmem_default = 229376 net.core.rmem_default = 229376 net.core.optmem_max = 20480 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_retrans_collapse = 1 net.ipv4.tcp_syn_retries = 5 net.ipv4.tcp_synack_retries = 5 net.ipv4.tcp_max_orphans = 131072 net.ipv4.tcp_max_tw_buckets = 131072 net.ipv4.tcp_keepalive_time = 7200 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_retries1 = 3 net.ipv4.tcp_retries2 = 15 net.ipv4.tcp_fin_timeout = 60 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_recycle = 0 net.ipv4.tcp_abort_on_overflow = 0 net.ipv4.tcp_stdurg = 0 net.ipv4.tcp_rfc1337 = 0 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.tcp_orphan_retries = 0 net.ipv4.tcp_fack = 1 net.ipv4.tcp_reordering = 3 net.ipv4.tcp_ecn = 2 net.ipv4.tcp_dsack = 1 net.ipv4.tcp_mem = 48369 64495 96738 net.ipv4.tcp_wmem = 10240 87380 12582912 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_app_win = 31 net.ipv4.tcp_adv_win_scale = 2 net.ipv4.tcp_tw_reuse = 0 net.ipv4.tcp_frto = 2 net.ipv4.tcp_frto_response = 0 net.ipv4.tcp_low_latency = 0 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_moderate_rcvbuf = 1 net.ipv4.tcp_tso_win_divisor = 3 net.ipv4.tcp_congestion_control = cubic net.ipv4.tcp_abc = 0 net.ipv4.tcp_mtu_probing = 0 net.ipv4.tcp_base_mss = 512 net.ipv4.tcp_workaround_signed_windows = 0 net.ipv4.tcp_dma_copybreak = 4096 net.ipv4.tcp_slow_start_after_idle = 1 net.ipv4.tcp_available_congestion_control = cubic reno net.ipv4.tcp_allowed_congestion_control = cubic reno net.ipv4.tcp_max_ssthresh = 0 net.ipv4.tcp_cookie_size = 0 net.ipv4.tcp_thin_linear_timeouts = 0 net.ipv4.tcp_thin_dupack = 0
Therefore the question(s): What exactly is happening when these packets are pruned? Are packets just being retransmitted later on, giving the impression that everything is OK? Or do we really have to worry about those pacets being pruned? Could the symptom indicate a backpressure from the firewall (Sonicwall) issuing traffic shaping (@ 100 Mbps)?
Figures are 10K to 20K pruned packetes every 3 minutes (according to our Nagios monitoring) - so actually a lot of pruned packets.
Any tips or answers appreciated! :)
EDIT: We are not using SR-IOV (as this is 2012 stuff I've been told), and we are using some kind of virtual switch (in Windows Server 2008 R2)