性能優化

出自 Arch Linux 中文维基

本文將介紹與性能有關的系統診斷知識和具體步驟,通過減少資源消耗等方式優化系統性能。遊戲相關的特別優化請參閱 遊戲#性能優化

基礎[編輯 | 編輯原始碼]

了解你的系統[編輯 | 編輯原始碼]

性能優化的最佳方法是找到瓶頸或拖慢整體速度的子系統。查看系統細節可以幫助確定問題。

  • 如果在同時運行多個大型程序時卡頓(如 LibreOffice、Firefox 等),請檢查內存容量是否充足。使用以下命令,並檢查「available」一列的數值:
    $ free -h
  • 如果電腦開機很慢,並且(僅在)第一次打開應用時加載很慢,可能是因為硬盤速度過慢。可以用hdparm命令測試硬盤速度:
    # hdparm -t /dev/sdX
注意: hdparm 只代表了硬盤的讀取速度,並沒有進行有效的評分。空閒時讀取速度只要高於 40MB/s 就可以滿足大多數系統。
  • 如果內存足夠而 CPU 佔用率居高不下,可以嘗試停止進程或禁用 守護服務。有多種方法可以監測 CPU 負荷,例如 htoppstree 或其他 系統監視器
    $ htop
  • 如果使用直接渲染(GPU 渲染)的應用運行卡頓(比如使用 GPU 的視頻播放器、遊戲甚至窗口管理器),改善 GPU 的性能應當有所幫助。首先需要檢查直接渲染是否已經開啟。可以使用 mesa-utils 中的 glxinfo 命令:
    $ glxinfo | grep "direct rendering"
    ,如果開啟了,則會返回direct rendering: Yes
  • 使用 桌面環境時,禁用桌面特效或許可以減少 GPU 使用。如果當前的桌面環境不符合硬件或個人需求,可以使用一個更輕量的桌面環境或 自己打造桌面環境
  • 使用專門優化過的 內核 可以提高性能,比如可以選擇 linux-zen,本文中的一些配置也可以優化默認內核的性能。

基準測試[編輯 | 編輯原始碼]

為定量評估優化成果,可使用基準測試

存儲設備[編輯 | 編輯原始碼]

多硬件路徑[編輯 | 編輯原始碼]

內部硬件路徑意指儲存設備是如何連接到主板的。例如 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) 是舊版本所擁有的調度器:
    • NOOP 是最簡單的調度器,它將所有的I/O請求放入一個先進先出隊列(FIFO)並以此實現請求合併。 在這個算法中,請求的位置的扇區號不會被用於排序。 因此,如果在另一層(例如設備級), 或者無論怎樣的調度算法都不會帶來性能問題( 例如SSD),那麼就可以使用這個算法。
    • Deadline
    • CFQ
注意: 單隊列調度器(single-queue schedulers)自從Linux 5.0起被移除.

更改 I/O 調度器[編輯 | 編輯原始碼]

注意: 調度器需要根據設備及負載的具體狀況進行選擇。另外,不應只根據以 MB/s 計量的吞吐量作為性能判斷的唯一標準:到期時間或公平度會影響總體的吞吐性能,但同時會提高響應性能。基準測試 章節有助幫你判斷各個 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 規則 以使更改在啟動時應用。

提示:GNOME 允許你在磁盤應用中配置部分這些參數,不需要編輯 udev 規則。
注意: 你的硬盤可能不支持部分功能。這種情況下,Hdparm 會向你發出提醒。你可以直接忽視掉這些不支持的配置選項。

減少磁盤讀寫[編輯 | 編輯原始碼]

避免對慢速存儲設備的不必要訪問不僅可以提升性能,還能延長設備壽命(不過,在現代硬件上往往可以忽略這些操作對設備壽命的影響)。

注意: 一個具有10倍寫入放大因子、10000 write/erase cycle的普通32GB SSD,若每天寫入10GB數據,仍有8年的預期壽命。對於具有更新的主控,因而寫入放大更少的SSD和容量更大的SSD,預期壽命將更長。此外,在考慮是否需要限制磁盤寫入量前,參見該實驗

顯示磁盤寫信息[編輯 | 編輯原始碼]

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

詳見:一個ionice的簡短介紹ionice(1)

CPU[編輯 | 編輯原始碼]

超頻[編輯 | 編輯原始碼]

超頻通過提升 CPU 的時鐘頻率提升電腦性能,超頻能力取決於 CPU 和主板的型號。通常使用 BIOS 進行超頻。超頻也會帶來風險和不便,這裏既不推薦超頻也不反對超頻。

