簡介這份文檔面向企業(yè)級 Linux 運維工程師與系統(tǒng)管理員聚焦 Red Hat Enterprise Linux AS 與 SUSE LINUX Enterprise Server 兩大發(fā)行版下的性能調(diào)優(yōu)實踐幫助讀者在有限硬件條件下提升服務器吞吐與穩(wěn)定性。內(nèi)容圍繞關(guān)閉非必要 daemons、停用 GUI 圖形界面、修改內(nèi)核參數(shù)三條主線展開并延伸至處理器、內(nèi)存、文件系統(tǒng)與網(wǎng)絡(luò)子系統(tǒng)的調(diào)優(yōu)思路涉及 sysctl、runlevel、chkconfig、taskset、nice 等常用手段同時提醒過度優(yōu)化可能帶來的反效果。資源包內(nèi)含 1 個 docx 文檔約 373KB按調(diào)優(yōu)主題分節(jié)組織便于按需查閱與對照實踐。目前已有 239 人學習適合希望系統(tǒng)梳理 Linux 性能優(yōu)化路徑、積累調(diào)優(yōu)經(jīng)驗的中高級運維人員參考。1. Linux 性能調(diào)優(yōu)的幾種方法從一臺「沒跑滿卻卡成 PPT」的機器說起一臺 8 核 16G 的 Linux 服務器CPU 使用率不到 30%內(nèi)存還剩一半可業(yè)務接口的 P99 從 80ms 漲到了 900ms。登錄上去敲topload average 是 12iostat里%util貼著 100%vmstat的wa列高得離譜——問題不在 CPU也不在內(nèi)存而是磁盤 I/O 把整條鏈路拖住了。這就是 Linux 性能調(diào)優(yōu)最典型的場景瓶頸往往不在你第一眼看的那個指標上。這篇筆記圍繞「Linux 性能調(diào)優(yōu)的幾種方法」展開把 CPU、內(nèi)存、磁盤 I/O、網(wǎng)絡(luò)四條主線拆開講清楚每條線用什么工具定位、關(guān)鍵參數(shù)怎么讀、改哪些內(nèi)核參數(shù)或應用配置能真正見效、改完怎么驗證沒翻車。適合已經(jīng)能熟練敲linux 常用命令、但遇到性能問題還靠「重啟大法」的運維和后端同學也適合準備linux 面試題時想把「調(diào)優(yōu)」這塊從背答案變成真會做的人。下面所有命令都在主流發(fā)行版CentOS/RHEL、Ubuntu/Debian、國產(chǎn) Linux 發(fā)行版上驗證過參數(shù)含義逐條說明不玩玄學。2. 先定位再動手用 USE 方法把四條資源線跑一遍調(diào)優(yōu)最大的坑是「上來就改參數(shù)」。sysctl里幾百個內(nèi)核參數(shù)不知道瓶頸在哪就亂調(diào)輕則無效重則把穩(wěn)定的服務調(diào)崩。我一般先用 USE 方法Utilization 使用率、Saturation 飽和度、Errors 錯誤把 CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)四條線快速掃一遍鎖定嫌疑對象再進具體章節(jié)。2.1 四條資源線的最小排查命令組合先裝好sysstat工具包yum install sysstat或apt install sysstat它提供sar、iostat、pidstat這一套。下面這組命令是我每次上機器必跑的第一輪# 1. 全局概覽load、CPU、內(nèi)存、swap、上下文切換 vmstat 1 5 # 輸出關(guān)注列 # r 運行隊列長度持續(xù) CPU核數(shù) 說明 CPU 飽和 # b 阻塞進程數(shù)0 通常意味著 I/O 等待 # si/so swap 換入換出非 0 就要警惕內(nèi)存壓力 # wa I/O 等待占 CPU 時間百分比20 基本鎖定磁盤 # cs 上下文切換次數(shù)突增可能是鎖競爭 # 2. 磁盤每個設(shè)備的 IOPS、吞吐、隊列、利用率 iostat -xz 1 5 # 關(guān)注列 # %util 設(shè)備繁忙度接近 100% 說明設(shè)備飽和 # await 平均 I/O 等待毫秒數(shù)機械盤 20ms、SSD 5ms 要查 # aqu-sz 平均隊列深度持續(xù) 1 說明請求排隊 # r/s w/s 讀寫 IOPS # 3. 進程級誰在吃 CPU、誰在等 I/O pidstat -u -d -r 1 5 # -u CPU -d 磁盤 -r 內(nèi)存缺頁 # 4. 網(wǎng)絡(luò)連接數(shù)、重傳、丟包 ss -s netstat -s | grep -iE retrans|drop|overflow邏輯說明vmstat給全局畫像iostat確認磁盤是否飽和pidstat把責任落到具體進程ss/netstat看網(wǎng)絡(luò)層有沒有異常。四步下來瓶頸基本能定位到某一條線。參數(shù)上vmstat 1 5表示每秒采樣一次共 5 次采樣間隔別設(shè)太大否則瞬時毛刺會被平均掉iostat -x的-x是顯示擴展統(tǒng)計不加這個參數(shù)看不到%util和await等于白跑。提示load average高不等于 CPU 忙。Linux 的 load 把「運行中」和「不可中斷睡眠D 狀態(tài)多在等 I/O」的進程都算進去所以磁盤卡死時 load 會飆高而 CPU 很閑。看到 load 高先看vmstat的b列和wa列。2.2 把指標對應到「改什么」的決策表定位到瓶頸后下一步是決定動哪里。下面這張表是我自己用的對照表左邊是現(xiàn)象右邊是優(yōu)先嘗試的方向避免瞎調(diào)現(xiàn)象大概率瓶頸優(yōu)先動作r列持續(xù) 核數(shù)ussy高CPU 飽和查熱點進程/線程看是否可并行或限流sy特別高30%系統(tǒng)調(diào)用/上下文切換查cs、中斷看是否鎖競爭或頻繁 syscallsi/so非 0free的 available 低內(nèi)存不足觸發(fā) swap查內(nèi)存泄漏調(diào)vm.swappinesswa高%util接近 100%磁盤 I/O 飽和查慢查詢/大文件寫考慮 IO 調(diào)度器重傳率高、ss -s連接堆積網(wǎng)絡(luò)或連接數(shù)瓶頸查somaxconn、tcp_max_syn_backlog這張表的價值在于它把「看指標」和「改配置」連起來了。很多人卡在中間——數(shù)據(jù)會看但不知道該改哪個參數(shù)。有了這張表至少方向不會錯。接下來四章分別展開 CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)的具體調(diào)法。3. CPU 與調(diào)度調(diào)優(yōu)從 load 高但 CPU 閑的怪象說起CPU 調(diào)優(yōu)最容易翻車的地方是把「CPU 使用率高」直接等同于「CPU 不夠用」。實際上us用戶態(tài)、sy內(nèi)核態(tài)、waI/O 等待、st被虛擬化偷走四個值指向完全不同的病因。這一章先把 CPU 指標讀透再講調(diào)度和綁核這類真正能見效的手段。3.1 讀懂 us/sy/wa/st四種「CPU 高」的不同解法top第一行的%Cpu(s)拆開看us高應用在用戶態(tài)真算得歡。常見于計算密集、死循環(huán)、正則回溯。解法是查熱點函數(shù)perf top或加緩存。sy高內(nèi)核態(tài)時間多通常是系統(tǒng)調(diào)用頻繁、上下文切換多、鎖競爭。vmstat的cs列會同步飆高。解法是減少 syscall批量讀寫代替逐條、排查鎖。wa高CPU 在等磁盤本質(zhì)是 I/O 問題不是 CPU 問題。別去加 CPU去查磁盤。st高虛擬機被宿主機「偷」了 CPU 時間。這種情況你在 guest 里怎么調(diào)都沒用得找宿主機或換實例規(guī)格。我見過最典型的誤判一臺機器sy占到 40%運維以為是 CPU 不夠要擴容實際是應用每秒發(fā)起幾十萬次小write系統(tǒng)調(diào)用。改成批量寫之后sy掉到 5%機器根本不用換。所以看到 CPU 高先分清是哪種高。# 找出用戶態(tài) CPU 最高的線程并看到它在干什么 top -H -p $(pgrep -f your_app | head -1) # 拿到高 CPU 的線程 TID 后轉(zhuǎn)成 16 進制 printf %x\n TID # 用 perf 或 gdb 看這個線程的調(diào)用棧 perf top -p PID # 或者直接采樣整個系統(tǒng) 5 秒 perf record -F 99 -a -g -- sleep 5 perf report邏輯說明top -H把進程拆到線程級定位到具體線程perf record -F 99以 99Hz 采樣 5 秒-g記錄調(diào)用棧perf report里能看到熱點函數(shù)。參數(shù)-F 99是采樣頻率99 是經(jīng)驗值避開 100 的整數(shù)倍減少與定時器共振。這一步的目的是把「CPU 高」落到具體代碼路徑而不是停在進程名。3.2 進程優(yōu)先級、綁核與調(diào)度策略的取舍定位到熱點后如果短期內(nèi)改不了代碼可以用調(diào)度手段緩解。三個常用動作調(diào)整 nice 值renice -n -5 -p PID提高優(yōu)先級需要 root讓關(guān)鍵進程優(yōu)先拿到 CPU。但注意nice 只在 CPU 爭搶時起作用CPU 空閑時調(diào)它沒意義。CPU 綁核taskset -cp 0-3 PID把進程綁到 0-3 號核。適合對延遲敏感、且希望減少跨核緩存失效的服務。但綁核是雙刃劍——綁太死會讓該進程在核忙時干等反而增加延遲。我一般只對延遲敏感的中間件如網(wǎng)關(guān)綁核且留出至少一個核給系統(tǒng)。調(diào)度策略普通進程用 CFS完全公平調(diào)度實時進程可用chrt設(shè) SCHED_FIFO/SCHED_RR。實時策略優(yōu)先級高于所有普通進程設(shè)錯了會把系統(tǒng)卡死比如一個死循環(huán)的實時進程能餓死所有其他進程生產(chǎn)環(huán)境慎用。# 查看進程當前調(diào)度策略和優(yōu)先級 chrt -p PID # 把進程設(shè)為 SCHED_FIFO優(yōu)先級 101-99越高越優(yōu)先 chrt -f -p 10 PID # 綁核到 2、3 號 CPU taskset -cp 2,3 PID參數(shù)說明chrt -f是 FIFO 策略-p 10是優(yōu)先級。FIFO 策略下同優(yōu)先級進程按到達順序執(zhí)行且不會被低優(yōu)先級搶占。注意實時進程如果陷入死循環(huán)會獨占 CPU 導致系統(tǒng)無響應務必配合ulimit或 watchdog 使用。綁核的核編號從 0 開始lscpu能看到可用核范圍。提示容器環(huán)境下Docker/K8staskset和chrt的效果受 cgroup CPU 配額限制。如果容器設(shè)了--cpus2你在容器里綁 4 個核也沒用實際還是被 cgroup 限流。調(diào)優(yōu)前先確認cat /sys/fs/cgroup/cpu.maxcgroup v2或?qū)?cgroup v1 文件。4. 內(nèi)存與 swap 調(diào)優(yōu)OOM 之前你還有哪些后悔藥內(nèi)存問題的可怕之處在于它平時不聲不響一旦觸發(fā) OOM Killer進程直接被 kill業(yè)務瞬間掉線。這一章講三件事怎么判斷內(nèi)存是真不夠還是被緩存占了、swap 到底該不該關(guān)、以及 OOM 發(fā)生前能做什么。4.1 分清 available、buff/cache 與真正的內(nèi)存壓力free -h的輸出里最容易被誤讀的是buff/cache。很多人看到free只剩幾百 M 就慌了其實buff/cache是可回收的——它被內(nèi)核用來緩存文件內(nèi)存緊張時會自動釋放。真正該看的是available這一列它估算的是「不觸發(fā) swap 的情況下還能給新進程用多少內(nèi)存」。free -h # 關(guān)注 available 列而不是 free 列 # 看內(nèi)存壓力更準的指標/proc/meminfo 里的 MemAvailable grep -E MemTotal|MemFree|MemAvailable|SwapTotal|SwapFree|Dirty /proc/meminfo # 看誰在占內(nèi)存按 RSS 排序 ps aux --sort-rss | head -10 # 看進程的內(nèi)存明細常駐、共享、缺頁 pidstat -r 1 5邏輯說明MemAvailable是內(nèi)核給出的「可用內(nèi)存」估算比MemFree靠譜得多。Dirty是待寫回磁盤的臟頁如果這個值很大且長時間不降說明寫回跟不上可能引發(fā)內(nèi)存回收壓力。pidstat -r的minflt/s次缺頁和majflt/s主缺頁能看出進程是否在頻繁觸發(fā)磁盤換頁——majflt高說明進程在等磁盤性能會斷崖式下跌。4.2 swappiness、overcommit 與 OOM 的三個關(guān)鍵參數(shù)內(nèi)存相關(guān)的內(nèi)核參數(shù)里真正影響生產(chǎn)穩(wěn)定性的就三個vm.swappiness控制內(nèi)核把內(nèi)存頁換到 swap 的傾向取值 0-100。默認 60意味著內(nèi)核比較積極用 swap。對數(shù)據(jù)庫、緩存類服務我一般設(shè)成 1 或 10減少不必要的換出但不建議設(shè)成 0因為 0 在部分內(nèi)核版本上會讓內(nèi)核在內(nèi)存緊張時直接 OOM 而不是先換出反而更危險。vm.overcommit_memory控制內(nèi)存分配策略。0 是啟發(fā)式默認1 是永遠允許超額分配2 是嚴格限制。Redis 這類 fork 場景建議設(shè) 1避免 fork 時因 overcommit 檢查失敗。vm.panic_on_oomOOM 時是否 panic。默認 0只 kill 進程生產(chǎn)環(huán)境保持 0讓系統(tǒng) kill 掉最占內(nèi)存的進程而不是整機重啟。# 臨時生效 sysctl -w vm.swappiness10 sysctl -w vm.overcommit_memory1 # 永久生效寫入 /etc/sysctl.d/99-tuning.conf cat /etc/sysctl.d/99-tuning.conf EOF vm.swappiness 10 vm.overcommit_memory 1 vm.dirty_ratio 20 vm.dirty_background_ratio 10 EOF sysctl -p /etc/sysctl.d/99-tuning.conf參數(shù)說明vm.dirty_ratio20表示臟頁占到內(nèi)存 20% 時寫操作會被阻塞強制回寫vm.dirty_background_ratio10表示臟頁到 10% 時后臺開始回寫。這兩個值調(diào)低能讓寫回更平滑避免突發(fā)大量臟頁導致 I/O 抖動但調(diào)太低會增加磁盤寫次數(shù)。我一般把dirty_ratio設(shè)在 15-20dirty_background_ratio設(shè)在 5-10。注意改swappiness前先確認機器有沒有 swap。swapon --show為空說明沒啟用 swap改這個參數(shù)沒意義。另外 SSD 上頻繁 swap 會加速磨損但現(xiàn)代 SSD 壽命足夠不必因噎廢食關(guān)鍵還是別讓內(nèi)存真的不夠。5. 磁盤 I/O 調(diào)優(yōu)iostat 里 %util 100% 時該動哪里磁盤 I/O 是生產(chǎn)環(huán)境最常見的瓶頸也是最容易被誤診的。%util100% 不代表磁盤一定到極限——對多隊列的 NVMe%util可能虛高。這一章講怎么正確判斷磁盤飽和、IO 調(diào)度器怎么選、以及文件系統(tǒng)和掛載參數(shù)能帶來什么。5.1 用 await、aqu-sz、IOPS 判斷磁盤是否真飽和iostat -xz 1里幾個關(guān)鍵列的正確讀法r/s、w/s每秒讀寫次數(shù)IOPS。對比磁盤標稱 IOPS看是否接近上限。await平均每次 I/O 的等待時間毫秒包含排隊時間。這是判斷用戶體驗最直接的指標。aqu-sz平均隊列深度。持續(xù)大于 1 說明請求在排隊。%util設(shè)備繁忙百分比。對單隊列設(shè)備機械盤、SATA SSD這個值有意義對多隊列 NVMe即使 %util 100% 也可能還有余量要結(jié)合await和 IOPS 一起看。# 看磁盤的實時 IOPS 和延遲 iostat -xz 1 5 # 找出哪個進程在瘋狂讀寫 iotop -oPa # 或不用 iotop 時用 pidstat pidstat -d 1 5 # 看具體是哪個文件被讀寫需要 root # 先找到進程 PID再看它打開的文件 lsof -p PID | grep -E REG|DIR邏輯說明iotop -oPa的-o只顯示有 I/O 的進程-P顯示進程而非線程-a顯示累計。pidstat -d的kB_rd/s和kB_wr/s是讀寫吞吐。定位到進程后lsof看它打開了哪些文件能進一步縮小到具體數(shù)據(jù)文件或日志。5.2 IO 調(diào)度器選擇與文件系統(tǒng)掛載參數(shù)Linux 的 IO 調(diào)度器決定請求怎么排隊和合并。常見三種調(diào)度器適用場景特點none/noopNVMe、高性能 SSD不做排序直接下發(fā)依賴設(shè)備自身隊列mq-deadline通用、數(shù)據(jù)庫保證請求在截止時間內(nèi)完成防餓死bfq桌面、交互式按進程分配帶寬公平性好但開銷大查看和切換# 查看當前調(diào)度器 cat /sys/block/nvme0n1/queue/scheduler # 輸出如 [none] mq-deadline bfq方括號是當前生效的 # 臨時切換 echo mq-deadline /sys/block/nvme0n1/queue/scheduler # 永久生效寫 udev 規(guī)則 cat /etc/udev/rules.d/60-ioscheduler.rules EOF ACTIONadd|change, KERNELnvme[0-9]*, ATTR{queue/scheduler}none ACTIONadd|change, KERNELsd[a-z], ATTR{queue/scheduler}mq-deadline EOF參數(shù)說明NVMe 設(shè)備用none通常性能最好因為它自身有深度隊列內(nèi)核再排序反而增加開銷。SATA SSD 和機械盤用mq-deadline更穩(wěn)。bfq在服務器上一般不用開銷偏大。文件系統(tǒng)掛載參數(shù)也能影響 I/O 性能。以 ext4 為例noatime能避免每次讀文件都更新訪問時間減少寫操作datawriteback提升寫性能但降低一致性保證數(shù)據(jù)庫場景慎用。# /etc/fstab 里給數(shù)據(jù)盤加 noatime # /dev/sdb1 /data ext4 defaults,noatime 0 2 mount -o remount,noatime /data提示noatime對大多數(shù)服務是安全的但如果你的應用依賴文件訪問時間比如某些備份工具判斷文件是否被讀過就別加。改掛載參數(shù)前先確認業(yè)務不依賴 atime。6. 網(wǎng)絡(luò)與內(nèi)核參數(shù)調(diào)優(yōu)高并發(fā)下連接被丟在哪一步網(wǎng)絡(luò)調(diào)優(yōu)的坑在于參數(shù)很多但真正影響高并發(fā)表現(xiàn)的沒幾個。這一章聚焦 TCP 連接建立、連接隊列、以及文件描述符這幾個高并發(fā)場景下的關(guān)鍵點。6.1 從 ss 和 netstat 看連接堆積在哪高并發(fā)下連接建立失敗通?？ㄔ谌齻€地方半連接隊列SYN 隊列、全連接隊列accept 隊列、文件描述符耗盡。先用命令確認卡在哪# 看各種狀態(tài)的連接數(shù) ss -s # 看監(jiān)聽隊列的溢出情況 ss -lnt # 輸出里 Send-Q 是隊列上限Recv-Q 是當前排隊數(shù) # 如果 Recv-Q 接近 Send-Q說明 accept 隊列快滿了 # 看內(nèi)核層面的隊列溢出統(tǒng)計 netstat -s | grep -iE listen|syn|overflow # times the listen queue of a socket overflowed 非 0 說明全連接隊列溢出 # SYNs to LISTEN sockets dropped 非 0 說明半連接隊列溢出邏輯說明ss -lnt的Recv-Q對 LISTEN 狀態(tài)的 socket 表示當前已完成三次握手、等待應用 accept 的連接數(shù)Send-Q是隊列上限。如果Recv-Q持續(xù)接近Send-Q說明應用 accept 太慢要么加應用處理能力要么調(diào)大隊列。netstat -s里的溢出計數(shù)是累計值隔一段時間看增量才有意義。6.2 somaxconn、tcp_max_syn_backlog 與文件描述符三個最常調(diào)的網(wǎng)絡(luò)參數(shù)net.core.somaxconn全連接隊列上限默認 128老內(nèi)核或 4096。高并發(fā)服務建議調(diào)到 32768。注意這個值要和應用的listen()backlog 參數(shù)配合取兩者較小值。net.ipv4.tcp_max_syn_backlog半連接隊列上限默認 1024 左右。SYN Flood 或高并發(fā)建連時可能不夠建議調(diào)到 8192 以上。文件描述符ulimit -n默認 1024高并發(fā)下遠遠不夠。要同時改系統(tǒng)級和進程級。# 臨時調(diào)整 sysctl -w net.core.somaxconn32768 sysctl -w net.ipv4.tcp_max_syn_backlog8192 sysctl -w net.ipv4.tcp_syncookies1 # 永久寫入配置文件 cat /etc/sysctl.d/99-tuning.conf EOF net.core.somaxconn 32768 net.ipv4.tcp_max_syn_backlog 8192 net.ipv4.tcp_syncookies 1 net.ipv4.tcp_tw_reuse 1 net.ipv4.ip_local_port_range 10240 65000 EOF sysctl -p /etc/sysctl.d/99-tuning.conf # 文件描述符系統(tǒng)級 cat /etc/security/limits.conf EOF * soft nofile 65535 * hard nofile 65535 EOF # 進程級systemd 服務 # 在 service 文件里加 LimitNOFILE65535參數(shù)說明tcp_syncookies1在 SYN 隊列滿時用 cookie 機制響應能緩解 SYN Flood但會犧牲部分 TCP 選項如窗口縮放高并發(fā)正常場景下影響不大。tcp_tw_reuse1允許復用 TIME_WAIT 狀態(tài)的連接緩解端口耗盡但只在客戶端主動連接時生效。ip_local_port_range擴大本地端口范圍增加可用連接數(shù)。注意tcp_tw_reuse和已廢棄的tcp_tw_recycle不是一回事。tcp_tw_recycle在 NAT 環(huán)境下會導致連接異常已被內(nèi)核移除別再去開它。改somaxconn后要重啟應用才生效因為隊列大小在listen()時確定。7. 調(diào)優(yōu)后的驗證與回滾怎么確認沒把系統(tǒng)調(diào)壞調(diào)優(yōu)最怕的是「改完感覺快了但不知道是不是錯覺」或者更糟——改完當時沒事壓測一上來就崩。這一章講怎么用數(shù)據(jù)驗證調(diào)優(yōu)效果以及怎么給自己留后悔藥。7.1 用壓測和基線對比驗證效果調(diào)優(yōu)前后必須有可對比的數(shù)據(jù)。我一般用wrk或ab做 HTTP 壓測用fio做磁盤壓測記錄關(guān)鍵指標# HTTP 壓測4 線程 100 連接持續(xù) 30 秒 wrk -t4 -c100 -d30s --latency http://127.0.0.1:8080/api # 磁盤壓測隨機讀 4K隊列深度 32跑 30 秒 fio --namerandread --ioenginelibaio --rwrandread \ --bs4k --numjobs4 --iodepth32 --runtime30 \ --time_based --group_reporting # 壓測同時采集系統(tǒng)指標 sar -u -r -d 1 30 /tmp/before_tuning.log邏輯說明wrk的--latency會輸出延遲分布P50/P90/P99這是比平均值更有意義的指標。fio的--iodepth32模擬高并發(fā) I/O--numjobs4是并發(fā)任務數(shù)。壓測時用sar同步采集事后對比調(diào)優(yōu)前后的%util、await、CPU 各態(tài)占比。關(guān)鍵原則一次只改一個參數(shù)改完壓測確認有效再改下一個否則出了問題不知道是哪個參數(shù)導致的。7.2 參數(shù)回滾與變更記錄調(diào)優(yōu)參數(shù)一定要有回滾方案。我的習慣是所有sysctl改動寫進獨立的/etc/sysctl.d/99-tuning.conf不直接改/etc/sysctl.conf回滾時刪文件即可。改動前記錄原值sysctl -a /tmp/sysctl_before.txt回滾時對比。應用層參數(shù)如 JVM、連接池改動走配置中心或版本控制別手改線上文件。每次變更記錄改了什么、為什么改、預期效果、實際效果、回滾命令。# 記錄當前所有內(nèi)核參數(shù)作為基線 sysctl -a /tmp/sysctl_baseline_$(date %F).txt # 回滾刪除調(diào)優(yōu)文件并重新加載 rm /etc/sysctl.d/99-tuning.conf sysctl --system # 對比改動前后的差異 diff (sysctl -a) /tmp/sysctl_baseline_2024-01-01.txt參數(shù)說明sysctl --system會重新加載所有配置文件包括/etc/sysctl.d/下的。diff能快速看出哪些參數(shù)被改過。這套流程看起來繁瑣但真出問題時能讓你在幾分鐘內(nèi)回到已知穩(wěn)定狀態(tài)比現(xiàn)場抓瞎強太多。我踩過最深的一個坑有次為了「優(yōu)化」把vm.dirty_ratio從 20 調(diào)到 5壓測時寫性能確實好了但上線后遇到一次大批量寫臟頁回寫太頻繁導致磁盤 I/O 抖動反而拖慢了讀請求。后來才明白dirty_ratio調(diào)低是拿「寫平滑」換「寫吞吐」得看業(yè)務是讀多還是寫多。調(diào)優(yōu)沒有銀彈每個參數(shù)背后都是取舍。希望這些經(jīng)驗能幫你少走點彎路幫到你。本文還有配套的精品資源點擊獲取