调整Linux系统backlog参数能显著降低内存占用吗？
- 内容介绍
- 文章标签
- 相关推荐
在现代 Linux 运维里厮混久了,总会遇到些让人哭笑不得的 "灵异事件":服务器明明没跑什么大程序,Cpu 和磁盘都闲着,but memory usage就是高居不下像被施了魔咒一般查遍进程列表也找不到 "凶手",直到某天翻 /proc/net/tcp 的时候才愕然发现——原来是那个藏在角落的 backlog 参数在偷偷 "吃 memory " !
别笑 ,这真不是夸张说法 .作为一个踩过无数次 " connection timeout " 和 " memory alarm " 坑 的老运 这就说得通了。 维 ,今天必须把 backlog 参数扒个底朝天 :它到底怎么吞 memory ?调整它真能 "显著降 memory "吗 ?且听我慢慢唠 .
一、 先破个谣：Linux 的 backlog ,从来不是单个参数那么简单
提起 backlog ,很多人第一反应就是 "网络连接排队参数嘛",但其实吧 —— 它管着俩 "分工明确 " 的队 太坑了。 列 ,一个叫 SYN 半连接队 ,另一个叫 Accept 全连队 ,这俩才是 memory 的 "隐形吸血鬼 ".
别急着嫌麻烦 ,先给大伙讲个血淋淋的真实案例 :去年双十二前夕 ,我们团队负责的电商支付系统突然集体报 "memory critical ",监控面板上红线直蹦跶 .一开始全员盯着 Java 进程骂 ,后来啊杀了几个 Tomcat 实例之后 ,memory 不降反升 .再说说蹲在服务器跟前逐条查 /proc 文件 ,才发现罪魁祸首是前同事为 "防过载 "私自改大的 tcpmaxsyn_backlog ——从默认的 1024 被拉到了惊人的 8192 !，抓到重点了。
光这个 SYN 半连队 ,就悄摸摸吃掉了近百兆 memory .更坑爹的是 Acce 人间清醒。 pt 队 也被设成了 2048 ,俩队加起来直接干翻了服务器一半空闲 memory .
二、算笔狠账 : backlog 的 memory消耗 ,比你想得多得多
至于吗？ 很多人觉得 "不就是个排队参数吗 ?能吃多少 ?",我当初也是这么天真 ——直到亲手撸起袖子算完这笔账 .
先给大伙科普两个最基础的数据 :
▶️ SYN半连队
存储 尚未完成三次握手 的请求 ,每个条目要保存 :源IP/端口、目标IP/端口、随机娱乐IS N、超时定时器...这些东西加起来大概 占256~512字节.
▶️ Accept全连队
存储 已完成三次握手但还没被应用程序取走 的请求 .这玩意儿可不一样 ——它要保存完整 Socket结构体 :包括收发缓冲区 、 对吧？ TCP状态机上下文、窗口大小...简简单单一条目就能 吃掉100~500KB !
瞅瞅我们之前那个坑爹案例的数据 : bash，呵...
tcpmaxsyn_backog =8192 somaxconn =2048，吃瓜。
SYN队 ≈8192 ×256B ≈2MB Accept队 ≈2048 ×100KB ≈2GB 总消耗 ≈???!(哦不搞错单位勒！应该系约两百零二mb左右啦！！接受列队系二千零四十八乘一百kb等于二百零四点八mb加上syn嘅两mb大概二百零六mb左右！！对哦刚才算错鸟 scare你们一下下～），层次低了。
SYN队 ≈512×7eighty-eight B≈百二十四kb Accept队 ≈千二十四 ×一百kb ≈一百零二点四mb 总消耗≈一百零二点五mb，整一个...
瞧见没 ?光是把 Accept队从两千改到一千 ,memory直接少掉近一倍 !关键在于 —— Accept列队才是 memory大户啊朋友们 !它每一 entry都比 SYN队胖几百倍 !，我懂了。
三､灵魂拷问 :调整 backlodg真能 “显著降memory ”吗 ?答案分三种情况
聊到这儿肯定有人急了 :"那我赶紧把 backlodg调到最小不就完事儿 梳理梳理。 ?!" ——兄弟慢着 !这事得分场景讨论 ,不然分分钟把服务器搞崩给你看 .
❌场景一 : backlodg远大于实际并发 →调完立竿见影
典型例子就是前面说嘅电商双十二惨案 :"业务高峰并发最多也就三千次吧 !前同事偏要设八千防超时 ...".这种情况下 tuning backlodg简直不要太爽 ——直接按 实际峰值× 设置即可,money节省肉眼可见 .，说起来...
操作一波。 像我们后来把 somaXConn从两千砍到一千多一点儿,money使用率直接从7S%跌到S工%,而且业务高峰期连按成功率还维持在99.q%以上完美!.
⚠️场景二 : backlodg刚好覆盖并发 →乱调就是自杀
去年帮某医院做电子病历系统优化时遇见过类似情况 :他们数据库服务器嘅 tcpmqxSyπbaclOg设成一千,symaXConn八百 .査监控发现,syπwait_ 境界没到。 queue几乎每天下午三点都会爆满 .当时技术主管想把 somaXConn调到五百节省 money ...后来啊第二天一大早全院医生都骂街 :"系统登不上啦 !!"
为啥 ?主要原因是下午三点嘅并发峰值高达九百多次 ——somaXConn砍到五百后,"已完成三次握手嘅请求根本排不上号 ",应用程序还没来得及读就被 queue挤掉瞭!后来我们把 somaXConn加到一千二百才稳定下来一边加瞭实时监控脚本每当 syπwaitqueue超过九百就发告警提示提前扩容 .
🚫场景三 : backlodg本来就很小 →再调就是作死
见过不少刚入行嘅小兄弟 :"听说调低 backlodg能省 money我帮公司服务器改一下叭 ~!"后来啊呢 ?某创业公司客服系统原本 tcpmqxSyπ_baclOg=lOo,symaXConn=ZzS .小哥擅自改成 so跟 zo ...没过两天客户反馈 :"微信公众号登不上 "."APP老是闪退 "...原因很简单 :偶爾嘅几十次并发请求都被 queue拒收瞭!
四､平安 tuning指南 :四步走完不踩坑
我整个人都不好了。 说了这么多干货总得教大伙怎么平安操作吧 ?别慌 ~以下四步包你避坑 :
step I :先测实際并發生況！別猜！
别跟我说什么 “感觉业务并发不大”,用工具实打实测最靠谱 : bash
netstat -an | grep SYn_ReCV | wc-l #旧方法兼容所有Linu 他破防了。 x ss -tan state SYn-RCv #新方法更快更準
cat /proc/net/tCP | grep ESTABLISHED | WC-l #近似值 watch -n I 'ss -tan I grep ":soso"|WC-l' #實時監控目標端口
step Z：確定平安閾値→留緩衝！
准确地说... 測完峰值之后記得乘以 l.l ~ l.S作為新參數上限 ——給突發流量留點餘地嘛～比方说峰值 concurrent connections系 sσσσ那麼 tcpmqxSyπ_baclOg設 δσσσ~sσσσ之間,symaXConn設 sσσσ~工σσσ之間剛剛好～
step S：小幅度試錯→別一次砍太狠！
千萬別腦熱一次性減少一半參數 !建議每次減少 Zo%~So%觀察一小時再決定 乱弹琴。 要不要繼續～觀察指標包括 :連接成功率;⑵memory使用率;⑶應用錯誤日志.
step④：持久化配置→重啟不怕失效！
臨時修改 /porc 文件系統屬於 “一次性 ”行為重啟服務器馬上恢復原狀 !必須寫入配置文件才能永久生效呀親～不同系統操作略有差異 :CentOs/Ubuntu編輯/etc/sysctl.conf添加以下內容:;⑵執行sysctl-p讓配置马上生效;.，对，就这个意思。
五､最後想說句掏心窩子話……
作為一個經歷過無數次 “改崩服務器 ”又死撐著修復嘅運維狗真心想對大伙說一句∶ *優化從不是 “為省錢而省錢 ”背lodg參數存在嘅價値昰 “容納突發流量 ”而非 “浪費memory”.所謂 “顯著降低memory ”不過係 “刪除多餘嘅緩衝空間 ”而已若為咗節省這點memory犧牲咗業務穩定性啱好係因小失大!. *，精神内耗。
想起剛入行時候帶俺嘅老師講過一句話∶ “技術優化永遠係門平衡術 ――錢要花喺刀刃上參數要設喺剛好處.”至今銘記於心～
所以下次再想動 backlodg這個參數嘅時候千萬別急先問自己三個問題 ∶⑴你嘅業務真係需要咁大嘅隊列嗎⑵凋整之後會唔會影響連接成功率⑶呢筆 “節省下來嘅memory ”真係值得嗎 ?:
在现代 Linux 运维里厮混久了,总会遇到些让人哭笑不得的 "灵异事件":服务器明明没跑什么大程序,Cpu 和磁盘都闲着,but memory usage就是高居不下像被施了魔咒一般查遍进程列表也找不到 "凶手",直到某天翻 /proc/net/tcp 的时候才愕然发现——原来是那个藏在角落的 backlog 参数在偷偷 "吃 memory " !
别笑 ,这真不是夸张说法 .作为一个踩过无数次 " connection timeout " 和 " memory alarm " 坑 的老运 这就说得通了。 维 ,今天必须把 backlog 参数扒个底朝天 :它到底怎么吞 memory ?调整它真能 "显著降 memory "吗 ?且听我慢慢唠 .
一、 先破个谣：Linux 的 backlog ,从来不是单个参数那么简单
提起 backlog ,很多人第一反应就是 "网络连接排队参数嘛",但其实吧 —— 它管着俩 "分工明确 " 的队 太坑了。 列 ,一个叫 SYN 半连接队 ,另一个叫 Accept 全连队 ,这俩才是 memory 的 "隐形吸血鬼 ".
别急着嫌麻烦 ,先给大伙讲个血淋淋的真实案例 :去年双十二前夕 ,我们团队负责的电商支付系统突然集体报 "memory critical ",监控面板上红线直蹦跶 .一开始全员盯着 Java 进程骂 ,后来啊杀了几个 Tomcat 实例之后 ,memory 不降反升 .再说说蹲在服务器跟前逐条查 /proc 文件 ,才发现罪魁祸首是前同事为 "防过载 "私自改大的 tcpmaxsyn_backlog ——从默认的 1024 被拉到了惊人的 8192 !，抓到重点了。
光这个 SYN 半连队 ,就悄摸摸吃掉了近百兆 memory .更坑爹的是 Acce 人间清醒。 pt 队 也被设成了 2048 ,俩队加起来直接干翻了服务器一半空闲 memory .
二、算笔狠账 : backlog 的 memory消耗 ,比你想得多得多
至于吗？ 很多人觉得 "不就是个排队参数吗 ?能吃多少 ?",我当初也是这么天真 ——直到亲手撸起袖子算完这笔账 .
先给大伙科普两个最基础的数据 :
▶️ SYN半连队
存储 尚未完成三次握手 的请求 ,每个条目要保存 :源IP/端口、目标IP/端口、随机娱乐IS N、超时定时器...这些东西加起来大概 占256~512字节.
▶️ Accept全连队
存储 已完成三次握手但还没被应用程序取走 的请求 .这玩意儿可不一样 ——它要保存完整 Socket结构体 :包括收发缓冲区 、 对吧？ TCP状态机上下文、窗口大小...简简单单一条目就能 吃掉100~500KB !
瞅瞅我们之前那个坑爹案例的数据 : bash，呵...
tcpmaxsyn_backog =8192 somaxconn =2048，吃瓜。
SYN队 ≈8192 ×256B ≈2MB Accept队 ≈2048 ×100KB ≈2GB 总消耗 ≈???!(哦不搞错单位勒！应该系约两百零二mb左右啦！！接受列队系二千零四十八乘一百kb等于二百零四点八mb加上syn嘅两mb大概二百零六mb左右！！对哦刚才算错鸟 scare你们一下下～），层次低了。
SYN队 ≈512×7eighty-eight B≈百二十四kb Accept队 ≈千二十四 ×一百kb ≈一百零二点四mb 总消耗≈一百零二点五mb，整一个...
瞧见没 ?光是把 Accept队从两千改到一千 ,memory直接少掉近一倍 !关键在于 —— Accept列队才是 memory大户啊朋友们 !它每一 entry都比 SYN队胖几百倍 !，我懂了。
三､灵魂拷问 :调整 backlodg真能 “显著降memory ”吗 ?答案分三种情况
聊到这儿肯定有人急了 :"那我赶紧把 backlodg调到最小不就完事儿 梳理梳理。 ?!" ——兄弟慢着 !这事得分场景讨论 ,不然分分钟把服务器搞崩给你看 .
❌场景一 : backlodg远大于实际并发 →调完立竿见影
典型例子就是前面说嘅电商双十二惨案 :"业务高峰并发最多也就三千次吧 !前同事偏要设八千防超时 ...".这种情况下 tuning backlodg简直不要太爽 ——直接按 实际峰值× 设置即可,money节省肉眼可见 .，说起来...
操作一波。 像我们后来把 somaXConn从两千砍到一千多一点儿,money使用率直接从7S%跌到S工%,而且业务高峰期连按成功率还维持在99.q%以上完美!.
⚠️场景二 : backlodg刚好覆盖并发 →乱调就是自杀
去年帮某医院做电子病历系统优化时遇见过类似情况 :他们数据库服务器嘅 tcpmqxSyπbaclOg设成一千,symaXConn八百 .査监控发现,syπwait_ 境界没到。 queue几乎每天下午三点都会爆满 .当时技术主管想把 somaXConn调到五百节省 money ...后来啊第二天一大早全院医生都骂街 :"系统登不上啦 !!"
为啥 ?主要原因是下午三点嘅并发峰值高达九百多次 ——somaXConn砍到五百后,"已完成三次握手嘅请求根本排不上号 ",应用程序还没来得及读就被 queue挤掉瞭!后来我们把 somaXConn加到一千二百才稳定下来一边加瞭实时监控脚本每当 syπwaitqueue超过九百就发告警提示提前扩容 .
🚫场景三 : backlodg本来就很小 →再调就是作死
见过不少刚入行嘅小兄弟 :"听说调低 backlodg能省 money我帮公司服务器改一下叭 ~!"后来啊呢 ?某创业公司客服系统原本 tcpmqxSyπ_baclOg=lOo,symaXConn=ZzS .小哥擅自改成 so跟 zo ...没过两天客户反馈 :"微信公众号登不上 "."APP老是闪退 "...原因很简单 :偶爾嘅几十次并发请求都被 queue拒收瞭!
四､平安 tuning指南 :四步走完不踩坑
我整个人都不好了。 说了这么多干货总得教大伙怎么平安操作吧 ?别慌 ~以下四步包你避坑 :
step I :先测实際并發生況！別猜！
别跟我说什么 “感觉业务并发不大”,用工具实打实测最靠谱 : bash
netstat -an | grep SYn_ReCV | wc-l #旧方法兼容所有Linu 他破防了。 x ss -tan state SYn-RCv #新方法更快更準
cat /proc/net/tCP | grep ESTABLISHED | WC-l #近似值 watch -n I 'ss -tan I grep ":soso"|WC-l' #實時監控目標端口
step Z：確定平安閾値→留緩衝！
准确地说... 測完峰值之后記得乘以 l.l ~ l.S作為新參數上限 ——給突發流量留點餘地嘛～比方说峰值 concurrent connections系 sσσσ那麼 tcpmqxSyπ_baclOg設 δσσσ~sσσσ之間,symaXConn設 sσσσ~工σσσ之間剛剛好～
step S：小幅度試錯→別一次砍太狠！
千萬別腦熱一次性減少一半參數 !建議每次減少 Zo%~So%觀察一小時再決定 乱弹琴。 要不要繼續～觀察指標包括 :連接成功率;⑵memory使用率;⑶應用錯誤日志.
step④：持久化配置→重啟不怕失效！
臨時修改 /porc 文件系統屬於 “一次性 ”行為重啟服務器馬上恢復原狀 !必須寫入配置文件才能永久生效呀親～不同系統操作略有差異 :CentOs/Ubuntu編輯/etc/sysctl.conf添加以下內容:;⑵執行sysctl-p讓配置马上生效;.，对，就这个意思。
五､最後想說句掏心窩子話……
作為一個經歷過無數次 “改崩服務器 ”又死撐著修復嘅運維狗真心想對大伙說一句∶ *優化從不是 “為省錢而省錢 ”背lodg參數存在嘅價値昰 “容納突發流量 ”而非 “浪費memory”.所謂 “顯著降低memory ”不過係 “刪除多餘嘅緩衝空間 ”而已若為咗節省這點memory犧牲咗業務穩定性啱好係因小失大!. *，精神内耗。
想起剛入行時候帶俺嘅老師講過一句話∶ “技術優化永遠係門平衡術 ――錢要花喺刀刃上參數要設喺剛好處.”至今銘記於心～
所以下次再想動 backlodg這個參數嘅時候千萬別急先問自己三個問題 ∶⑴你嘅業務真係需要咁大嘅隊列嗎⑵凋整之後會唔會影響連接成功率⑶呢筆 “節省下來嘅memory ”真係值得嗎 ?: