Linux性能优化实战
倪朋飞
微软资深工程师，Kubernetes项目维护者
立即订阅
23395 人已学习
课程目录
已完结 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性能优化实战
登录|注册
39 | 案例篇：怎么缓解 DDoS 攻击带来的性能下降问题？
倪朋飞 2019-02-20
你好，我是倪朋飞。
上一节，我带你学习了 tcpdump 和 Wireshark 的使用方法，并通过几个案例，带你用这两个工具实际分析了网络的收发过程。碰到网络性能问题，不要忘记可以用 tcpdump 和 Wireshark 这两个大杀器，抓取实际传输的网络包，排查潜在的性能问题。
今天，我们一起来看另外一个问题，怎么缓解 DDoS（Distributed Denial of Service）带来的性能下降问题。
DDoS 简介
DDoS 的前身是 DoS（Denail of Service），即拒绝服务攻击，指利用大量的合理请求，来占用过多的目标资源，从而使目标服务无法响应正常请求。
DDoS（Distributed Denial of Service） 则是在 DoS 的基础上，采用了分布式架构，利用多台主机同时攻击目标主机。这样，即使目标服务部署了网络防御设备，面对大量网络请求时，还是无力应对。
从攻击的原理上来看，DDoS 可以分为下面几种类型。
第一种，耗尽带宽。无论是服务器还是路由器、交换机等网络设备，带宽都有固定的上限。带宽耗尽后，就会发生网络拥堵，从而无法传输其他正常的网络报文。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Linux性能优化实战》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(28)
怀特这个专栏太超值，我跟追剧一样的追到现在，收获已经巨大！
谢谢倪工的分享。
更谢谢倪工对留言一丝不苟的回复---这份对听众的耐心，其他专栏的作者没有一个能比得上的。
继续追剧！作者回复: 哈哈，谢谢热心回复和支持
2019-02-21 12
ichiro最近服务会出现干核现象，一个单进程程序发现把一个cpu耗尽，用top发现一个cpu的，软中断很高，通过watch -d cat /proc/softireq，发现网络中断很高，然后配置多网卡队列，把中断分散到是他cpu，缓解了进程cpu的压力，但同时带来担忧，配置多网卡队列绑定，会不会带来cpu切换，缓存失效等负面影响？另外，老师还有别的建议吗？作者回复: 会的，实际上优化网络都会占用更多的cpu和内存。所以还要看优化是不是值得，是不是最需要优化的瓶颈
2019-02-27 5
李燕平²⁰¹⁸服务器插上网线就像开车上路。
DDoS攻击可以理解为撞车，提升汽车本身的安全系数会有用。
大量DDoS攻击可以理解为撞上大货车，需要护卫车队来保护主车。作者回复: 赞👍
2019-02-20 5
ChristmasSysc backlog并不是在配置了sync cookie之后就失效了吧，netstat -s 看到的listen状态的recv 和send不是分别表示连接队列配置和当前活跃队列长度吗，比如监听某个端口的进程不响应了，那么这里的recv队列就会慢慢变长然后溢出。溢出之后，linux可以选择drop掉什么也不做，或者返回connection reset通知客户端作者回复: 请参考 syn cookie 和 netstat 的文档，这些配置和字段的含义都有明确的说明
2019-03-01 2
明翼检测DDOS攻击，我没有什么这方面经验想了下：
1、既然攻击，肯定不是正常业务，所以在sar -n DEV 4 命令看运行包的时候，不光要注意收到的包的大小，还要注意平时在监控业务的时候观察正常的业务的收包量，做一个横向比较，确定异常流量；还有一点特别重要，我觉得tcp连接交互基本都是双向的，那么回包数量和发包的数量不能相差太大，如果太大了可能有问题。
2、至于查看源IP，除了tcpdump外，是不是可以通过netstat 结合wc 统计下各类状态的连接数，如果连接数超过平时的连接数就要注意，关注状态一致的连接数，这里面也有ip信息，当然也可以判断来源。作者回复: 嗯，sar和netstat都是最常用的工具
2019-02-20 2
且听风吟net.ipv4.tcp_max_tw_buckets
net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle
net.ipv4.tcp_keepalive_time
net.ipv4.tcp_timestamps
期待结合生产环境对这几个内核参数的讲解。目前生产环境下php服务器time_wait特别多，网络包的流程： NGINX代理<——>PHP服务器——>redis/mysql..
高峰时期php服务器一共50k+的连接。49k+的time_wait.， 主要来源是php作为客户端的角色时连接redis、mysql、给代理NGINX回包、php服务器内部调用。希望老师能给解决问题的思路。作者回复: 嗯，后面有的
2019-02-20 2
dancer重新开追，前两天着重看了cpu调优，正好线上压测发现了cpu.user飙高的问题，通过perf和pprof查明了是一个复杂json结构解析导致的，学以致用下来印象更深了！这两天开始看网络，后面再看io和内存相关，感谢！作者回复: 赞，很高兴也看到学以致用
2019-03-06 1
Geek_ea21df老师，咨询个问题，当半连接队列被占满后，客户端继续发syn，这时服务器端还会返回syn+ack吗？由于没有收到客户端返回的ack，半连接队列里面的连接会被踢出吗？2019-10-17
辉晖--rand-source
用tcpdump抓包看到的还是同样的IP呀，没有出现随机2019-10-15
乖，摸摸头
抓包被攻击主机
17:15:09.834282 IP 172.17.0.17.http > 39.105.27.73.25213: Flags [S.], seq 3104982810, ack 1682132320, win 64240, options [mss 1460], length 0
17:15:09.834577 IP 39.105.27.73.25180 > 172.17.0.17.http: Flags [R], seq 1552097248, win 0, length 0
17:15:09.835241 IP 39.105.27.73.25219 > 172.17.0.17.http: Flags [S], seq 1495946800, win 512, length 0
17:15:09.835258 IP 172.17.0.17.http > 39.105.27.73.25219: Flags [S.], seq 4115155724, ack 1495946801, win 64240, options [mss 1460], length 0
17:15:09.835319 IP 39.105.27.73.25215 > 172.17.0.17.http: Flags [S], seq 472764723, win 512, length 0
17:15:09.835333 IP 172.17.0.17.http > 39.105.27.73.25215: Flags [S.], seq 3536954741, ack 472764724, win 64240, options [mss 1460], length 0
17:15:09.837205 IP 39.105.27.73.25190 > 172.17.0.17.http: Flags [R], seq 1357800982, win 0, length 0
抓包发起攻击的主机 好多发起得是[R]
抓包发起攻击的主机
17:17:36.904992 IP 172.17.115.106.5941 > 49.234.232.49.http: Flags [S], seq 399367614, win 512, length 0
17:17:36.906033 IP 172.17.115.106.5942 > 49.234.232.49.http: Flags [S], seq 591134454, win 512, length 0
17:17:36.907112 IP 172.17.115.106.5943 > 49.234.232.49.http: Flags [S], seq 1780793513, win 512, length 0
17:17:36.908170 IP 172.17.115.106.5944 > 49.234.232.49.http: Flags [S], seq 1999407364, win 512, length 0
17:17:36.908471 IP 49.234.232.49.http > 172.17.115.106.5914: Flags [S.], seq 3104468759, ack 1898840089, win 64240, options [mss 1424], length 0
17:17:36.908485 IP 172.17.115.106.5914 > 49.234.232.49.http: Flags [R], seq 1898840089, win 0, length 0
我这个好多都是发起的[R]攻击2019-10-01
峰回您好，请问系统closed飙高，占用大量句柄的原因是什么呢，有解决方案么？2019-06-10- zshanjun我这里dos攻击没有什么效果，我查看了一下被攻击主机的tcp连接状态发现根本就没有多少SYN_REC的状态。
然后通过抓包发现，是攻击主机主动发了【R】，导致被攻击主机的tcp的SYN_REC没有堆积起来：
06:38:15.452913 IP 192.168.38.4.15651 > 192.168.38.5.80: Flags [S], seq 1206198085, win 512, length 0
06:38:15.452930 IP 192.168.38.5.80 > 192.168.38.4.15651: Flags [S.], seq 1729577211, ack 1206198086, win 29200, options [mss 1460], length 0
06:38:15.453009 IP 192.168.38.4.15652 > 192.168.38.5.80: Flags [S], seq 1185838297, win 512, length 0
06:38:15.453033 IP 192.168.38.5.80 > 192.168.38.4.15652: Flags [S.], seq 1389286866, ack 1185838298, win 29200, options [mss 1460], length 0
06:38:15.453132 IP 192.168.38.4.15651 > 192.168.38.5.80: Flags [R], seq 1206198086, win 0, length 0
06:38:15.453141 IP 192.168.38.4.15652 > 192.168.38.5.80: Flags [R], seq 1185838298, win 0, length 0
06:38:15.453384 IP 192.168.38.4.15653 > 192.168.38.5.80: Flags [S], seq 1851454908, win 512, length 0
06:38:15.453406 IP 192.168.38.5.80 > 192.168.38.4.15653: Flags [S.], seq 128486955, ack 1851454909, win 29200, options [mss 1460], length 0
06:38:15.453479 IP 192.168.38.4.15653 > 192.168.38.5.80: Flags [R], seq 1851454909, win 0, length 0
06:38:15.453719 IP 192.168.38.4.15654 > 192.168.38.5.80: Flags [S], seq 700664781, win 512, length 0
06:38:15.453743 IP 192.168.38.5.80 > 192.168.38.4.15654: Flags [S.], seq 3877145682, ack 700664782, win 29200, options [mss 1460], length 0
06:38:15.454017 IP 192.168.38.4.15654 > 192.168.38.5.80: Flags [R], seq 700664782, win 0, length 0
06:38:15.454961 IP 192.168.38.4.15655 > 192.168.38.5.80: Flags [S], seq 1751493720, win 512, length 0
06:38:15.454993 IP 192.168.38.5.80 > 192.168.38.4.15655: Flags [S.], seq 1257904630, ack 1751493721, win 29200, options [mss 1460], length 0
请问这种情况是hping3工具的问题吗？作者回复: 看起来像是被攻击主机配置了防DoS策略
2019-04-12 
大坏狐狸1 增大队列SYN最大半连接数sysctl -w et.ipv4.tcp_max_syn_backlog=3000
2 减少超时值：通过减少超时重传次数，sysctl -w net.ipv4.tcp_synack_retries=1
3 SYN_COOKIE : 开启cookie echo "1" > / proc/sys/net/ipv4/tcp_syncookies （原本对cookie有误解，看了本文才清楚，谢谢老师）
4 过滤可疑IP地址: iptables -I INPUT -s 192.168.0.2 -p tcp -j REJECT 禁止 0.2访问2019-04-11
z.l请问老师今天讲的三个tcp内核参数调优能否作为通用的提高服务器抗并发能力的优化手段？作者回复: 嗯 是的
2019-04-09- 如果DAY39，打卡2019-04-03
Maxwell压测过程中，使用多线程向服务器施压，也算是DDOS攻击吧？作者回复: 看请求量了，很多情况下也算的
2019-03-24
青石REJECT攻击IP所有报文，接口响应没什么变化，还是127秒，DROP报文后响应时间才恢复正常，查了REJECT和DROP的区别，REJECT会返回个ICMP包给源IP，有点不太理解为什么一个ICMP包导致这么大的差异。
# hping3命令, u10效果不明显，所以改成了u1测试
$ hping3 -S -p 80 172.30.81.136 -I eno1 -i u1
# 调整内核参数测试结果，接口响应时间为127秒
$ curl -s -w 'Http code: %{http_code}\nTotal time:%{time_total}s\n' -o /dev/null http://172.30.81.136/
Http code: 000
Total time:127.109s
# 调整内核参数、iptables限制syn并发的测试结果，接口响应时间为127秒
$ curl -s -w 'Http code: %{http_code}\nTotal time:%{time_total}s\n' -o /dev/null http://172.30.81.136/
Http code: 000
Total time:127.106s
# 调整内核参数、iptables限制syn并发、单IP连接数的测试结果，接口响应时间为127秒
$ curl -s -w 'Http code: %{http_code}\nTotal time:%{time_total}s\n' -o /dev/null http://172.30.81.136/
Http code: 000
Total time:127.097s
# 调整内核参数、iptables限制syn并发、单IP连接数、DROP攻击IP所有报文的测试结果，接口响应时间为127秒
$ curl -s -w 'Http code: %{http_code}\nTotal time:%{time_total}s\n' -o /dev/null http://172.30.81.136/
Http code: 200
Total time:0.001s作者回复: REJECT还会给攻击源发送响应，这也是消耗网络资源的；而DROP没有任何回应，直接丢弃
2019-03-17
we老师，如果把tcp 改为sctp 协议，是不是就不会再发生DDos 攻击了？作者回复: 只对SYN Flood有效，但很多针对应用层的DoS应该还是无效的
2019-03-13
Brown羊羊net.ipv4.tcp_max_syn_backlog = 256 改成1024 这个对DDoS攻击无效吧，也不差这几百个连接作者回复: 嗯嗯，对流量型无效；但是可以缓解针对业务的攻击（这种一般请求小但响应大或者处理耗时）
2019-03-10
wj我也按上面的情况去模拟了，但是没有达到能够把服务器刷死的那种效果，请求时间没什么变化作者回复: 我设置的请求数比较保守（虚机性能不是特别好），加大请求试试
2019-03-06
收起评论