性能優化
本文將介紹與性能有關的系統診斷知識和具體步驟,通過減少資源消耗等方式優化系統性能。遊戲相關的特別優化請參閱遊戲#性能優化。
基礎[編輯 | 編輯原始碼]
了解你的系統[編輯 | 編輯原始碼]
性能優化的最佳方法是找到瓶頸或拖慢整體速度的子系統。查看系統細節可以幫助確定問題。
- 如果在同時運行多個大型程序時卡頓(如 LibreOffice、Firefox 等),請檢查內存容量是否充足。使用以下命令,並檢查「available」一列的數值:
$ free -h
- 如果電腦開機很慢,並且(僅在)第一次打開應用時加載很慢,可能是因為硬碟速度過慢。可以用
hdparm
命令測試硬碟速度:# hdparm -t /dev/sdX
- 如果使用直接渲染(GPU 渲染)的應用運行卡頓(比如使用 GPU 的視頻播放器、遊戲甚至窗口管理器),改善 GPU 的性能應當有所幫助。首先需要檢查直接渲染是否已經開啟。可以使用 mesa-utils包 中的
glxinfo
命令:$ glxinfo | grep "direct rendering"
,如果開啟了,則會返回direct rendering: Yes
。
基準測試[編輯 | 編輯原始碼]
為定量評估優化成果,可使用基準測試。
存儲設備[編輯 | 編輯原始碼]
多硬體路徑[編輯 | 編輯原始碼]
內部硬體路徑意指儲存設備是如何連接到主板的。例如 TCP/IP 經由 NIC、即插即用設備可以使用 PCIe/PCI、火線、RAID 卡 、USB 等。通過將儲存設備均分到這些接口可以最大化主板的性能,比如將六個硬碟接連到 USB 要比三個連接到 USB、三個連接到火線要慢。原因是主板上的接口點類似管道,而管道同一時間的最大流量是有上限的。幸運的是主板通常會有多個管道。
此外,假設電腦前面有兩個 USB 插口,後面有四個 USB 插口,那麼前面插兩個、後面插兩個應當要比前面插一個、後面插三個更快。這是因為前面的插口可能是多個根 Hub 設備,也就是說它可以在同一時間發送更多的數據。
使用下面的命令查看機器上是否有多個路徑:
USB設備樹
$ lsusb -tv
PCI設備樹
$ lspci -tv
分區[編輯 | 編輯原始碼]
確保您已經對齊分區。
多硬碟[編輯 | 編輯原始碼]
如果有多個硬碟,將其設置為軟體 RAID 可以提升速度。
在分離的硬碟上創建交換空間也有所幫助,尤其是使用交換空間十分頻繁時。
選擇並調整文件系統[編輯 | 編輯原始碼]
為系統選擇合適的文件系統十分重要,因為不同文件系統有各自的優勢。文件系統文中對主流文件系統作了簡短的總結,也可以在分類:文件系統中閱讀其他相關文章。
掛載選項[編輯 | 編輯原始碼]
一些*atime 選項可以降低strictatime
造成的性能損失。其他選項和文件系統相關,請參考所使用文件系統的相關段落。
更改內核選項[編輯 | 編輯原始碼]
有些選項會影響塊設備的性能,更多信息請參考 sysctl#虛擬內存。
I/O 調度[編輯 | 編輯原始碼]
背景信息[編輯 | 編輯原始碼]
I/O調度器是用於決定塊I/O操作提交到存儲設備順序的一個內核組件,這裡有必要簡單的說一下兩種主要驅動器的規格,因為I/O調度器的目標是優化這些不同驅動器的處理請求的方式:
- 機械硬碟(HDD)的工作原理是旋轉磁碟以物理方式將扇區靠近磁頭,基於這個原因,機械硬碟的隨機讀取延遲相當的高,一般在3到12毫秒。而順序訪問則可提供更高的吞吐量,典型的機械硬碟的I/O操作吞吐量約為每秒200次即200IOPS
- 固態硬碟(SSD)沒有機械硬碟那樣的移動部件,因此它的隨機訪問速度和順序訪問速度是一樣快的,通常不到0.1毫秒,並且可以處理多個並發的請求。典型的固態硬碟的I/O吞吐量超過了10,000IOPS,遠超出了常見工作負載下所需的吞吐量
當多個進程向不同的存儲部件發出了I/O請求,每秒就會產生數千的I/O請求,而一般的機械硬碟每秒只能處理大約200個I/O請求,這就是I/O調度發揮其作用的時候。
調度算法[編輯 | 編輯原始碼]
提高吞讀量的一種方法是將訪問隊列進行物理上的線性化,即通過對等待請求按照邏輯地址進行排序,並且將地址上最近的一些請求組合在一起,舉個例子,當三個程序發出請求,分別為1,2,3,其中1號要操作的位置在磁碟中間,而2號操作的位置在磁碟頭部,3號操作的位置位於磁碟尾部,出於提高吞讀的需求,我們會希望磁頭能夠轉完一圈的時候將這三個I/O操作全部完成,也就是按照2,1,3的順序來執行I/O操作,這很像現實生活中的電梯,因此,這個調度算法也被稱為電梯調度算法(elevator)。
但是電梯調度算法存在著一個問題,它並不適用於一個正在進行順序讀寫的進程,常見的情況是:一個進程讀取了一塊數據並且就要讀取下一塊,上一個操作完成到下一個操作發起的時間相對於已經轉到物理位置時進行讀寫所需時間來講是很長的(進行操作僅需幾微秒,而上一個操作完成到下一個往往需要幾十微秒,這個調度算法推出的時候5400轉的機械硬碟依舊是主流,而5400轉的硬碟轉一圈需要11.11毫秒)。 這個例子暴露出了電梯調度算法並不知道進程即將讀取下一塊數據. 預測調度算法(anticipatory I/O scheduler)解決了這個問題:它在處理另一個請求之前,先暫停幾毫秒(並不是停下磁碟),等待另一個與上個操作在物理位置上相近的操作。
以上兩個調度算法都是試圖提高總吞吐量的算法, 但他們忽視了I/O調度中的另一個問題,就是請求的延遲問題. 舉個例子:當大多數進程在磁碟頭髮起請求,而少量的進程在磁碟另外一端,需要轉一圈才可以訪問(反轉是不現實的,將一片正在高速旋轉的磁碟突然停下然後反轉這對磁碟的強度提出了極高的需求),這時,預測算法就會在一系列對於磁碟頭的操作的請求中,等待數多個「幾毫秒」,而這時磁碟尾端操作的請求早已等候許久,甚至可能已經因為I/O操作無法完成而無法進行下一步操作。我們將這樣的情況稱之為飢餓. 為了增加I/O操作的公平性 ,截止日期算法( deadline algorithm)應運而生 。它也有一個按照地址排序的隊列,與電梯算法類似, 當一個進程在隊列中等待了太久它們就會被移入到一個名為 "expired"(意指到期) 的隊列中按照誰到期時間更久誰越靠前進行排序。調度器會檢查這個隊列,並從中處理請求,處理完成後,才會回到電梯隊列中。這種調度方式犧牲了整體吞吐量以此交換了操作延遲,這也是I/O調度算法所需解決的問題,即吞吐量與延遲的平衡。
完全公平隊列算法( Completely Fair Queuing (CFQ) )試圖從不同的角度來平衡吞吐量與延遲,它將時間劃分成時間片,然後根據進程優先級來劃分配這個時間片與允許的請求數。 它支持 cgroup 以此允許為特定的進程保留一些時間片和請求數。 這在雲存儲中特別適用: 一些雲存儲服務的付費用戶總是期望可以得到更多的IOPS。 此外它也會在同步I/O結束的時候閒置下來,等待其他附近位置的操作, 以此,它取代了預測調度算法(anticipatory scheduler)並且帶來了一些增強的功能. 預測調度算法(anticipatory scheduler)和電梯調度算法(elevator schedulers)都在現在的 Linux 內核中被下面更為先進的算法所替代。
預算公平算法( Budget Fair Queuing (BFQ) )是一種基於 CFQ 代碼增加一些功能改進而來。它並不為磁碟分配固定的時間片,而是根據使用啟發式的算法為進程分配「預算」(Budget). 它相對與其他算法來說比較複雜, 這種算法也許更適合本來吞吐量就偏低的機械硬碟和低速SSD,它每次操作的開銷都更高,特別是當CPU速度較慢時,這個調度算法甚至可能降低設備的響應速度. 它在個人系統上的目標是優化交互式任務的體驗, 此時的存儲設備與空閒的時候響應性能相當。它默認的配置被用來提供最低延遲,而不是最大吞吐量
Kyber 是一種新推出的調度器。受到網絡路由器的主動隊列管理結束啟發,使用「token」用作限制請求的一種調度機制。這個機制有兩個「令牌」(token)一個稱為隊列令牌(queuing token),用來防止請求進入「飢餓」狀態,另一個稱為「調度令牌」(dispatch token),被用作限制在指定設備上操作的優先級。 最後再定義一個目標讀取延遲,並調整調度器來達到這個目標。 這個算法的實現相對簡單,並且被認為是用於高速的設備(例如固態硬碟)。
內核的 I/O 調度器[編輯 | 編輯原始碼]
除去一些早期調度算法已經被移除, 官方的Linux kernel支持多種調度器,主要分為一下兩類:
- 內核默認支持多隊列調度器(multi-queue schedulers). 多隊列塊I/O排隊機制( Multi-Queue Block I/O Queuing Mechanism (blk-mq) )將I/O查詢映射到多個隊列, 任務分布於多個線程之間,同樣也分布在多個CPU核心之間。 以下幾種調度器在這個框架中可用:
- None, 不應用任何調度算法.
- mq-deadline, deadline(截止日期調度算法)的多線程版本。
- Kyber
- BFQ
- 單隊列調度器(single-queue schedulers) 是舊版本所擁有的調度器:
- 注意: 單隊列調度器(single-queue schedulers)自從Linux 5.0起被移除.
更改 I/O 調度器[編輯 | 編輯原始碼]
列出單一設備所有可用的調度器及激活中的調度器(方括號內):
$ cat /sys/block/sda/queue/scheduler
mq-deadline kyber [bfq] none
列出所有設備可用的所有調度器:
$ grep "" /sys/block/*/queue/scheduler
/sys/block/pktcdvd0/queue/scheduler:none /sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none /sys/block/sr0/queue/scheduler:[mq-deadline] kyber bfq none
將 sda 使用的調度器更改為 bfq:
# echo bfq > /sys/block/sda/queue/scheduler
不論硬碟為何種類型,更改 I/O 調度器的操作都可以被自動化並持久化。例如,下列展示的 udev 規則將 NVMe 硬碟的調度器設為 none,SSD/eMMC 硬碟設為 bfq,機械硬碟設為 bfq:
/etc/udev/rules.d/60-ioschedulers.rules
# HDD ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq" # SSD ACTION=="add|change", KERNEL=="sd[a-z]*|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="bfq" # NVMe SSD ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
完成後重啟或是強制 udev 加載新規則。
微調 I/O 調度器[編輯 | 編輯原始碼]
每一個內核的I/O調度器都有自己的tunables,如延遲時間、過期時間和FIFO參數。tunables有助於根據特定的設備和工作負載來調整算法。通常情況下,這是為了實現更高的吞吐量或更低的延遲。tunables及相關描述可以在內核文檔中找到。
要查看設備(例如sdb)可用的tunables,執行:
$ ls /sys/block/sdb/queue/iosched
fifo_batch front_merges read_expire write_expire writes_starved
上例中sdb使用deadline調度算法。
要犧牲延遲而改善deadline算法的吞吐量,可用以下命令提高fifo_batch
的值:
# echo 32 > /sys/block/sdb/queue/iosched/fifo_batch
電源管理配置與寫入緩存[編輯 | 編輯原始碼]
使用機械硬碟(HDD)時你可能會想要降低或是完全關閉省電功能,並確認寫入緩存是否已經啟用。
可以參考電源管理配置和 Hdparm#寫入緩存。
完成後,你可以配置 udev 規則以使更改在啟動時應用。
減少磁碟讀寫[編輯 | 編輯原始碼]
避免對慢速存儲設備的不必要訪問不僅可以提升性能,還能延長設備壽命(不過,在現代硬體上往往可以忽略這些操作對設備壽命的影響)。
顯示磁碟寫信息[編輯 | 編輯原始碼]
iotop包可以顯示程序寫入磁碟的頻率,並可將進程按寫入量排序。詳見iotop(8)。
重定位文件到 tmpfs[編輯 | 編輯原始碼]
可將某些文件(如瀏覽器profile)重定位到一個tmpfs上。這將讓文件存儲在內存中,在降低磁碟寫入量的同時提升應用響應速度。
在tmpfs與磁碟間同步瀏覽器profile,參見Profile-sync-daemon。有些瀏覽器可能需要額外操作(如Firefox on RAM)。
同步任何指定的文件夾,見Anything-sync-daemon。
在tmpfs中編譯程序以減少編譯用時,見Makepkg#減少編譯時間。
文件系統[編輯 | 編輯原始碼]
可參閱特定文件系統的維基頁面,檢查是否有適用的性能優化指南。如:Ext4#提升性能、XFS#性能。
交換空間[編輯 | 編輯原始碼]
見 Swap#性能優化。
Writeback interval 和緩衝區大小[編輯 | 編輯原始碼]
詳見 Sysctl#虛擬內存。
關閉Core dump[編輯 | 編輯原始碼]
詳見Core dump#Disabling automatic core dumps。
使用 ionice 調度儲存 I/O[編輯 | 編輯原始碼]
許多後台任務(如備份),並不需要低I/O延遲或高I/O帶寬。而對於桌面系統,要獲得流暢的UI響應,前台進程的I/O就必須足夠快。因此,若在其它任務需要時減少後台任務的存儲帶寬資源,將對提升性能大有裨益。Linux的CFQ I/O調度器支持為不同的進程設定不同的優先級,可以使用CFQ調度器達成這一點。
後台進程的I/O優先級可被降低到"Idle":
# ionice -c 3 command
CPU[編輯 | 編輯原始碼]
超頻[編輯 | 編輯原始碼]
超頻通過提升 CPU 的時鐘頻率提升電腦性能,超頻能力取決於 CPU 和主板的型號。通常使用 BIOS 進行超頻。超頻也會帶來風險和不便,這裡既不推薦超頻也不反對超頻。
很多 Intel 晶片不會在 acpi_cpufreq 或其他軟體中報告真正的時鐘頻率,這會導致過多的 dmesg 消息。通過卸載並將 acpi_cpufreq
模塊加入黑名單可以避免此問題。使用 i7z包 中的 i7z 可以讀取真實的時鐘速度。對於正確的 CPU 超頻方式而言,推薦使用壓力測試。
自動調整頻率[編輯 | 編輯原始碼]
見 CPU 調頻。
調整默認CPU調度器(CFS)[編輯 | 編輯原始碼]
mainline Linux內核中的默認CPU調度器是EEVDF。
其他CPU調度器[編輯 | 編輯原始碼]
- MuQSS — Multiple Queue Skiplist Scheduler. Available with the
-ck
patch set developed by Con Kolivas.
- PDS — Priority and Deadline based Skiplist multiple queue scheduler focused on desktop responsiveness.
- BMQ — The BMQ "BitMap Queue" scheduler was created based on existing PDS development experience and inspired by the scheduler found in Zircon by Google, the kernel on which their Fuchsia OS initiative runs. Available with a set of patches from CachyOS.
- Project C — Cross-project for refactoring BMQ into Project C, with re-creation of PDS based on the Project C code base. So it is a merge of the two projects, with a subsequent update of the PDS as Project C. Recommended as a more recent development.
- TT — The goal of the Task Type (TT) scheduler is to detect tasks types based on their behaviours and control the schedulling based on their types.
- BORE — The BORE scheduler focuses on sacrificing some fairness for lower latency in scheduling interactive tasks, it is built on top of CFS and is only adjusted for vruntime code updates, so the overall changes are quite small compared to other unofficial CPU schedulers.
實時內核[編輯 | 編輯原始碼]
有些應用(如在全高清(1080p)解析度下運行電視卡)可能在實時內核下表現更好。
調整進程優先級[編輯 | 編輯原始碼]
Ananicy[編輯 | 編輯原始碼]
Ananicy是一個用於自動調節可執行程序nice值的守護進程。nice值表示了在為特定可執行程序分配CPU資源時的優先級。Ananicy在AUR中可用:ananicy-gitAUR。
cgroups[編輯 | 編輯原始碼]
見cgroups。
Cpulimit[編輯 | 編輯原始碼]
Cpulimit是一個用於限制特定進程使用CPU資源多少的程序。安裝cpulimitAUR後,可以通過一個進程的PID來限制其CPU利用「百分比」。CPU利用「百分比」可取0到(總CPU核心數*100)間的任意值。例如,一個8核CPU的CPU利用「百分比」可取0到800間的值。
例如,要限制PID為5081的進程的CPU利用「百分比」為50,執行:
$ cpulimit -l 50 -p 5081
irqbalance[編輯 | 編輯原始碼]
irqbalance包通過在多處理器系統上將硬體中斷分散到每個處理器上以提升性能。可通過irqbalance.service
服務控制irqbalance的運行。
關閉CPU漏洞緩解措施[編輯 | 編輯原始碼]
關閉CPU漏洞緩解措施可能提升性能。 要完全關閉CPU漏洞緩解措施,使用如下內核參數:
mitigations=off
該內核參數改變的所有設置的詳細解釋可在kernel.org|這裡找到。 可以使用spectre-meltdown-checkerAUR 或者 util-linux包 提供的 lscpu(1) 進行漏洞檢測
顯卡[編輯 | 編輯原始碼]
Xorg 配置[編輯 | 編輯原始碼]
顯卡性能由/etc/X11/xorg.conf
的配置決定,見 NVIDIA、AMDGPU 和 Intel 文章。配置不當可能導致 Xorg 停止工作,請慎重操作。
Mesa 配置[編輯 | 編輯原始碼]
Mesa驅動的性能可通過drirc配置。此外,也可通過GUI工具進行配置:
- adriconf (Advanced DRI Configurator) — 通過GUI進行配置並向標準drirc文件寫入配置項的工具。
- DRIconf — 用於Direct Rendering Infrastructure的配置小程序。支持在應用/屏幕/設備層面上調整OpenGL的性能和視覺效果設置。
硬體視頻加速[編輯 | 編輯原始碼]
硬體視頻加速可利用顯卡解碼/編碼視頻。
超頻[編輯 | 編輯原始碼]
與 CPU 一樣,超頻可以直接提高性能,但通常不建議使用。AUR中的超頻工具有rovclockAUR (ATI 顯卡)、rocm-smi-lib包 (較新的 AMD 顯卡) 、nvclockAUR (到 Geforce 9系的舊 NVIDIA 顯卡),以及適用於新 NVIDIA 顯卡的nvidia-utils包。
見 AMDGPU#Overclocking 或 NVIDIA/Tips and tricks#Enabling overclocking。
啟用 PCI Resizable BAR[編輯 | 編輯原始碼]
- 在某些系統上啟用 PCI Resizable BAR 會造成性能嚴重下降。配置完成後務必對系統進行測試以確保性能獲得了提升。
- 啟用前 Compatibility Support Module (CSM) 必須關閉。
PCI 標準允許使用更大的基地址寄存器(BAR)以向 PCI 控制器暴露 PCI 設備的內存。這一操作可以提高顯卡的性能。允許訪問顯卡的所有顯存可以提高性能,同時也允許顯卡驅動對其進行針對性的優化。AMD將 resizable BAR、above 4G decoding 和顯示驅動一系列針對性的優化統稱為 AMD 顯存智取技術,最初出現在搭載 AMD 500 系列晶片組的主板上,並隨後通過 UEFI 更新擴展至 AMD 400 系列及 Intel 300 系列主板。並非所有主板都有該設置,在某些主板上還會造成啟動問題。
如果 BAR 大小為 256M,說明該特性尚未啟用或不受支持:
# dmesg | grep BAR=
[drm] Detected VRAM RAM=8176M, BAR=256M
如要啟用,需要在主板的設置中啟用 "Above 4G Decode" 或 ">4GB MMIO"。完成後檢查 BAR 是否變大:
# dmesg | grep BAR=
[drm] Detected VRAM RAM=8176M, BAR=8192M
內存、虛擬內存與內存溢出處理[編輯 | 編輯原始碼]
頻率和時序[編輯 | 編輯原始碼]
內存可在不同的頻率和時序上運行,可通過BIOS進行設置。兩者都會影響內存性能。選擇BIOS中系列預設值中最高的一個通常會帶來相比默認值的性能提升。將內存頻率提高到不被主板和內存廠商支持的數值被稱作超頻,由此帶來的風險與不便和#超頻中的相似。
在RAM overlay上配置根文件系統[編輯 | 編輯原始碼]
如果系統在寫入速率較慢的設備(如USB、機械硬碟)上運行且對根文件系統的寫入量較小,可在真實的根文件系統上掛載一層RAM overlay。這將保持 真實的根文件系統為只讀狀態,所有的寫入操作都在RAM中進行。由此可帶來顯著的性能提升,但根文件系統的寫入量將受到限制。
zram 或 zswap[編輯 | 編輯原始碼]
與#在RAM overlay上配置根文件系統相似的好處(當然也有相似的不便)也可通過zswap或zram達成。兩者的目的相同但實現方法不同:zswap依靠一塊壓縮的內存緩存來工作,不需要(也不允許)過多的用戶空間配置;而zram內核模塊可用於在內存中創建一個壓縮的塊設備。zswap需與swap設備配合工作,而zram則不需要。
使用顯存[編輯 | 編輯原始碼]
在很少見的情況下,內存很小而顯存過剩,那麼可以將顯存設為交換文件。見 Swap on video RAM.
在低內存情況下改善系統反應速度[編輯 | 編輯原始碼]
在傳統的GNU/Linux系統,尤其是圖形工作站上,當內存被過量分配(overcommitted)時,系統反應速度可能會在觸發內核的OOM-killer前迅速降低到無法使用的程度,除非足量的內存得到釋放。具體的過程會因特定的設置和系統所處的情況不同,導致系統回到正常狀態的時間從數秒到超過半個小時不等。
在低內存狀態下,內核的表現及用戶空間程序的情況可能在未來得到改善(詳見內核和Fedora的郵件列表)。此外,相比硬重啟和調整vm.overcommit_*
sysctl參數,用戶還可以使用更可行和有效的選擇:
- 使用Magic SysRq key(
Alt+SysRq+f
)手動觸發內核OOM-killer。 - 使用用戶空間的OOM守護進程來自動或交互性地處理低內存問題。
相比SysRq,OOM守護進程可能更受到歡迎,因為不能手動設定內核的OOM-killer結束相關進程的優先級。
以下是一些OOM守護進程:
- systemd-oomd —
systemd-oomd.service
由systemd提供,可使用cgroups-v2及PSI(pressure stall information)監控進程並在內核OOM發生前採取行動。
- earlyoom — 用C語言實現的簡單的用戶空間OOM-killer。
- oomd — 基於PSI的OOM-killer實現,需要4.20+版本的內核。配置文件為JSON格式且較複雜。已被確認應用於Facebook的生產環境。
- nohang — 用Python實現的複雜OOM handler,具有可選的PSI支持,比earlyoom的可配置性強。
- low-memory-monitor — 由GNOME開發,力圖為用戶空間應用程式提供更多的指示低內存狀態的交流方式。基於PSI,需要5.2+版本的內核。
- uresourced — 一個為圖形界面用戶會話提供基於cgroup的資源保護的微型守護進程。
網絡[編輯 | 編輯原始碼]
- 內核網絡設置: 詳見Sysctl#性能優化
- NIC: 詳見網絡配置#設定設備的 MTU 和隊列長度
- DNS: 考慮使用有緩存的DNS解析器,詳見域名解析#DNS 伺服器。
- Samba: 詳見Samba#Improve throughput。
看門狗[編輯 | 編輯原始碼]
- 看門狗計時器是一種檢測並從計算機故障中恢復的電子計時器。在正常情況下,計算機定期重置看門狗計時器。如果計算機未能重置計時器,計時便會一直持續直到產生超時信號。產生超時信號後將執行修正操作,一般包括使系統回到安全狀態並恢復正常的系統運作。
或由於系統的關鍵角色(如伺服器)或由於斷電重置(如在嵌入式設備上常發生的),許多用戶需要看門狗以在某些情況下保持系統的良好運作。然而,普通用戶(如使用普通台式機或筆記本)並不需要看門狗。
要關閉看門狗計時器(包含硬體及軟體實現),在啟動參數中加入nowatchdog
。
nowatchdog
啟動參數可能不適用於 Intel TCO 硬體看門狗 [4]。在這種情況下,可以使用 modprobe.blacklist=iTCO_wdt
內核參數禁用 TCO 的內核模塊。
如果使用的是AMD Ryzen CPU,檢查日誌中的sp5100-tco
相關輸出。sp5100-tco
是AMD 700晶片組系列中的硬體看門狗。要關閉它,編輯:
/etc/modprobe.d/disable-sp5100-watchdog.conf
blacklist sp5100_tco
或者使用modprobe.blacklist=sp5100_tco
內核參數。
要檢查新配置是否成功應用,執行 cat /proc/sys/kernel/watchdog
或 wdctl
。
因為加載的模塊更少,上述兩種關閉看門狗的方式都能提升系統的啟動和關機速度。此外,關閉看門狗計時器還能提升性能並降低電量消耗。
使用ALHP倉庫[編輯 | 編輯原始碼]
請參閱 ALHP 頁面。