linux网卡通信延迟高,Linux性能优化-网络请求延迟变大
目录
网络延迟
案例分析
总结
网络延迟
常用的是双向的往返通信延迟,比如 ping 测试的结果,就是往返延时 RTT(Round-Trip Time)
除了网络延迟外,另一个常用的指标是应用程序延迟,它是指,从应用程序接收到请求,再到发回响应,全程所用的时间。
通常,应用程序延迟也指的是往返延迟,是网络数据传输时间加上数据处理时间的和。
可以用 ping 来测试网络延迟。ping 基于 ICMP 协议,它通过计算 ICMP 回显响应报文与 ICMP 回显请求报文的时间差,来获得往返延时。
这个过程并不需要特殊认证,常被很多网络攻击利用,比如端口扫描工具 nmap、组包工具 hping3 等等。
为了避免这些问题,很多网络服务会把 ICMP 禁止掉,导致我们无法用 ping ,来测试网络服务的可用性和往返延时。
这时,可以用 traceroute 或 hping3 的 TCP 和 UDP 模式,来获取网络延迟。
用hping3测试TCP连通性,往返百度的时间,为31毫
hping3 -c 3 -S -p 80 www.baidu.com
HPING www.baidu.com (eth0 180.97.33.107): S set, 40 headers + 0 data bytes
len=40 ip=180.97.33.107 ttl=52 id=43290 sport=80 flags=SA seq=0 win=8192 rtt=30.8 ms
len=40 ip=180.97.33.107 ttl=52 id=2031 sport=80 flags=SA seq=1 win=8192 rtt=30.4 ms
len=40 ip=180.97.33.107 ttl=52 id=38026 sport=80 flags=SA seq=2 win=8192 rtt=33.7 ms
--- www.baidu.com hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 30.4/31.7/33.7 ms
使用traceroute测试百度
traceroute --tcp -p 80 -n www.baidu.com
traceroute to www.baidu.com (180.97.33.107), 30 hops max, 60 byte packets
1 * * *
2 11.220.30.13 7.570 ms 8.186 ms 11.220.31.13 6.699 ms
3 * * 11.220.31.138 1.996 ms
4 11.204.180.98 4.482 ms 11.218.196.250 4.087 ms 11.204.180.122 3.793 ms
5 116.251.117.2 2.668 ms 2.618 ms 116.251.117.10 2.829 ms
6 116.251.112.157 2.898 ms 103.41.141.85 3.419 ms 116.251.112.165 3.155 ms
7 * * *
8 36.110.244.61 5.907 ms 180.149.141.117 5.921 ms 180.149.141.145 4.990 ms
9 220.181.177.77 3.651 ms 36.110.244.33 4.363 ms *
10 * * *
11 202.102.69.14 32.121 ms 202.102.69.58 37.728 ms 37.448 ms
12 * * *
13 180.97.32.102 30.030 ms 180.97.32.74 110.789 ms 180.97.32.94 30.907 ms
14 * * *
15 * * 180.97.33.107 35.010 ms
案例分析
案例中使用到的环境如下
安装wrk
wget https://codeload.github.com/wg/wrk/zip/master .
unzip wrk-master.zip
cd wrk-master
yum install build-essential -y
make
cp wrk /usr/local/bin
启动一个正常的nginx
docker run --network=host --name=good -i -t -d
启动案例nginx
docker run --name nginx_test --network=host -i -t -d feisky/nginx:latency
测试两个环境的nginx返回情况
curl http://【服务端IP】:80/
。。。
Thank you for using nginx.
。。。
curl http://【服务端IP】:8080/
。。。
Thank you for using nginx.
。。。
用 wrk 测试两个服务器的并发连接性能
wrk --latency -c 100 -t 2 --timeout 2 http://【服务端ip】:80/
Running 10s test @ http://【服务端ip】:80/
2 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 173.32ms 296.47ms 1.94s 88.71%
Req/Sec 69.35 58.00 545.00 86.98%
Latency Distribution
50% 31.80ms
75% 265.96ms
90% 492.02ms
99% 1.61s
1355 requests in 10.01s, 1.10MB read
Socket errors: connect 0, read 0, write 0, timeout 13
Requests/sec: 135.33
Transfer/sec: 112.76KB
wrk --latency -c 100 -t 2 --timeout 2 http://【服务端ip】:8080/
Running 10s test @ http://【服务端ip】:8080/
2 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 269.46ms 387.81ms 1.94s 89.15%
Req/Sec 65.35 41.21 490.00 91.96%
Latency Distribution
50% 53.39ms
75% 274.77ms
90% 833.70ms
99% 1.85s
1302 requests in 10.02s, 1.07MB read
Socket errors: connect 0, read 0, write 0, timeout 28
Requests/sec: 129.94
Transfer/sec: 109.32KB
从分布上看正常的nginx 90%的请求是在492毫秒内完成的
而有问题的nginx 90%的请求是在833毫秒内完成的
抓包分析
tcpdump -nn tcp port 8080 -w nginx.pcap
再继续执行
wrk --latency -c 100 -t 2 --timeout 2 http://【服务端ip】:8080/
Running 10s test @ http://【服务端ip】:8080/
tcpdump 抓包后用Wireshark打开后分析交互过程
每次数据包回复都有延迟
这个跟Nagle算法有关,除非客户端开启了 TCP_QUICKACK模式,否则默认情况下采用的是 延迟确认机制
TCP_NODELAY
If set, disable the Nagle algorithm. This means that segments are always sent as soon as possible, even if there is only a small amount
of data. When not set, data is buffered until there is a sufficient amount to send out, thereby avoiding the frequent sending of small
packets, which results in poor utilization of the network. This option is overridden by TCP_CORK; however, setting this option forces
an explicit flush of pending output, even if TCP_CORK is currently set.
TCP_QUICKACK (since Linux 2.4.4)
Enable quickack mode if set or disable quickack mode if cleared. In quickack mode, acks are sent immediately, rather than delayed if
needed in accordance to normal TCP operation. This flag is not permanent, it only enables a switch to or from quickack mode. Subse-
quent operation of the TCP protocol will once again enter/leave quickack mode depending on internal protocol processing and factors such
as delayed ack timeouts occurring and data transfer. This option should not be used in code intended to be portable.
strace 分析 wrk的启动模式,是用了TCP_NODELAY,但没起开TCP_QUICKACK,所以采用的是延迟确
setsockopt(52, SOL_TCP, TCP_NODELAY, [1] 4) = 0
Nagle算法的机制如下图
当Server发送了第一个分组后,由于Client开启了延迟确认,就需要等待40毫秒后才会回复ACK
同时,由于Server端开启了Nagle,而这时还没收到第一个分组的ACK,Server也会在这里一直等待
直到40毫秒超时后,Client才会回复ACK,然后Server才会继续发送第二个分组
查看有问题的nginx的配置情况
docker exec nginx_test cat /etc/nginx/nginx.conf | grep tcp_nodelay
tcp_nodelay off;
关闭之前有问题的,启动一个修改后的
docker run --name nginx_good --network=host -i -t -d feisky/nginx:nodelay
再用wrk检查一下,这次比上次快了
wrk --latency -c 100 -t 2 --timeout 2 http://【服务端ip】:8080/
Running 10s test @ http://【服务端ip】:8080/
2 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 211.41ms 332.29ms 1.98s 88.30%
Req/Sec 69.99 66.81 767.00 95.83%
Latency Distribution
50% 36.01ms
75% 272.11ms
90% 639.90ms
99% 1.61s
1366 requests in 10.02s, 1.11MB read
Socket errors: connect 0, read 0, write 0, timeout 28
Requests/sec: 136.36
Transfer/sec: 113.65KB
总结
在发现网络延迟增大后,可以调用各种工具定位网络潜在问题
使用hping3以及wrk等工具,确认单词请求和并发请求的网络延迟是否正常
使用tcpdump和Wireshark,确认网络包的收发是否正常
使用strace,观察应用程序对网络套接字的调用情况是否正常
这样,就可以依次从路由,网络包的收发,再到应用程序等,逐层排查,直到定位问题根源
linux网卡通信延迟高,Linux性能优化-网络请求延迟变大相关推荐
- 游戏延迟测试软件,官方发布游戏延迟测试工具将优化网络
原标题:官方发布游戏延迟测试工具将优化网络 英雄联盟是一个不怎么吃电脑配置的游戏,毕竟是2009年发布的游戏,虽然在今年更新的新版客户端,但底层代码和游戏引擎仍然不太占据电脑运行空间.但对于英雄联盟这 ...
- 网络请求延迟变大了,我该怎么办?
本文是通过学习倪朋飞老师的<Linux性能优化实战> :网络请求延迟变大了,我该怎么办? 网络请求延迟变大了,我该怎么办? 网络延迟 案例准备 总结 除了 DDoS 会带来网络延迟增大外, ...
- 【linux性能优化】系统Swap变高原因分析
一.内存处理 1.1 内存资源紧张的应对 当发生了内存泄漏或者运行大内存的应用程序,导致系统的内存资源紧张时,系统又会如何应对呢? 这其实会导致两种可能结果,内存回收和OOM杀死进程 OOM杀死进程 ...
- linux【网络】网络请求延迟变大了,我该怎么办?
文章目录 1. 回顾 2. 网络延迟 3. 案例准备 4. 总结 1. 回顾 DDoS 利用大量的伪造请求,导致目标服务要耗费大量资源,来处理这些无效请求,进而无法正常响应正常用户的请求. 由于 DD ...
- linux网卡缓冲区设置,【Linux】tcp缓冲区大小的默认值、最大值
Author:阿冬哥 Created:2013-4-17 Blog:http://blog.csdn.net/c359719435/ Copyright 2013 阿冬哥 http://blog.cs ...
- linux网卡配子接口,linux 内核学习(2).
linux 内核学习(2). (2011-07-18 01:45:46) 标签: 杂谈 linux内核源码树基本构造 由于linux的原代码继续在改变,因而不可能给出太翔实的内容,只能指出一个特异的驱 ...
- linux网卡恢复默认配置,Linux网卡的配置
(2)开启网卡服务: CentOS默认网卡是没有启动的,我们执行如下命令,修改网卡配置文件: vi /etc/sysconfig/network-scripts/ifcfg-eth0 然后,将ONBO ...
- linux 网卡驱动分析,基于linux下网卡驱动分析及实现技术研究
摘 要 Linux技术是当前计算机技术中最大的一个热点,在我国以及全世界得到了迅猛的发展,被广泛的应用于嵌入式系统.服务器.网络系统.安全等领域.从而使得掌握在 Linux环境下的开发技术,成为 ...
- linux网卡驱动开发视频,Linux下网卡驱动程序的开发.doc
Linux下网卡驱动程序的开发 论文题目:Linux下网卡驱动程序的开发 专 业: 年 级: 学生学号: 学生姓名: 指导教师: 完成时间: Linux下网卡驱动程序的开发 八年经验 专业指导毕业设计 ...
最新文章
- Spring Boot注册Servlet三大组件(Servlet, Filter, Listener)
- Android studio 设置主题
- 拼多多的真实面试题:数亿的用户,如何用Redis统计独立用户访问量
- html文件设置成mac屏保,Mac怎么设置屏幕保护?如何设置Mac屏幕保护程序?
- jquery-pjax
- Git:git合并分支
- MAXScript语法及命令
- Xmanager4注册码
- IDEA使用教程之创建一个工程(一)
- C语言 - 计算n的阶乘(n!)
- mysql五日均线_中国股市:一根“5日均线”走天下,线上买,线下卖,简直了!...
- 与matlab里面 imadjust 函数相同的python代码
- 【第六章】使用jQuery操作表单和表格2
- “离婚”华为后,荣耀第一胎满身伤痕
- C语言程序设计50行以上,C语言程序设计100例——都卡会了,2级绝对没问题了---2...
- is_infinite() 函数
- 高性能JavaScript模板引擎template.js原理解析
- 这谁顶得住?Mybatis 十八连环问
- 第十五章 拒绝服务
- 用标准理性的思维找女朋友