Linux性能优化实战
倪朋飞
微软资深工程师,Kubernetes项目维护者
立即订阅
23409 人已学习
课程目录
已完结 64 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (2讲)
开篇词 | 别再让Linux性能问题成为你的绊脚石
免费
01 | 如何学习Linux性能优化?
CPU 性能篇 (13讲)
02 | 基础篇:到底应该怎么理解“平均负载”?
03 | 基础篇:经常说的 CPU 上下文切换是什么意思?(上)
04 | 基础篇:经常说的 CPU 上下文切换是什么意思?(下)
05 | 基础篇:某个应用的CPU使用率居然达到100%,我该怎么办?
06 | 案例篇:系统的 CPU 使用率很高,但为啥却找不到高 CPU 的应用?
07 | 案例篇:系统中出现大量不可中断进程和僵尸进程怎么办?(上)
08 | 案例篇:系统中出现大量不可中断进程和僵尸进程怎么办?(下)
09 | 基础篇:怎么理解Linux软中断?
10 | 案例篇:系统的软中断CPU使用率升高,我该怎么办?
11 | 套路篇:如何迅速分析出系统CPU的瓶颈在哪里?
12 | 套路篇:CPU 性能优化的几个思路
13 | 答疑(一):无法模拟出 RES 中断的问题,怎么办?
14 | 答疑(二):如何用perf工具分析Java程序?
内存性能篇 (8讲)
15 | 基础篇:Linux内存是怎么工作的?
16 | 基础篇:怎么理解内存中的Buffer和Cache?
17 | 案例篇:如何利用系统缓存优化程序的运行效率?
18 | 案例篇:内存泄漏了,我该如何定位和处理?
19 | 案例篇:为什么系统的Swap变高了(上)
20 | 案例篇:为什么系统的Swap变高了?(下)
21 | 套路篇:如何“快准狠”找到系统内存的问题?
22 | 答疑(三):文件系统与磁盘的区别是什么?
I/O 性能篇 (10讲)
23 | 基础篇:Linux 文件系统是怎么工作的?
24 | 基础篇:Linux 磁盘I/O是怎么工作的(上)
25 | 基础篇:Linux 磁盘I/O是怎么工作的(下)
26 | 案例篇:如何找出狂打日志的“内鬼”?
27 | 案例篇:为什么我的磁盘I/O延迟很高?
28 | 案例篇:一个SQL查询要15秒,这是怎么回事?
29 | 案例篇:Redis响应严重延迟,如何解决?
30 | 套路篇:如何迅速分析出系统I/O的瓶颈在哪里?
31 | 套路篇:磁盘 I/O 性能优化的几个思路
32 | 答疑(四):阻塞、非阻塞 I/O 与同步、异步 I/O 的区别和联系
网络性能篇 (13讲)
33 | 关于 Linux 网络,你必须知道这些(上)
34 | 关于 Linux 网络,你必须知道这些(下)
35 | 基础篇:C10K 和 C1000K 回顾
36 | 套路篇:怎么评估系统的网络性能?
37 | 案例篇:DNS 解析时快时慢,我该怎么办?
38 | 案例篇:怎么使用 tcpdump 和 Wireshark 分析网络流量?
39 | 案例篇:怎么缓解 DDoS 攻击带来的性能下降问题?
40 | 案例篇:网络请求延迟变大了,我该怎么办?
41 | 案例篇:如何优化 NAT 性能?(上)
42 | 案例篇:如何优化 NAT 性能?(下)
43 | 套路篇:网络性能优化的几个思路(上)
44 | 套路篇:网络性能优化的几个思路(下)
45 | 答疑(五):网络收发过程中,缓冲区位置在哪里?
综合实战篇 (13讲)
46 | 案例篇:为什么应用容器化后,启动慢了很多?
47 | 案例篇:服务器总是时不时丢包,我该怎么办?(上)
48 | 案例篇:服务器总是时不时丢包,我该怎么办?(下)
49 | 案例篇:内核线程 CPU 利用率太高,我该怎么办?
50 | 案例篇:动态追踪怎么用?(上)
51 | 案例篇:动态追踪怎么用?(下)
52 | 案例篇:服务吞吐量下降很厉害,怎么分析?
53 | 套路篇:系统监控的综合思路
54 | 套路篇:应用监控的一般思路
55 | 套路篇:分析性能问题的一般步骤
56 | 套路篇:优化性能问题的一般方法
57 | 套路篇:Linux 性能工具速查
58 | 答疑(六):容器冷启动如何性能分析?
加餐篇 (4讲)
加餐(一) | 书单推荐:性能优化和Linux 系统原理
加餐(二) | 书单推荐:网络原理和 Linux 内核实现
用户故事 | “半路出家 ”,也要顺利拿下性能优化!
用户故事 | 运维和开发工程师们怎么说?
结束语 (1讲)
结束语 | 愿你攻克性能难关
Linux性能优化实战
登录|注册

