Linux 性能优化实战
倪朋飞
资深 Linux 专家,Kubernetes 项目维护者
87258 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 65 讲
结束语 (1讲)
Linux 性能优化实战
15
15
1.0x
00:00/00:00
登录|注册

42 | 案例篇:如何优化 NAT 性能?(下)

发现性能问题
ab 测试性能
ab 测试性能
优化解决方法
性能问题定位和分析
性能优化思路
使用 conntrack 查看连接跟踪表内容
调整连接跟踪表参数
使用 perf 进一步分析丢包位置
使用 SystemTap 追踪丢包
使用 NAT 的 Nginx 服务
不使用 NAT 的 Nginx 服务
SystemTap
预先安装工具
机器配置
对网络性能有一定影响
基于内核的连接跟踪模块实现
安全隔离局域网中机器
解决公网 IP 地址短缺问题
重写 IP 数据包的源 IP 或目的 IP
思考
性能问题分析
案例分析
案例准备
Linux 中的 NAT
NAT 技术
如何优化 NAT 性能?

该思维导图由 AI 生成,仅供参考

你好,我是倪朋飞。
上一节,我们学习了 NAT 的原理,明白了如何在 Linux 中管理 NAT 规则。先来简单复习一下。
NAT 技术能够重写 IP 数据包的源 IP 或目的 IP,所以普遍用来解决公网 IP 地址短缺的问题。它可以让网络中的多台主机,通过共享同一个公网 IP 地址,来访问外网资源。同时,由于 NAT 屏蔽了内网网络,也为局域网中机器起到安全隔离的作用。
Linux 中的 NAT ,基于内核的连接跟踪模块实现。所以,它维护每个连接状态的同时,也对网络性能有一定影响。那么,碰到 NAT 性能问题时,我们又该怎么办呢?
接下来,我就通过一个案例,带你学习 NAT 性能问题的分析思路。

案例准备

