前一陣折騰一臺(tái)線上Linux服務(wù)器剛接手時(shí)負(fù)載常年穩(wěn)定在十幾接口響應(yīng)動(dòng)不動(dòng)就飄到秒級(jí)。經(jīng)過一輪Linux系統(tǒng)性能優(yōu)化從CPU、內(nèi)存、磁盤到網(wǎng)絡(luò)棧都過了一遍最后把問題收斂到幾個(gè)具體的瓶頸點(diǎn)上整個(gè)過程值得完整復(fù)盤一遍。這篇文章適合兩類人看一類是剛?cè)腴T、拿到一臺(tái)“有點(diǎn)卡”的Linux服務(wù)器不知道從哪里下手的同學(xué)另一類是已經(jīng)會(huì)看top和free但面對(duì)千奇百怪的優(yōu)化建議不知道哪些該信、哪些是坑的老手。我會(huì)先把排查思路講清楚再按子系統(tǒng)逐個(gè)拆解優(yōu)化手段最后附上我在實(shí)戰(zhàn)里踩過的坑和最終沉淀下來的參數(shù)基線。整篇內(nèi)容偏實(shí)戰(zhàn)命令都是我在終端里敲過的可以放心對(duì)照自己的環(huán)境試。1. 先定位瓶頸再動(dòng)手性能排查的思路與工具1.1 別被表象帶偏先看全局再看局部接手一臺(tái)性能有問題的服務(wù)器最忌諱的事情就是直接抄網(wǎng)上的優(yōu)化參數(shù)一頓改。我見過不少同事上來就說“CPU滿了”然后趕緊給進(jìn)程調(diào)nice、改調(diào)度器折騰半天負(fù)載紋絲不動(dòng)。后來用iostat一看磁盤在大量同步寫CPU的sys時(shí)間全耗在等待IO完成上改CPU參數(shù)當(dāng)然沒用。所以說第一步永遠(yuǎn)是全局觀察至少持續(xù)10到30分鐘。如果問題是偶發(fā)的這個(gè)間隔要拉得更長最好配合歷史監(jiān)控?cái)?shù)據(jù)一起看。核心命令就這幾個(gè)top看CPU和負(fù)載vmstat看內(nèi)存、上下文切換和IO等待iostat看磁盤sar看歷史趨勢(shì)。別小看這些老命令它們輸出的每一列都是長期沉淀下來的標(biāo)準(zhǔn)指標(biāo)比花里胡哨的監(jiān)控面板靠譜得多。實(shí)際操作的時(shí)候我習(xí)慣并行開幾個(gè)窗口或者用一條命令把關(guān)鍵指標(biāo)一次性收集下來。比如遇到一次線上抖動(dòng)我會(huì)這樣跑vmstat 1 10 iostat -x 1 5 pidstat -u -r -d 1 5 sar -n DEV 1 5這樣做的目的是讓CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)四個(gè)維度的數(shù)據(jù)在同一個(gè)時(shí)間窗口內(nèi)對(duì)齊。如果只單獨(dú)看某一個(gè)指標(biāo)很容易把相關(guān)關(guān)系誤判成因果關(guān)系。等下一輪問題復(fù)現(xiàn)時(shí)至少有完整的數(shù)據(jù)能回看不至于拍腦袋。1.2 一張速查表幫你快速判斷瓶頸方向判斷瓶頸方向這件事本質(zhì)上就是做排除法。我在大量實(shí)戰(zhàn)里總結(jié)出一張速查表遇到問題先對(duì)著看能省下不少彎路的功夫現(xiàn)象可能的瓶頸下一步確認(rèn)工具所有核的us都很高純計(jì)算密集或出現(xiàn)死循環(huán)perf top / top 排序看進(jìn)程單個(gè)核打滿其余空閑線程綁定或中斷分配不均pidstat -t 看線程檢查tasksetsy高且上下文切換劇烈鎖競爭、系統(tǒng)調(diào)用過于頻繁vmstat的cs列strace -cwa高磁盤IO瓶頸iostat -x 看await與utilswap持續(xù)增長內(nèi)存不足free -h查看匿名頁回收情況st高宿主機(jī)CPU超賣虛擬化環(huán)境聯(lián)系虛擬化平臺(tái)確認(rèn)網(wǎng)絡(luò)重傳率高緩沖區(qū)不足或鏈路質(zhì)量差sar -n EDEV, netstat -s這張表不是萬能藥但能幫你快速鎖定大方向。值得注意的是真實(shí)場景里往往是多個(gè)瓶頸疊加比如內(nèi)存不足會(huì)引發(fā)swapswap又加劇磁盤IO最后表現(xiàn)為load average飆升。所以排查時(shí)要把“現(xiàn)象—瓶頸—觸發(fā)鏈”串起來看而不是單點(diǎn)下結(jié)論。1.3 日常監(jiān)控比臨時(shí)救火更重要很多性能問題在發(fā)生之前是有預(yù)兆的只是沒人記錄到了爆發(fā)那一刻才手忙腳亂。我強(qiáng)烈建議在生產(chǎn)環(huán)境裝好sysstat配置定時(shí)采集讓數(shù)據(jù)每天自動(dòng)落盤# Debian/Ubuntu apt install sysstat # RHEL/CentOS yum install sysstat裝好后確認(rèn) /etc/cron.d/sysstat 里的采集間隔是10分鐘或更短然后用 sar -q、sar -u、sar -r、sar -b、sar -n DEV 回看歷史。遇到問題先翻案發(fā)現(xiàn)場而不是干等復(fù)現(xiàn)這能讓你在排查時(shí)多出幾雙眼睛。這也是我處理線上問題的一貫思路監(jiān)控先行優(yōu)化跟上。2. CPU與調(diào)度優(yōu)化從使用率到上下文切換2.1 CPU使用率高不等于負(fù)載高這兩個(gè)概念必須分清CPU使用率是“CPU有多長時(shí)間在忙”負(fù)載是“有多少進(jìn)程處于可運(yùn)行或不可中斷狀態(tài)”。單核機(jī)器上load average為1意味著滿載4核機(jī)器load average為4才意味著所有核打滿。很多初學(xué)優(yōu)化的朋友一看load超過1就緊張其實(shí)在4核機(jī)器上load 2.5是相當(dāng)健康的水平。更迷惑人的是D狀態(tài)進(jìn)程。不可中斷睡眠的進(jìn)程會(huì)一直計(jì)入負(fù)載但它的CPU使用率是0。所以你會(huì)看到一種情況load average已經(jīng)飆到8但top里CPU的us、sy都只有個(gè)位數(shù)vmstat里的wa也不高。這時(shí)候優(yōu)先排查的不是CPU參數(shù)而是哪個(gè)進(jìn)程卡在IO上了。ps -eo state,pid,wchan:32,cmd | grep ^D這條命令列出所有D狀態(tài)進(jìn)程和它們?cè)趦?nèi)核里等待的內(nèi)核函數(shù)?？吹?wchan 那一列基本就知道卡在什么類型的IO上了是等塊設(shè)備、等NFS還是等內(nèi)存頁回寫心里大概有數(shù)。2.2 上下文切換高鎖競爭和系統(tǒng)調(diào)用的鍋上下文切換本身不是壞事但如果每秒切換次數(shù)高到離譜CPU時(shí)間就大量耗在“換人”上而不是“干活”上?？磛mstat輸出的cs列如果持續(xù)超過幾萬甚至十幾萬就該用pidstat定位到底是誰在頻繁切換。pidstat -w 1 5關(guān)注兩列cswch/s是自愿切換nvcswch/s是非自愿切換。自愿切換多說明線程在等鎖、等IO、頻繁睡眠喚醒非自愿切換多說明時(shí)間片耗盡被強(qiáng)制讓出CPU往往是線程數(shù)開太多或者調(diào)度器參數(shù)不合適。定位到進(jìn)程后用perf record抓調(diào)用棧perf record -g -p pid -- sleep 10 perf report如果是鎖競爭火焰圖里會(huì)看到明顯的鎖函數(shù)熱點(diǎn)如果是系統(tǒng)調(diào)用風(fēng)暴strace -c 統(tǒng)計(jì)出的syscall分布會(huì)告訴你答案。這一套組合拳下來90%的CPU異常都能找到根因。2.3 調(diào)度器參數(shù)別亂調(diào)適合場景才是關(guān)鍵Linux的CFS調(diào)度器有幾個(gè)常見參數(shù)我簡單說一下適用場景# 查看當(dāng)前值 sysctl kernel.sched_min_granularity_ns sysctl kernel.sched_wakeup_granularity_ns sysctl kernel.sched_migration_cost_nssched_min_granularity_ns是每個(gè)進(jìn)程獲得CPU時(shí)間片的最小粒度默認(rèn)值通常在幾毫秒量級(jí)。把它調(diào)大減少頻繁切換適合跑大規(guī)模計(jì)算任務(wù)調(diào)小則讓CPU時(shí)間更均勻地分配給每個(gè)進(jìn)程交互體驗(yàn)更跟手適合桌面或低延遲服務(wù)。sched_wakeup_granularity_ns控制被喚醒進(jìn)程能否搶占當(dāng)前進(jìn)程調(diào)大可以避免頻繁搶占導(dǎo)致的抖動(dòng)但也會(huì)讓喚醒延遲變高。我的建議是非必要不調(diào)調(diào)度器參數(shù)?，F(xiàn)代內(nèi)核的默認(rèn)調(diào)度策略在大多數(shù)場景下已經(jīng)很合理盲改只會(huì)把系統(tǒng)弄得更糟。如果確實(shí)要調(diào)一次只能改一個(gè)參數(shù)對(duì)照壓測(cè)數(shù)據(jù)確認(rèn)收益改完留足觀察期。2.4 綁核與中斷親和性給關(guān)鍵進(jìn)程騰出專屬CPUNUMA架構(gòu)普及之后CPU訪問本地內(nèi)存和遠(yuǎn)端內(nèi)存的延遲差距能達(dá)到幾十納秒甚至更多。對(duì)延遲敏感的應(yīng)用綁核是性價(jià)比很高的優(yōu)化手段。用taskset把進(jìn)程綁定到指定CPU核可以避免線程在不同核之間遷移帶來的緩存失效。# 將進(jìn)程綁定到CPU 0和1 taskset -pc 0,1 pid # 啟動(dòng)時(shí)直接綁定 taskset -c 0,1 ./your_app如果物理機(jī)是NUMA架構(gòu)numactl比taskset更精細(xì)可以同時(shí)綁定CPU節(jié)點(diǎn)和內(nèi)存節(jié)點(diǎn)numactl --cpunodebind0 --membind0 ./your_app綁核的副作用也不小當(dāng)綁定的核被占滿任務(wù)只能排隊(duì)等待即使其他核空閑也無法利用。所以綁核只適合明確知道資源需求的場景比如把網(wǎng)卡中斷、某個(gè)核心線程、關(guān)鍵業(yè)務(wù)進(jìn)程分別放到不同的核上互不干擾。一般性的Web服務(wù)反而不要綁死讓內(nèi)核調(diào)度器自由調(diào)度會(huì)更靈活。3. 內(nèi)存優(yōu)化從swap到大頁的取舍3.1 看懂free輸出buff/cache不是你想的那樣很多新人看free -h只盯著used那一列一看內(nèi)存用了90%就開始慌。其實(shí)Linux的內(nèi)存管理哲學(xué)是“空閑內(nèi)存不如拿來緩存”。buff/cache占用的內(nèi)存在應(yīng)用需要時(shí)可以隨時(shí)回收不應(yīng)該簡單理解成“被吃掉了”。真正需要關(guān)注的是available這一列它代表“在不觸發(fā)swap的前提下還能分配給新進(jìn)程的內(nèi)存總量”。我見過不少服務(wù)器free里used高達(dá)95%但available依然充裕系統(tǒng)跑得穩(wěn)穩(wěn)當(dāng)當(dāng)。如果你判斷內(nèi)存是否充足只看used遲早會(huì)被自己嚇出心臟病。判斷內(nèi)存壓力的核心指標(biāo)是swap的使用趨勢(shì)。如果swap的si和so列長期不為零說明系統(tǒng)確實(shí)在頻繁換入換出這時(shí)候才是真正需要考慮內(nèi)存擴(kuò)容或優(yōu)化內(nèi)存使用的信號(hào)。3.2 swappiness不是越大越好也不是越小越好vm.swappiness控制內(nèi)核回收匿名頁進(jìn)程堆棧與頁緩存文件緩存的傾向性。取值范圍在舊內(nèi)核是0到100新內(nèi)核已經(jīng)擴(kuò)展到0到200默認(rèn)60。數(shù)值越高越傾向于回收匿名頁也就是把進(jìn)程內(nèi)存往swap里寫數(shù)值越低越傾向于回收頁緩存。對(duì)數(shù)據(jù)庫、緩存中間件這類內(nèi)存敏感的服務(wù)常見建議是把swappiness調(diào)低讓內(nèi)核優(yōu)先回收文件緩存而不是進(jìn)程內(nèi)存sysctl -w vm.swappiness10 echo vm.swappiness 10 /etc/sysctl.conf調(diào)低之后最直接的效果是進(jìn)程的內(nèi)存頁不容易被換出訪問延遲更穩(wěn)定。但我踩過的坑是有人把swappiness直接設(shè)成0以為這樣就徹底禁用swap了。實(shí)際上0只是“極端避免匿名頁換出”不代表完全不換。只要內(nèi)存壓力到一定程度內(nèi)核依然會(huì)觸發(fā)swap。反過來也別輕易調(diào)高swappiness除非你明確知道自己在做什么。有些場景下把不常用的進(jìn)程內(nèi)存換出給頁緩存騰出更多空間反而能提升整體吞吐——但這需要非常謹(jǐn)慎的壓測(cè)驗(yàn)證。3.3 dirty頁參數(shù)寫緩存是把雙刃劍Linux會(huì)把寫操作先緩沖到內(nèi)存的dirty頁里再由后臺(tái)線程刷到磁盤。vm.dirty_ratio和vm.dirty_background_ratio這兩個(gè)參數(shù)控制刷盤時(shí)機(jī)dirty_background_ratio后臺(tái)刷盤線程啟動(dòng)的閾值默認(rèn)10%達(dá)到這個(gè)值內(nèi)核開始異步寫回不阻塞應(yīng)用。dirty_ratio進(jìn)程自身強(qiáng)制同步寫回的閾值默認(rèn)20%達(dá)到這個(gè)值所有寫操作都要等刷盤完成才能繼續(xù)相當(dāng)于瞬間寫停頓。把這兩個(gè)值調(diào)大能顯著提升大量小文件寫入場景的吞吐量因?yàn)楦鄬懭氡缓喜⒌絻?nèi)存里。但代價(jià)是斷電或內(nèi)核崩潰時(shí)丟失數(shù)據(jù)的窗口從幾秒變成幾十秒。我一般建議dirty_background_ratio控制在10到15之間dirty_ratio控制在20到30之間除非你做了電池備份或?qū)?shù)據(jù)丟失不敏感否則不要為了性能犧牲一致性。3.4 透明大頁看似美好實(shí)際是數(shù)據(jù)庫服務(wù)的痛點(diǎn)透明大頁THP是Linux內(nèi)核的“自動(dòng)大頁化”機(jī)制把物理內(nèi)存自動(dòng)聚合為2MB的大頁理論上能減少TLB miss。但是它的后臺(tái)內(nèi)存規(guī)整過程會(huì)引入延遲尖刺對(duì)延遲敏感的應(yīng)用極不友好。我優(yōu)化過的數(shù)據(jù)庫類服務(wù)幾乎無一例外在關(guān)閉THP后延遲穩(wěn)定性都明顯改善# 臨時(shí)關(guān)閉 echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag # 永久關(guān)閉在 /etc/default/grub 的 GRUB_CMDLINE_LINUX 中添加 transparent_hugepagenever關(guān)閉之后數(shù)據(jù)庫寫入和內(nèi)存分配的長尾延遲下降非常明顯。但如果你跑的是數(shù)值計(jì)算、科學(xué)仿真這類對(duì)內(nèi)存帶寬敏感的任務(wù)THP反而可能是正向收益。所以我對(duì)THP的結(jié)論是默認(rèn)狀態(tài)下建議關(guān)掉除非你用量化數(shù)據(jù)證明它對(duì)你當(dāng)前負(fù)載有幫助。4. 磁盤IO優(yōu)化調(diào)度器、掛載參數(shù)與回寫策略4.1 iostat的高階讀法%util高不代表磁盤極限iostat -x 1的輸出里%util是最常被誤解的指標(biāo)。很多人看到%util接近100%就斷言磁盤滿了其實(shí)%util反映的是采樣周期內(nèi)設(shè)備“有請(qǐng)求待處理”的時(shí)間占比不代表設(shè)備的實(shí)際吞吐能力。NVMe固態(tài)盤隨便就能跑到好幾個(gè)GB/s的讀寫速度%util到100%也不代表性能到頂因?yàn)樗澈笫菢O高的并發(fā)隊(duì)列深度。真正要看的指標(biāo)是await平均IO請(qǐng)求處理時(shí)間和aqu-sz平均隊(duì)列深度。如果await很高說明單個(gè)請(qǐng)求排隊(duì)等待時(shí)間長可能是磁盤硬件跟不上也可能是文件系統(tǒng)鎖、cgroup的IO限制在作怪。我遇到過一臺(tái)機(jī)器%util只有30%w_await卻到了500多毫秒最后排查下來是cgroup的blkio限流導(dǎo)致寫請(qǐng)求在隊(duì)列里排隊(duì)而不是磁盤本身的問題。4.2 IO調(diào)度器機(jī)械盤和固態(tài)的完全相反的選擇Linux的IO調(diào)度器有多個(gè)流派選擇完全取決于底層存儲(chǔ)介質(zhì)# 查看當(dāng)前調(diào)度器 cat /sys/block/sda/queue/scheduler # 修改調(diào)度器以改為none為例 echo none /sys/block/sda/queue/scheduler傳統(tǒng)機(jī)械硬盤強(qiáng)烈推薦deadline或mq-deadline它會(huì)對(duì)讀請(qǐng)求做優(yōu)先級(jí)排序減少磁頭來回尋道的浪費(fèi)。固態(tài)硬盤和NVMe盤推薦none也就是直通模式因?yàn)樵O(shè)備自己已經(jīng)有很好的請(qǐng)求合并和排序能力內(nèi)核再排一次序純屬畫蛇添足。千萬別在NVMe盤上繼續(xù)用cfq那是古董時(shí)期針對(duì)機(jī)械盤設(shè)計(jì)的調(diào)度器在多隊(duì)列時(shí)代早已被廢棄。新內(nèi)核的默認(rèn)調(diào)度策略通常會(huì)識(shí)別NVMe并自動(dòng)選擇none但如果你從舊版本升級(jí)上來還是手動(dòng)確認(rèn)一遍比較穩(wěn)妥。4.3 noatime一個(gè)零成本但收益實(shí)在的掛載選項(xiàng)Linux默認(rèn)的atime特性每次讀取文件都要更新訪問時(shí)間戳這對(duì)大量讀操作來說是純粹的浪費(fèi)。每次讀文件都要觸發(fā)一次元數(shù)據(jù)寫回長期積累下來的開銷相當(dāng)可觀。推薦在文件系統(tǒng)掛載時(shí)加上noatime尤其是日志、靜態(tài)文件、圖片資源這類讀多寫少的場景# /etc/fstab 示例 /dev/sdb1 /data ext4 defaults,noatime,nodelalloc,commit60 0 2如果不想承擔(dān)任何atime丟失的風(fēng)險(xiǎn)relatime是折中方案atime只在mtime或ctime變化時(shí)更新或者距離上次更新超過一天才更新?，F(xiàn)代Linux發(fā)行版默認(rèn)就是relatime但很多服務(wù)器從舊版本升級(jí)過來還是老的atime配置這點(diǎn)值得檢查一下。4.4 文件系統(tǒng)日志與回寫commit調(diào)大要付出數(shù)據(jù)安全代價(jià)ext4和xfs都支持日志journal目的是保證崩潰一致性。日志刷盤頻率由commit參數(shù)控制默認(rèn)是5秒意味著每5秒強(qiáng)制把日志和數(shù)據(jù)落盤一次。調(diào)大commit窗口比如commit600可以減少高頻寫入場景下的刷盤次數(shù)顯著降低IO壓力。但這件事要算清楚代價(jià)commit600意味著系統(tǒng)異常斷電時(shí)最多可能丟失最近10分鐘的數(shù)據(jù)而不是默認(rèn)的5秒。這已經(jīng)不只是性能優(yōu)化而是數(shù)據(jù)安全策略的調(diào)整。我只有在日志類、臨時(shí)緩存類數(shù)據(jù)的存儲(chǔ)上才會(huì)把commit調(diào)大到60以上核心數(shù)據(jù)庫永遠(yuǎn)不會(huì)這么干。4.5 我看到過的“假磁盤瓶頸”隊(duì)列排滿但設(shè)備空閑有一次壓測(cè)時(shí)發(fā)現(xiàn)w_await飆升iostat顯示aqu-sz隊(duì)列深度已經(jīng)到幾十但%util只有40%左右。排查方向一開始鎖定在磁盤硬件后來用blktrace一追發(fā)現(xiàn)是文件系統(tǒng)層面的鎖在排隊(duì)——ext4的某個(gè)日志操作變成了串行瓶頸。這種情況下光調(diào)整IO調(diào)度器或者換更快的SSD都解決不了問題。需要從文件系統(tǒng)掛載選項(xiàng)比如改成datawriteback、內(nèi)核日志模式j(luò)ournal_async_commit、或者干脆換文件系統(tǒng)層面重新設(shè)計(jì)存儲(chǔ)方案來徹底解決。這個(gè)案例給我的教訓(xùn)是指標(biāo)異常時(shí)別急著下結(jié)論把IO路徑上的每一層都排查清楚再動(dòng)手。5. 網(wǎng)絡(luò)棧優(yōu)化隊(duì)列、緩沖與內(nèi)核參數(shù)的合理姿勢(shì)5.1 多隊(duì)列網(wǎng)卡與中斷分散讓每個(gè)CPU都參與收包網(wǎng)卡收包時(shí)如果所有中斷都落在同一個(gè)CPU核上這個(gè)核會(huì)成為瓶頸其他核閑著?，F(xiàn)代網(wǎng)卡支持多隊(duì)列和RSSReceive Side Scaling可以把不同隊(duì)列的收包中斷分散到不同CPU核上# 查看網(wǎng)卡支持隊(duì)列數(shù) ethtool -l eth0 # 開啟多隊(duì)列 ethtool -L eth0 combined 4如果網(wǎng)卡不支持多隊(duì)列或者跑在虛擬化環(huán)境里可以用RPSReceive Packet Steering讓內(nèi)核把收到的包軟件層分發(fā)到多個(gè)CPU核echo ffff /sys/class/net/eth0/queues/rx-0/rps_cpus echo 2 /sys/class/net/eth0/queues/rx-0/rps_flow_cnt這里的ffff是CPU掩碼表示分發(fā)到前16個(gè)CPU核。RPS適合小包高并發(fā)的場景大包傳輸場景收益有限。啟用后要用sar -n DEV觀察軟中斷分布是否均勻避免引入新的緩存親和性開銷。5.2 網(wǎng)絡(luò)內(nèi)核參數(shù)圍繞連接生命周期逐項(xiàng)看網(wǎng)絡(luò)相關(guān)的內(nèi)核參數(shù)特別多我這里只列幾個(gè)高頻使用且可控性強(qiáng)的按我實(shí)際調(diào)整的經(jīng)驗(yàn)逐項(xiàng)說明參數(shù)作用我的建議net.core.somaxconnlisten隊(duì)列上限默認(rèn)128高并發(fā)服務(wù)建議設(shè)4096但要與應(yīng)用層listen backlog匹配net.ipv4.tcp_max_syn_backlogSYN半連接隊(duì)列長度抗SYN泛洪時(shí)調(diào)大一般8192夠用net.core.netdev_max_backlog協(xié)議棧接收隊(duì)列長度網(wǎng)卡突發(fā)流量大時(shí)調(diào)大建議8192net.ipv4.ip_local_port_range主動(dòng)連接可用的臨時(shí)端口范圍短連接多的服務(wù)建議擴(kuò)到1024-65535net.core.rmem_max / wmem_maxsocket緩沖區(qū)上限大流量傳輸時(shí)影響吞吐可調(diào)大到16MBnet.ipv4.tcp_fin_timeoutFIN_WAIT_2狀態(tài)超時(shí)默認(rèn)60秒短連接場景可調(diào)小到30秒給出一段我常用的基礎(chǔ)配置cat /etc/sysctl.conf EOF net.core.somaxconn 4096 net.ipv4.tcp_max_syn_backlog 8192 net.core.netdev_max_backlog 8192 net.ipv4.ip_local_port_range 1024 65535 net.core.rmem_max 16777216 net.core.wmem_max 16777216 net.ipv4.tcp_fin_timeout 30 EOF sysctl -p這些參數(shù)的共性邏輯就一句話把內(nèi)核的瓶頸從“默認(rèn)保守的緩沖區(qū)大小”里釋放出來讓連接建立和傳輸效率匹配上層應(yīng)用的并發(fā)模型。但參數(shù)不是越大越好比如socket緩沖區(qū)調(diào)得過大在長肥網(wǎng)絡(luò)中反而導(dǎo)致延遲不穩(wěn)定。每一個(gè)改動(dòng)都需要壓測(cè)驗(yàn)證。5.3 驗(yàn)證網(wǎng)絡(luò)優(yōu)化的效果重傳率與連接隊(duì)列是關(guān)鍵優(yōu)化完網(wǎng)絡(luò)參數(shù)不要只看帶寬有沒有跑滿更要看連接質(zhì)量指標(biāo)。我常用的驗(yàn)證命令# 查看網(wǎng)絡(luò)吞吐、丟包、重傳 sar -n DEV,EDEV 1 5 # 查看TCP連接狀態(tài)分布 ss -s # 查看具體重傳統(tǒng)計(jì) netstat -s | grep -i retrans重傳率上升說明網(wǎng)絡(luò)包在鏈路上丟失或者接收緩沖區(qū)太小導(dǎo)致內(nèi)核直接丟棄。如果重傳集中在某一個(gè)連接上多半是應(yīng)用層的問題如果全局重傳率都高先檢查網(wǎng)卡丟包統(tǒng)計(jì)再檢查socket緩沖區(qū)設(shè)置。網(wǎng)絡(luò)性能優(yōu)化的目標(biāo)不是“參數(shù)拉滿”而是讓重傳率和丟包率降到合理范圍同時(shí)延遲穩(wěn)定。6. 常見問題排查實(shí)錄與誤區(qū)盤點(diǎn)6.1 場景一load average居高不下但CPU和內(nèi)存都“正?！边@是我在前一家公司遇到的真實(shí)問題。某天監(jiān)控報(bào)警load average飆到20看top和free一切都很正常CPU usage不高內(nèi)存也充足。用ps排查后發(fā)現(xiàn)了十幾個(gè)D狀態(tài)的進(jìn)程全部卡在NFS掛載目錄上原因是網(wǎng)絡(luò)存儲(chǔ)所在的交換機(jī)出了故障。排查D狀態(tài)進(jìn)程還有一個(gè)隱藏技巧直接看 /proc/ /stack內(nèi)核棧會(huì)顯示進(jìn)程阻塞的內(nèi)核函數(shù)。如果是NFS棧里會(huì)有nfs_*相關(guān)的函數(shù)如果是本地磁盤會(huì)有ext4或scsi相關(guān)的函數(shù)。這個(gè)信息比wchan更精確定位問題的速度快得多。解決問題之后這張服務(wù)器的性能問題徹底消失因?yàn)楦驂焊辉诜?wù)器本身。6.2 場景二關(guān)閉THP后延遲從抖動(dòng)變穩(wěn)定某次優(yōu)化一個(gè)內(nèi)存分配極其頻繁的服務(wù)壓測(cè)時(shí)長尾延遲經(jīng)常飆到幾百毫秒P99完全沒法看。用perf分析后發(fā)現(xiàn)大量時(shí)間耗在內(nèi)核的頁面規(guī)整邏輯上罪魁禍?zhǔn)渍峭该鞔箜摰淖詣?dòng)規(guī)整功能。關(guān)閉THP并禁用defrag之后長尾延遲直接降了一個(gè)數(shù)量級(jí)從最高700多毫秒降到30毫秒以內(nèi)。不過換一臺(tái)純計(jì)算型任務(wù)的服務(wù)關(guān)閉THP沒有任何可觀測(cè)的收益反而因?yàn)轫摫眄?xiàng)變多導(dǎo)致TLB miss增加性能小幅回退。這個(gè)案例說明同一個(gè)優(yōu)化手段在不同負(fù)載模型下效果可能完全相反移植經(jīng)驗(yàn)之前一定要先在自己的環(huán)境里做對(duì)照實(shí)驗(yàn)。6.3 場景三sysctl改了沒生效或者生效了但副作用明顯sysctl.conf改完一定要sysctl -p重新加載否則配置只在當(dāng)前運(yùn)行環(huán)境中生效重啟就丟。改/proc下的文件也是同理重啟后需要重新寫入。有一個(gè)更隱蔽的坑是容器環(huán)境容器內(nèi)的/proc是只讀掛載內(nèi)核參數(shù)需要在宿主機(jī)上調(diào)整容器里改sysctl要么權(quán)限不足要么改了也影響不到宿主機(jī)。副作用方面我見過最典型的是把vm.min_free_kbytes調(diào)得過高結(jié)果內(nèi)核為保留空閑內(nèi)存提前觸發(fā)了內(nèi)存回收工作導(dǎo)致系統(tǒng)整體性能不升反降。調(diào)參要有度先用sysctl讀取當(dāng)前值再做小步調(diào)整每步都要有指標(biāo)驗(yàn)證。6.4 實(shí)用速查Linux系統(tǒng)性能優(yōu)化關(guān)鍵參數(shù)基線把我這輪優(yōu)化沉淀下來的參數(shù)基線整理成一張表方便大家對(duì)照自己的環(huán)境評(píng)估優(yōu)化對(duì)象核心參數(shù)/操作推薦值注意事項(xiàng)內(nèi)存換出vm.swappiness10不要設(shè)0swap是最后救生圈臟頁回寫vm.dirty_background_ratio / dirty_ratio10 / 20調(diào)大丟數(shù)據(jù)窗口變長大頁transparent_hugepagenever數(shù)據(jù)庫類服務(wù)強(qiáng)烈建議關(guān)閉IO調(diào)度器/sys/block/*/queue/schedulerHDD: deadline, SSD: none別用cfq文件系統(tǒng)掛載選項(xiàng)noatime,relatime日志目錄慎用commit調(diào)大網(wǎng)絡(luò)連接net.core.somaxconn4096應(yīng)用listen backlog要同步改網(wǎng)絡(luò)緩沖區(qū)rmem_max / wmem_max16MB過多加大延遲抖動(dòng)CPU調(diào)度kernel.sched_*默認(rèn)非必要不調(diào)這套基線不是金科玉律每臺(tái)機(jī)器的負(fù)載類型不一樣適用的參數(shù)組合也不同。我每次做優(yōu)化之前都會(huì)先把當(dāng)前參數(shù)快照存下來改完一批就做一輪壓測(cè)確認(rèn)沒有回退再進(jìn)入下一批。這樣即使出現(xiàn)意外也能快速回滾到上一個(gè)穩(wěn)定版本。6.5 一個(gè)習(xí)慣每輪優(yōu)化只動(dòng)一件事最后分享一個(gè)讓我少踩很多坑的習(xí)慣每一輪優(yōu)化只改一個(gè)子系統(tǒng)里的一個(gè)參數(shù)改完留出足夠的觀察和壓測(cè)時(shí)間再考慮下一個(gè)改動(dòng)。同時(shí)改CPU調(diào)度、swap、IO調(diào)度器、網(wǎng)絡(luò)參數(shù)一旦出問題你根本不知道該回滾哪一項(xiàng)。我見過有人一天之內(nèi)改了十幾個(gè)內(nèi)核參數(shù)結(jié)果系統(tǒng)性能暴跌最后只能重置一整套系統(tǒng)配置。正確的姿勢(shì)是把改動(dòng)記錄在一張表格里每行寫清楚改了什么、為什么改、預(yù)期收益是什么、壓測(cè)結(jié)果如何這既是給自己留的臺(tái)賬也是以后做復(fù)盤的第一手資料。這輪Linux系統(tǒng)性能優(yōu)化做完之后我最深的體會(huì)是大部分問題在開始動(dòng)手之前就已經(jīng)注定能不能解決了。把80%的時(shí)間花在定位問題上真正調(diào)參數(shù)往往只需要幾分鐘。監(jiān)控工具用好、排查思路理清、每步改動(dòng)可回滾這三件事做好性能優(yōu)化就沒那么玄乎。希望這篇記錄能讓你少走幾個(gè)我走過的彎路。