很多 Intel 晶片不會在 acpi_cpufreq 或其他軟件中報告真正的時鐘頻率,這會導致過多的 dmesg 消息。通過卸載並將 acpi_cpufreq 模塊加入黑名單可以避免此問題。使用 i7z 中的 i7z 可以讀取真實的時鐘速度。對於正確的 CPU 超頻方式而言,推薦使用 壓力測試

自動調整頻率[編輯 | 編輯原始碼]

CPU 調頻

調整默認CPU調度器(CFS)[編輯 | 編輯原始碼]

mainline Linux內核中的默認CPU調度器是EEVDF

這篇文章的某些內容需要擴充。

原因: Add CFS, the previous default scheduler, to the list. (在 [[1]] 中討論)

其他CPU調度器[編輯 | 編輯原始碼]

  • MuQSS — Multiple Queue Skiplist Scheduler. Available with the -ck patch set developed by Con Kolivas.
Unofficial user repositories/Repo-ck || linux-ckAUR
  • PDS — Priority and Deadline based Skiplist multiple queue scheduler focused on desktop responsiveness.
https://cchalpha.blogspot.com/ || linux-pdsAUR
  • 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.
https://cchalpha.blogspot.com/ || linux-cachyos-bmqAUR
  • 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.
https://cchalpha.blogspot.com/ || linux-prjcAUR
  • 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.
https://github.com/hamadmarri/TT-CPU-Scheduler || linux-ttAUR
  • 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.
https://github.com/firelzrd/bore-scheduler || linux-cachyos-boreAUR

實時內核[編輯 | 編輯原始碼]

有些應用(如在全高清(1080p)解像度下運行電視卡)可能在實時內核下表現更好。

調整進程優先級[編輯 | 編輯原始碼]

nice(1)renice(1)

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漏洞緩解措施[編輯 | 編輯原始碼]

警告: 不要在充分考慮導致的漏洞前應用這些設置。更多信息見:[2][3]

關閉CPU漏洞緩解措施可能提升性能。 要完全關閉CPU漏洞緩解措施,使用如下內核參數:

mitigations=off

該內核參數改變的所有設置的詳細解釋可在kernel.org|這裏找到。 可以使用spectre-meltdown-checkerAUR 或者 util-linux 提供的 lscpu(1) 進行漏洞檢測

注意: 當使用10代之後的Intel CPU或Ryzen 1000系列之後的AMD CPU時, 關閉CPU漏洞緩解措施帶來的性能提升小於5%(而不是之前產品的多達25%)。詳見the general review from early 2021the test on Rocket Lakethe test on Alder Lake

顯卡[編輯 | 編輯原始碼]

Xorg 配置[編輯 | 編輯原始碼]

顯卡性能由/etc/X11/xorg.conf的配置決定,見 NVIDIAAMDGPUIntel 文章。配置不當可能導致 Xorg 停止工作,請慎重操作。

Mesa 配置[編輯 | 編輯原始碼]

Mesa驅動的性能可通過drirc配置。此外,也可通過GUI工具進行配置:

  • adriconf (Advanced DRI Configurator) — 通過GUI進行配置並向標準drirc文件寫入配置項的工具。
https://gitlab.freedesktop.org/mesa/adriconf/ || adriconf
  • DRIconf — 用於Direct Rendering Infrastructure的配置小程序。支持在應用/屏幕/設備層面上調整OpenGL的性能和視覺效果設置。
https://dri.freedesktop.org/wiki/DriConf/ || driconfAUR

硬件視頻加速[編輯 | 編輯原始碼]

硬件視頻加速可利用顯卡解碼/編碼視頻。

超頻[編輯 | 編輯原始碼]

與 CPU 一樣,超頻可以直接提高性能,但通常不建議使用。AUR中的超頻工具有rovclockAUR (ATI 顯卡)、rocm-smi-lib (較新的 AMD 顯卡) 、nvclockAUR (到 Geforce 9系的舊 NVIDIA 顯卡),以及適用於新 NVIDIA 顯卡的nvidia-utils

AMDGPU#OverclockingNVIDIA/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上配置根文件系統相似的好處(當然也有相似的不便)也可通過zswapzram達成。兩者的目的相同但實現方法不同:zswap依靠一塊壓縮的內存緩存來工作,不需要(也不允許)過多的用戶空間配置;而zram內核模塊可用於在內存中創建一個壓縮的塊設備。zswap需與swap設備配合工作,而zram則不需要。