下面的案例仍然基于 Ubuntu 18.04,同样适用于其他的 Linux 系统。我使用的案例环境是这样的:
机器配置:2 CPU,8GB 内存。
预先安装 docker、tcpdump、curl、ab、SystemTap 等工具,比如
# Ubuntu
$ apt-get install -y docker.io tcpdump curl apache2-utils
# CentOS
$ curl -fsSL https://get.docker.com | sh
$ yum install -y tcpdump curl httpd-tools
大部分工具,你应该都比较熟悉,这里我简单介绍一下 SystemTap 。
SystemTap 是 Linux 的一种动态追踪框架,它把用户提供的脚本,转换为内核模块来执行,用来监测和跟踪内核的行为。关于它的原理,你暂时不用深究,后面的内容还会介绍到。这里你只要知道怎么安装就可以了:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入介绍了如何通过案例环境分析和优化 NAT 性能的相关内容。作者通过使用 SystemTap 和 perf 工具来跟踪内核函数调用,找出性能下降的根源,并通过调整内核参数来优化连接跟踪表的大小,解决 "nf_conntrack: table full" 错误。文章还介绍了如何使用 conntrack 命令行工具来查看连接跟踪表的内容,并通过统计分析来优化性能。最后,作者提出了思考题,鼓励读者分享自己的经验和思路。整体来说,本文内容详实,案例清晰,适合对 NAT 性能优化感兴趣的读者阅读学习。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Linux 性能优化实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(34)

  • 最新
  • 精选
  • 分清云淡
    https://mp.weixin.qq.com/s/VYBs8iqf0HsNg9WAxktzYQ:(多个容器snat时因为搜索本地可用端口(都从1025开始,到找到可用端口并插入到conntrack表是一个非事务并且有时延--第二个插入会失败,进而导致第一个syn包被扔掉的错误,扔掉后重传找到新的可用端口,表现就是时延偶尔为1秒或者3秒) 这篇文章是我见过诊断NAT问题最专业的,大家要多学习一下里面的思路和手段

    作者回复: 👍 谢谢分享。内核问题的分析和排查一般都比较耗时间,对基础知识的要求也会高一些。

    2019-03-01
    47
  • 腾达
    这个案例,能不能讲讲怎么找到是NAT问题?这个很关键,但文章里直接点明说是NAT问题,这个就不好了,一般看cpu,看其他指标很难想到是nat问题,真实场景里,怎么会想到是nat问题呢?

    作者回复: 嗯嗯,是个好问题。下一模块中有内核线程的分析思路,到时候可以看到分析的方法

    2019-03-01
    11
  • vvccoe
    ‘# 连接跟踪对象大小为 376,链表项大小为 16 nf_conntrack_max* 连接跟踪对象大小 +nf_conntrack_buckets* 链表项大小 = 1000*376+65536*16 B = 1.4 MB’ 老师 上面的376和16 是固定值吗?

    作者回复: 这是内核数据结构的大小,一般不会变化

    2019-02-27
    3
    9
  • Geek_007
    老师你好,有两个问题想请教一下。 第一点,了解到ip_conntrack模块既然会限制链接,且调大会导致占用内存,而且调大了也不一定能解决大流量服务器的网络性能问题,我理解是不是应该关掉ip_conntrack模块,因为业务服务器按理说是不需要状态追踪的。 第二点,如果我关掉ip_conntrack,会不会因为我执行iptables命令导致该模块被加载,或者执行conntrack命令导致模块被加载。。

    作者回复: 1. 有很多服务是依赖conntrack的,所以要看实际需求确定 2. 要看iptables规则是不是用到了conntrack功能

    2019-04-10
    2
    7
  • 无名老卒
    很惊讶,之前在线上环境中就出现了kernel: nf_conntrack: table full, dropping packet.的报错,当时就认为是conntrack_max导致的,后面调整了这个值之后就恢复了,但其实那次故障也不应该会加载nf_conntrack模块,因为iptables规则只是设置了几个IP允许登陆服务器,当时也不清楚为什么会去加载这个模块了。 同时,conntrack_max和conntrack_buckets有没有什么联系呢?从描述中,感觉conntrack_buckets应该要大于conntrack_max才对,但实际 上不是这样,请老师解惑下。

    作者回复: 应该是反过来,nf_conntrack_max是最大连接跟踪数,nf_conntrack_buckets是连接跟踪表(哈希表)大小。哈希表最大也就是最大连接跟踪数

    2019-05-01
    2
    5
  • 我来也
    [D42打卡] 今天的内容只能围观了. 居然还用了内核动态追踪工具,统计丢包位置. 对于我这种完全不了解内核的人来说, 只当是开了眼界. 对于我来说,目前知道 NAT会带来性能损耗 就行了.🤦‍♀️ 能避免就避免使用,不能避免了就在请求数较多的场景下调些参数. `# 连接跟踪对象大小为 376,链表项大小为 16` 这应该是c结构体的大小吧.

    作者回复: 是的

    2019-02-27
    4
  • aliuql
    老师你好,docker,是不是必然会用到dnat的端口映射?linux服务器内 nat本身应该也有流量限制吧!

    作者回复: 不一定,比如使用hostnetwork就会直接使用host的网络。NAT支持流量限制,不过需要额外的配置

    2019-07-31
    1
  • Goal
    nf_conntrack_buckets 和 nf_conntrack_max 从文中的描述没有搞清楚, 我们只是调整了 nf_conntrack_max(最大连接跟踪数),那么,这个连接是记录在 nf_conntrack_buckets(连接跟踪表)中的吗?,那是否意味着,调整max的同时,也得调整buckets表的大小?

    作者回复: 可以只调整一个,不过要记得这两个参数一起决定了连接跟踪表的结构,这是一个哈希表,两者相除表示冲突的程度。

    2019-06-09
    1
  • Maxwell
    请问这个错误是什么原因导致的呢? root@maxwell-virtual-machine:/usr/bin/env# stap --all-modules dropwatch.stp semantic error: while resolving probe point: identifier 'kernel' at dropwatch.stp:18:7 source: probe kernel.trace("kfree_skb") { locations[$location] <<< 1 } ^ semantic error: no match Pass 2: analysis failed. [man error::pass2] Tip: /usr/share/doc/systemtap/README.Debian should help you get started.

    作者回复: 可能是debuginfo跟内核版本不一致

    2019-03-24
    3
    1
  • 夜空中最亮的星
    以前只是知道net性能不好,今天通过老师的讲解彻底明白了来龙去脉。 公司内部上网用的就是net 人一多就特别慢。 业务基本上没用过net。

    作者回复: NAT,不是net😊

    2019-02-27
    1
收起评论
显示
设置
留言
34
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部