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