40 | 案例篇:网络请求延迟变大了,我该怎么办?

倪朋飞 2019-02-22
你好,我是倪朋飞。
上一节,我们学习了碰到分布式拒绝服务(DDoS)的缓解方法。简单回顾一下,DDoS 利用大量的伪造请求,导致目标服务要耗费大量资源,来处理这些无效请求,进而无法正常响应正常用户的请求。
由于 DDoS 的分布式、大流量、难追踪等特点,目前确实还没有方法,能够完全防御 DDoS 带来的问题,我们只能设法缓解 DDoS 带来的影响。
比如,你可以购买专业的流量清洗设备和网络防火墙,在网络入口处阻断恶意流量,只保留正常流量进入数据中心的服务器。
在 Linux 服务器中,你可以通过内核调优、DPDK、XDP 等多种方法,增大服务器的抗攻击能力,降低 DDoS 对正常服务的影响。而在应用程序中,你可以利用各级缓存、 WAF、CDN 等方式,缓解 DDoS 对应用程序的影响。
不过要注意,如果 DDoS 的流量,已经到了 Linux 服务器中,那么,即使应用层做了各种优化,网络服务的延迟一般还是会比正常情况大很多。
所以,在实际应用中,我们通常要让 Linux 服务器,配合专业的流量清洗以及网络防火墙设备,一起来缓解这一问题。
除了 DDoS 会带来网络延迟增大外,我想,你肯定见到过不少其他原因导致的网络延迟,比如
网络传输慢,导致延迟;
Linux 内核协议栈报文处理慢,导致延迟;
应用程序数据处理慢,导致延迟等等。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Linux性能优化实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(23)

  • 我来也
    [D40打卡]
    我之前理解的网络延迟分三部分:客户端到服务端,服务端逻辑处理,服务端到客户端到耗时。

    其中服务端逻辑处理的耗时是跟自身程序有关的,另外两个耗时跟宽带服务提供商有关,想更短的耗时就得加钱:选更优的线路或者在靠近客户端的地方加入口。

    目前我们线上程序是可以推算出单次响应的时间的,因为在出入口的地方有记录。不管中间经过了多少服务的处理,都可以算出总的耗时。

    我们在客户端中也加了汇报功能,在客户端的某些消息中会汇报 客户端实际发送请求->收到服务端响应 的时间差。这样便于我们确认客户端的网络状况。

    从本文中,第一次见到了 Nagle 算法。也知道了服务端关闭icmp时怎么用tcp/udp测试网络延迟。

    文中的内容也是跌宕起伏,分析着怎么还是客户端的问题,客户端访问另外一个服务还是好的。原来是服务端程序也有问题,一个巴掌拍不响。😂

    作者回复: 😊谢谢分享你的经验

    2019-02-22
    6
  • Christmas
    以前经常看到tcp no delay的socket设置,一直不求甚解,这次终于懂了,nagle算法
    2019-03-04
    3
  • Andylee
    我记得之前碰到的延迟ack是200ms,这个是可以配置的吗?

    作者回复: 看系统的,据我所知,只有RHEL可以通过/proc/sys/net/ipv4/tcp_delack_min修改(默认40ms),而其他发行版都不支持。

    2019-02-22
    3
  • Linuxer
    案例中能设置客户端的TCP_QUICKACK解决吗?

    作者回复: 嗯,只是客户端有可能在用户那儿,可能无法控制这些选项

    2019-02-22
    2
  • 微微
    遇到一个问题,backlog设置的很大,有22w,但是用ss -ltn命令查看这个监听端口的Send-Q和Recv-Q都是0,但是用命令netstat -s|egrep "listen|LISTEN"的溢出值一直在上升,统计这个端口的连接数还不到5000,请问可能会是什么原因?
    2019-10-21
    1
    1
  • 大坏狐狸
    额 第二次居然curl不通了。。18.04 的防火墙是ufw ,需要ufw allow 80/tcp

    作者回复: 👍 谢谢分享

    2019-05-27
    1
  • Maxwell
    为什么执行strace -f wrk --latency -c 100 -t 2 --timeout 2 http://192.168.126.136:8080/,输出结果中并没有TCP_NODELAY配置选项呢?

    作者回复: 是不是还有其他报错?

    2019-03-24
    1
  • 青石
    网上查了Nagle算法的定义:任意时刻,最多只能有一个未被确认的小段。所谓“小段”,指的是小于MSS尺寸的数据块,所谓“未被确认”,是指一个数据块发送出去后,没有收到对方发送的ACK确认该数据已收到。

    对比80端口和8080端口的报文,80端口的报文中,响应消息再发送完header后立刻发送body部分;8080端口的报文,响应消息再发送完header后,需要获得ACK响应后,才会发送body部分。

    8080端口报文中server端在获得到ACK响应后才发送body部分,就是因为Nagle算法必须确认这个数据块被收到的原因。client在40ms后发送ACK是因为客户端没有开启TCP_QUICKACK的缘故。

    请问老师,这样理解,对吗?

    作者回复: 嗯

    2019-03-19
    1
  • 你好,我在网络编程中遇到一个问题,
    我们用go语言做的服务调用其他HTTP服务器,发现HTTP请求中卡住,概率非常低。
    然后我看了发现write,返回eagain,然后就等待epoll通知描述符是否可用,这个时候发现等了很久很久都不可用。netstata看了下,TCP写buffer有数据但是没有满,等了很久也貌似发生不出去,有重传,但是还是传不出去。直接达到rto次数内核中断连接。
    我们只能将rto改很小让内核中断连接。
    请问这种情况一般都是由什么原因引起的呢?

    作者回复: 这个因素比较多,RTO超时说明已经发生来重传,根源上还是要看为什么会发生重传,比如是否有丢包、是否超出了内核中的资源限制或者对端是否有类似的问题等等。这些最好两端抓包对比分析

    2019-02-28
    1
  • 怀特
    traceroute 会在路由的每一跳发送三个包,并在收到响应后,输出往返延时。如果无响应或者响应超时(默认 5s),就会输出一个星号。
    ----这个地方,还有些不明白,希望老师能在这里再解释几句

    作者回复: 就是说星号表示没有收到这一跳的响应

    2019-02-22
    1
  • Magic Star Trace
    请问:物理机centos 7 ,kvm 上虚拟机 丢包不稳定是什么问题导致的呢?
    time 延迟很不稳定

    作者回复: 用本文的思路分析一下,看看有什么发现?

    2019-08-25
  • 阳光梦
    您好,请教下。我通过客户端直接访问服务器,平均响应延迟是30ms,经过nginx代理响应延迟是200ms,我使用的ngx+lua,业务逻辑是先查询worker进程的缓存,没有再查redis,再没有查mysql,现在lua层面可以优化的已经优化了,平均响应延迟还是170ms,不知道通过什么工具能定位具体哪里导致响应延迟慢呢?谢谢!

    作者回复: 试试动态追踪(专栏第50、51篇)怎么样?

    2019-06-24
  • 坤丰
    不考虑磁盘问题,tcpdump 长期在生产环境打开,会有什么不良的影响吗?会影响到网络性能吗?如何去评估这样的问题

    作者回复: 会的,不推荐长期开着

    2019-05-15
  • skye
    那nagle算法用在什么情况下呢?
    2019-05-06
  • 大坏狐狸
    开始懵了。setsocket那里 没找到。。不过 确实nginx的那个nodeplay 为off
    2019-04-11
  • 如果
    DAY40,打卡
    2019-04-08
  • 文中没有说过有什么方法。而且我这是抓包根本看不出什么。只看见重传15次后连接断开。
    我想请教的是,一般什么原因导致重传这么多次还是没有重传成功呢?
    write buffer一直有数据且大小不变,代表数据一直发不出去。
    而TCP心跳在有数据在write buffer情况下是不会发生心跳的。
    2019-03-06
  • 科学Jia
    老师这个案例非常好,受益匪浅,让我决心好好再温习下tcp的基础知识。还是基础最重要。
    2019-03-06
  • 你好,但是每次出问题都要等到重传15次。而且write buffer都不变。
    应该不是简单超时吧。

    作者回复: 嗯,可以用文中的方法分析看看

    2019-03-05
  • 加盐铁论
    打卡,加油💪!
    2019-02-26
收起评论
23
返回
顶部