# hyper-v ubuntu虚拟机测试网卡并发，含sar tcpdump抓包 在 Hyper-V 中运行的 Ubuntu 18.04 虚拟机里，**没有直接命令能“检测网卡当时的并发量”或“并发上限”**，因为“并发量”在网络领域通常不是一个标准指标。但我们可以从以下几个角度理解你的需求，并提供对应的监控和分析方法： --- ### ✅ 一、澄清概念：什么是“网卡并发量”？ 在网络上下文中，“并发”一般指： - **同时建立的 TCP/UDP 连接数**（如 `netstat` 或 `ss` 统计的连接数） - **单位时间内的数据吞吐量**（如 Mbps、pps） - **网卡队列/中断处理能力**（底层性能） 而“并发上限”可能指： - 系统最大允许的 socket 连接数（受 `ulimit`、`net.core.somaxconn` 等限制） - 网卡或虚拟交换机的带宽上限（如 1 Gbps） - Hyper-V 虚拟网卡的性能瓶颈 --- ### ✅ 二、常用命令与工具（Ubuntu 18.04） #### 1. **查看当前网络连接数（模拟“并发连接”）** ```bash # 查看所有 TCP 连接数 ss -t | wc -l # 查看 ESTABLISHED 状态的连接数（更接近“活跃并发”） ss -t state established | wc -l # 按进程统计连接数 ss -tulpn ``` > ⚠️ 注意：这反映的是**应用层连接数**，不是网卡本身的“并发”。 --- #### 2. **实时监控网络带宽（吞吐量）** 使用 `iftop`、`nethogs`、`bmon` 等工具： ```bash # 安装 iftop（需 root） sudo apt update && sudo apt install iftop # 实时查看 eth0 的流量（按连接显示） sudo iftop -i eth0 ``` 输出示例： ``` 192.168.1.100 => 10.0.0.50 8.2Mb 12Mb 9.1Mb ``` → 表示当前每秒收发速率（近似“瞬时并发负载”） --- #### 3. **查看网卡理论带宽上限** Ubuntu 虚拟机中的网卡通常是 `hyperv_netvsc` 驱动（Hyper-V 虚拟网卡）： ```bash # 查看网卡速率（注意：虚拟网卡可能显示为 "unknown" 或 10000Mb/s） ethtool eth0 | grep Speed # 如果 ethtool 未安装： sudo apt install ethtool ``` > 💡 在 Hyper-V 中，虚拟网卡速率由 **虚拟交换机配置** 和 **主机物理网卡** 决定，通常可达 10 Gbps（逻辑值），实际受限于主机 I/O。 --- #### 4. **查看系统网络连接限制（“并发上限”相关参数）** ```bash # 最大监听队列长度（影响 accept() 并发） cat /proc/sys/net/core/somaxconn # 最大跟踪的连接数（netfilter） cat /proc/sys/net/netfilter/nf_conntrack_max # 当前已跟踪连接数 cat /proc/sys/net/netfilter/nf_conntrack_count ``` 若 `nf_conntrack_count` 接近 `nf_conntrack_max`，说明连接数已达系统上限。 --- #### 5. **压力测试网卡极限（主动探测上限）** 使用 `iperf3` 测试实际吞吐能力： ```bash # 在另一台机器运行服务端 iperf3 -s # 在 Ubuntu 虚拟机运行客户端 iperf3 -c -t 30 -P 8 ``` 可测出 **实际 TCP/UDP 吞吐上限（Mbps）和并发流性能**。 --- ### ✅ 三、Hyper-V 特别注意事项 1. **集成服务（Integration Services）必须启用** 确保 Ubuntu 安装了 `linux-virtual` 内核或启用了 Hyper-V 集成： ```bash lsmod | grep hv_ ``` 应看到 `hv_netvsc`、`hv_storvsc` 等模块。 2. **虚拟交换机类型影响性能** - **外部虚拟交换机**：性能最佳（直通物理网卡） - **内部/NAT**：有额外开销 3. **关闭不必要的功能提升性能** 在 Ubuntu 中可尝试： ```bash # 关闭 GRO（Generic Receive Offload）有时可提升小包性能 sudo ethtool -K eth0 gro off ``` --- ### ✅ 总结：如何回答你的问题？
你想知道的实际可用命令/方法
**当前“并发连接数”**`ss -t state established | wc -l`
**网卡实时流量（近似负载）**`iftop -i eth0`
**系统连接数上限**`cat /proc/sys/net/netfilter/nf_conntrack_max`
**网卡理论带宽**`ethtool eth0`（可能不准确）
**实际吞吐上限**`iperf3` 压力测试
> 📌 **结论**：没有单一命令能直接告诉你“网卡并发量”，但通过组合上述工具，你可以全面评估网络负载、连接数和性能瓶颈。 如需进一步分析（如丢包、重传），可使用 `sar -n DEV 1`（来自 `sysstat` 包）或 `tcpdump` 抓包分析。 当然可以！以下是针对 **Ubuntu 18.04** 系统，用于深入分析网络性能问题（如丢包、重传、吞吐瓶颈）的实用命令，特别适用于你当前在 Hyper-V 虚拟机中排查 `iperf3` 异常的场景。 --- ## ✅ 一、使用 `sar` 监控网卡实时流量与错误（来自 `sysstat`） ### 1. 安装 sysstat（如未安装） ```bash sudo apt update sudo apt install sysstat ``` > ⚠️ 注意：Ubuntu 默认可能禁用 `sysstat` 数据收集。 > 编辑配置文件启用： > > ```bash > sudo sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat > sudo systemctl restart sysstat > > ``` ### 2. 实时监控网卡统计（每秒刷新） ```bash # 监控所有网卡，每1秒输出一次 sar -n DEV 1 # 只监控 eth0 sar -n DEV 1 | grep eth0 ``` ### 🔍 关注字段含义：
字段说明
`rxpck/s`每秒接收的数据包数
`txpck/s`每秒发送的数据包数
`rxkB/s`每秒接收的千字节数（≈带宽）
`txkB/s`每秒发送的千字节数
`rxerr/s`**每秒接收错误包数（关键！）**
`txerr/s`**每秒发送错误包数（关键！）**
`rxdrop/s`接收丢包数（因缓冲区满等）
`txdrop/s`发送丢包数
> ✅ **如果 `rxerr/s` 或 `rxdrop/s > 0`，说明网卡或驱动层存在丢包！** --- ## ✅ 二、使用 `tcpdump` 抓包分析 TCP 行为（丢包、重传、窗口等） ### 1. 基础抓包（保存到文件） ```bash # 抓取与 10.2.2.227 的通信，保存为 pcap 文件 sudo tcpdump -i eth0 host 10.2.2.227 -w iperf_test.pcap ``` 在另一个终端运行 `iperf3 -c 10.2.2.227 -P 8 -t 10`，结束后按 `Ctrl+C` 停止抓包。 ### 2. 实时分析重传和丢包（命令行快速诊断） ```bash # 显示 TCP 重传（Retransmission） sudo tcpdump -i eth0 host 10.2.2.227 -nn -q | grep -i "retrans" # 或更精确地过滤 dup ack 和 fast retransmit sudo tcpdump -i eth0 host 10.2.2.227 -nn -q 'tcp[tcpflags] & (tcp-rst|tcp-syn) != 0 or tcp[13] & 8 != 0' ``` ### 3. 使用 `tshark`（Wireshark 命令行版）分析（推荐） 先安装： ```bash sudo apt install tshark ``` 然后分析重传比例： ```bash # 统计 TCP 重传包数量 tshark -r iperf_test.pcap -Y "tcp.analysis.retransmission" | wc -l # 查看 TCP Window Full（接收方缓冲区满） tshark -r iperf_test.pcap -Y "tcp.analysis.window_full" # 查看重复 ACK（暗示丢包） tshark -r iperf_test.pcap -Y "tcp.analysis.duplicate_ack" ``` --- ## ✅ 三、查看内核 TCP 统计（高级诊断） ### 1. 使用 `ss` 查看连接状态和重传 ```bash # 查看所有 TCP 连接的重传次数（重点看 rto、retrnsmt） ss -i state established # 示例输出片段： # cubic rto:204 rtt:4/2 cwnd:10 send 1.2Mbps rcv_space:14600 # → 如果 rto 很大或 retrnsmt > 0，说明有重传 ``` ### 2. 查看全局 TCP 错误统计 ```bash # 显示 TCP 重传、丢包等累计计数器 cat /proc/net/netstat | grep TcpExt # 关键字段（第二行对应值）： # TCPLostRetransmit, TCPFastRetrans, TCPSlowStartRetrans, TCPRenoRecovery, TCPSACKRecovery # TCPTimeouts, TCPLossProbes, TCPRenoFailures ``` 例如： ```bash awk '/TcpExt/ {getline; print}' /proc/net/netstat ``` 输出类似： ``` TcpExt: ... 0 5 0 0 12 ... ``` → 第 2 个数字是 `TCPFastRetrans`（快速重传次数），非零即有问题。 --- ## ✅ 四、综合诊断建议（针对你的场景） 由于你 **sender 是 Ubuntu，receiver 是 Windows（推测）**，且 `telnet` 通但 `iperf3` 数据收不到： ### 📌 推荐操作流程： 1. **在 Ubuntu sender 端运行**： ```bash # 开启 sar 监控 sar -n DEV 1 > sar_log.txt & # 同时抓包 sudo tcpdump -i eth0 host 10.2.2.227 -w debug.pcap & # 运行 iperf3 iperf3 -c 10.2.2.227 -P 8 -t 10 # 停止后台任务 killall sar tcpdump ``` 2. **分析结果**： - 查看 `sar_log.txt`：是否有 `rxerr/s` 或 `rxdrop/s`？ - 用 `tshark` 分析 `debug.pcap`： ```bash tshark -r debug.pcap -Y "tcp.analysis.retransmission" -T fields -e frame.time -e ip.src -e tcp.seq ``` - 如果 **只有 sender 发包，receiver 无 ACK** → 数据被中间设备丢弃（Windows 防火墙）。 - 如果 **有大量重传** → 网络拥塞或接收端处理慢。 --- ## ✅ 五、附加：快速检查驱动和中断（Hyper-V 特有） ```bash # 确认使用的是 hv_netvsc 驱动 ethtool -i eth0 | grep driver # 查看中断是否均衡（多 vCPU 时） cat /proc/interrupts | grep eth0 ``` > 在 Hyper-V 中，若虚拟机分配了多个 vCPU，但网络中断集中在 CPU0，可能导致瓶颈。 --- ### 总结：关键命令速查表
目的命令
实时带宽+错误`sar -n DEV 1`
抓包保存`tcpdump -i eth0 host 10.2.2.227 -w test.pcap`
检查重传`tshark -r test.pcap -Y "tcp.analysis.retransmission"`
查看连接重传`ss -i`
全局 TCP 错误`cat /proc/net/netstat | grep TcpExt`
--- 通过以上工具组合，你可以精准定位是 **丢包、重传、接收端不响应、还是驱动瓶颈**。 结合你之前的现象（receiver 收 0 字节），**最可能仍是 Windows 防火墙拦截**，但 `tcpdump` 能提供决定性证据。 如需进一步分析抓包文件，可将 `.pcap` 导出并在 Wireshark GUI 中打开，查看“Statistics → TCP Stream Graphs” 更直观。 你当前想分析 **昨天（2026年1月14日）18:00–19:00** 的网络设备（`-n DEV`）性能数据，但遇到了 `sar -n DEV 1 -f sar14` 报错： ``` Invalid system activity file: sar14 ``` 这是因为 **`sar` 命令读取的是 `saXX` 文件，而不是 `sarXX` 文件**。 --- ### ✅ 正确理解 sysstat 文件命名规则 在 Ubuntu/Debian 系统中： - **`saDD`**：二进制格式的原始系统活动数据文件（`sar` 命令读这个） - 例如：`sa14` → 代表 **14 日**的数据 - **`sarDD`**：通常是 `sar` 命令输出的文本日志（供人阅读），**不能被 `sar -f` 直接解析** > 📌 所以你应该使用 **`sa14`** 来分析 **1月14日** 的数据。 --- ### ✅ 正确命令：分析 1月14日 18:00–19:00 的网卡流量 ```bash # 查看 1月14日 全天的网卡统计（每10分钟一条，默认采集间隔） sar -n DEV -f /var/log/sysstat/sa14 # 只查看 18:00 到 19:00 之间的数据（注意：时间格式为 HH:MM:SS） sar -n DEV -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14 ``` > ⚠️ 注意： > > - `-s` 和 `-e` 指定起止时间（24小时制） > - 如果系统 `sysstat` 配置的采集间隔是 **10分钟**（默认），那么你只能看到 **18:00、18:10、18:20……18:50** 这些时间点的数据，**不会有秒级精度**。 > - 若需 1 秒粒度，必须当时用 `sar -n DEV 1` 实时记录（你没做，所以无法回溯秒级数据）。 --- ### 🔍 示例输出解读 运行后你会看到类似： ``` 06:10:01 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 06:20:01 PM eth0 12000 8000 15000 9000 0 0 0 12.3 ... 06:50:01 PM eth0 50000 48000 62000 60000 0 0 0 48.7 ``` 重点关注： - `rxkB/s` / `txkB/s`：接收/发送带宽（KB/s） - `%ifutil`：网卡利用率（部分驱动支持） - 如果 `rxerr/s` 或 `txerr/s` 出现（需加 `-n EDEV`），说明有错误 --- ### ✅ 补充：查看错误和丢包（如果需要） ```bash # 查看 1月14日 18-19点的网卡错误（如 CRC、丢包） sar -n EDEV -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14 ``` 字段说明： - `rxerr/s`：接收错误包/秒 - `txerr/s`：发送错误包/秒 - `coll/s`：冲突（半双工才有） - `rxdrop/s`：因缓冲区满丢弃的接收包 - `txdrop/s`：发送丢包 --- ### ❓ 为什么没有 `sa15` 完整文件？ 你看到： ``` -rw-r--r-- 1 root root 485428 Jan 15 16:45 sa15 ``` 这是因为 **今天（1月15日）还没结束**，`sa15` 是当天正在写入的临时文件。 通常在 **每日 23:59** 由 `sysstat` 的 cron 任务 finalize 成完整文件。 > ✅ 所以分析历史数据请用 `sa01` 到 `sa14`。 --- ### ✅ 总结：你要的命令 ```bash # 分析 2026-01-14 18:00–19:00 网卡流量 sar -n DEV -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14 # 如需错误统计 sar -n EDEV -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14 ``` > 💡 提示：如果输出为空，说明那段时间没有采集到数据（可能服务未运行，或采集间隔跳过了该时段）。 --- 如有其他需求（如分析 CPU、内存同期负载），也可用： ```bash sar -u -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14 # CPU sar -r -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14 # 内存 ``` 希望这能帮你精准定位昨天的网络性能状况！