使用顯存[編輯 | 編輯原始碼]

在很少見的情況下,內存很小而顯存過剩,那麼可以將顯存設為交換文件。見 Swap on video RAM.

在低內存情況下改善系統反應速度[編輯 | 編輯原始碼]

在傳統的GNU/Linux系統,尤其是圖形工作站上,當內存被過量分配(overcommitted)時,系統反應速度可能會在觸發內核的OOM-killer前迅速降低到無法使用的程度,除非足量的內存得到釋放。具體的過程會因特定的設置和系統所處的情況不同,導致系統回到正常狀態的時間從數秒到超過半個小時不等。

在低內存狀態下,內核的表現及用戶空間程序的情況可能在未來得到改善(詳見內核Fedora的郵件列表)。此外,相比硬重啟和調整vm.overcommit_* sysctl參數,用戶還可以使用更可行和有效的選擇:

  • 使用Magic SysRq keyAlt+SysRq+f)手動觸發內核OOM-killer。
  • 使用用戶空間的OOM守護進程來自動或交互性地處理低內存問題。
警告: 觸發OOM killer將強行停止某些正在運行的應用,可能導致未保存的工作丟失。是耐心等待並希望應用程式最終會釋放掉佔用的內存,還是迅速使系統脫離未響應狀態取決於用戶自身。

相比SysRq,OOM守護進程可能更受到歡迎,因為不能手動設定內核的OOM-killer結束相關進程的優先級。

以下是一些OOM守護進程:

  • systemd-oomdsystemd-oomd.servicesystemd提供,可使用cgroups-v2及PSI(pressure stall information)監控進程並在內核OOM發生前採取行動。
https://github.com/systemd/systemd, systemd-oomd(8) || systemd
  • earlyoom — 用C語言實現的簡單的用戶空間OOM-killer。
https://github.com/rfjakob/earlyoom || earlyoom
  • oomd — 基於PSI的OOM-killer實現,需要4.20+版本的內核。配置文件為JSON格式且較複雜。已被確認應用於Facebook的生產環境。
https://github.com/facebookincubator/oomd || oomdAUR
  • nohang — 用Python實現的複雜OOM handler,具有可選的PSI支持,比earlyoom的可配置性強。
https://github.com/hakavlad/nohang || nohang-gitAUR
  • low-memory-monitor — 由GNOME開發,力圖為用戶空間應用程式提供更多的指示低內存狀態的交流方式。基於PSI,需要5.2+版本的內核。
https://gitlab.freedesktop.org/hadess/low-memory-monitor/ || low-memory-monitor-gitAUR
  • uresourced — 一個為圖形界面用戶會話提供基於cgroup的資源保護的微型守護進程。
https://gitlab.freedesktop.org/benzea/uresourced || uresourcedAUR

網絡[編輯 | 編輯原始碼]

看門狗[編輯 | 編輯原始碼]

根據Wikipedia:Watchdog timer:

看門狗計時器是一種檢測並從計算機故障中恢復的電子計時器。在正常情況下,計算機定期重置看門狗計時器。如果計算機未能重置計時器,計時便會一直持續直到產生超時信號。產生超時信號後將執行修正操作,一般包括使系統回到安全狀態並恢復正常的系統運作。

或由於系統的關鍵角色(如伺服器)或由於斷電重置(如在嵌入式設備上常發生的),許多用戶需要看門狗以在某些情況下保持系統的良好運作。然而,普通用戶(如使用普通台式機或筆記本)並不需要看門狗。

要關閉看門狗計時器(包含硬件及軟件實現),在啟動參數中加入nowatchdog


nowatchdog 啟動參數可能不適用於 Intel TCO 硬件看門狗 [4]。在這種情況下,可以使用 modprobe.blacklist=iTCO_wdt 內核參數禁用 TCO 的內核模塊。

如果使用的是AMD Ryzen CPU,檢查日誌中的sp5100-tco相關輸出。sp5100-tcoAMD 700晶片組系列中的硬件看門狗。要關閉它,編輯:

/etc/modprobe.d/disable-sp5100-watchdog.conf
blacklist sp5100_tco

或者使用modprobe.blacklist=sp5100_tco 內核參數。


要檢查新配置是否成功應用,執行 cat /proc/sys/kernel/watchdogwdctl

因為加載的模塊更少,上述兩種關閉看門狗的方式都能提升系統的啟動和關機速度。此外,關閉看門狗計時器還能提升性能並降低電量消耗

另見[5][6][7],和[8]

參閱[編輯 | 編輯原始碼]