6.3. 設定工具

Red Hat Enterprise Linux 提供一系列工具，以協助系統管理員設定系統。本章節概述可使用的工具，以及提供這些工具可以如何運用，以解決 Red Hat Enterprise Linux 7 中有關網路效能的問題。
然而，重要的是知道網絡性能問題有時是由硬件故障或錯誤基礎結構導致的。Red Hat 極力建議在使用這些工具來調整網路堆疊前，檢查您硬件和基礎結構是正常運行的。
此外，透過更改應用程式比重新設定網路子系統，能夠更有效地解決一些網路效能問題。大體來說，設定您的應用程式以履行頻繁的 posix 呼叫是一個好的方法，因為這使資料能夠更有彈性的儲存，並根據所需在記憶體中調換，即使這意味著需要在應用程式空間佇列資料。

6.3.1. 網路效能的 Tuned-adm 設定檔

tuned-adm 提供一系列不同的設定檔，以改善一些特定使用案件的效能。以下設定檔有益於改善網路效能。
  • 延遲效能
  • 網路延遲
  • 網路輸送量
更多有關以上設定檔的詳細資訊，請參閱〈 節 A.6, “tuned-adm”〉。

6.3.2. 設定硬體緩衝

若大量 packets 由硬體緩衝卸除，系統將有一些可能的解決方案。
放慢輸入流量
過濾傳入的流量、減少加入的群播群組或減少播放數量，以降低佇列的投放率。更多有關如何篩選輸入流量的詳細資訊，請參閱《Red Hat Enterprise Linux 7 安全性指南》。更多有關群播群組的詳細資訊，請參閱 Red Hat Enterprise Linux 7 叢集文件。更多有關播放流量的詳細資訊，請參閱《Red Hat Enterprise Linux 7 系統管理員參考指南》或與您想設定的設置有關的文件。所有 Red Hat Enterprise Linux 7 文件可以自以下網址取得：〈http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/〉。
重新調整硬體緩衝佇列大小
透過增加佇列大小，降低卸除的封包數量，使佇列不易溢位。您可以使用 ethtool 命令，修改網路裝置的 rx/tx 參數： 
# ethtool --set-ring devname value
更改佇列的流失率
設置重量指的是一個設置一次能接收到的封包數量（於單一預定的處理器存取）。透過增加設置重量，佇列流失率會增加，而設置重量是由「dev_weight」參數管理。透過改變 /proc/sys/net/core/dev_weight 檔案的內容，此參數能夠暫時被更改，或永久地更改為「sysctl」，由 procps-ng 套件提供。
更改佇列流失率通常是降低不好的網路效能最簡單的方法。然而，增加一個裝置一次能接收的封包數量，會使用額外的處理器時間，且在這期間不能排程其他處理器，因此可能造成其他效能問題。

6.3.3. 設定中斷佇列

若分析顯示高度延遲，您的系統將能受益於以輪詢為基礎的封包回條，而非以中斷為基礎的封包回條。

6.3.3.1. 配置忙碌輪詢

忙碌輪詢透過讓通訊端層代碼輪詢接收一網路裝置的佇列與停用網路中斷，以協助降低在網路接收路徑上的延遲。這將移除由中斷造成的延遲，和可能構成的內容切換。然而，這也增加了 CPU 使用量。忙碌輪詢也避免 CPU 處於休眠狀態而導致額外的能源消耗量。
忙碌輪詢在預設情況下是停用的。欲在特定通訊端啟用忙碌輪詢，請按以下步驟操作。
  • 設定「sysctl.net.core.busy_poll」至一個非「 0」的值。此參數將控制微秒數量，等待位於裝置佇列的封包用於通訊端輪詢和挑選。 Red Hat 建議「 50」值。
  • 增加「 SO_BUSY_POLL」通訊端選項至通訊端。
欲整體性啟用忙碌輪詢， 您必須也設定「sysctl.net.core.busy_read」至一個非「0」的值。此參數將控制微秒數量，以等待位於裝置佇列上的封包用於通訊端取讀。此參數亦設定「SO_BUSY_POLL」選項的預設值。Red Hat 建議「50」值用於一個較少數量的通訊端，和 「100」值用於較多數量的通訊端。若用於極大數量多通訊端（多於數百），請使用「epoll」。
忙碌輪詢行為是由以下驅動程式支援。這些驅動程式亦支援 Red Hat Enterprise Linux 7。
  • bnx2x
  • be2net
  • ixgbe
  • mlx4
  • myri10ge
截至 Red Hat Enterprise Linux 7.1，您也可以操作以下命令以檢查一個特定的裝置是否支援忙碌輪詢。 
# ethtool -k device | grep "busy-poll"
若傳回「busy-poll: on [fixed]」，忙碌輪詢就能於裝置上使用。

6.3.4. 設定通訊端接收佇列

若分析顯示通訊端因通訊端佇列的流失率過於緩慢而被解除，有一些方法能夠減少因而造成的效能問題。
降低傳入流量的速度
透過在封包延伸至佇列前或透過降低裝置重量，篩選或卸除封包以降低佇列填滿的速率。
增加應用程式通訊端佇列的深度
若一通訊端佇列在高載時接收有限數量的流量，增加通訊端深度以符合流量的高載大小，能夠避免封包被卸除。

6.3.4.1. 降低傳入流量的速度

篩選傳入流量或降低網路介面卡的裝置重量，以減緩傳入流量。更多有關如何篩選傳入流量的詳細資訊，請參閱《Red Hat Enterprise Linux 7 安全性指南》，可自以下網址取得：〈http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/〉。
裝置重量指的是一個裝置一次能接收的封包數量（在一個單一排程處理器存取）。裝置重量是由「dev_weight」參數管理。透過修改 「/proc/sys/net/core/dev_weight」檔案的內容，或與「sysctl」永久更動（由 procps-ng 套件提供），此參數可以暫時被更動。

6.3.4.2. 增加佇列深度

增加一應用程式通訊端佇列的深度，通常是改善通訊端佇列流失率最簡單的方法，但這不太可能是長期的解決方法。
欲增加佇列深度，請透過以下變更增加通訊端接收緩衝區的大小：
增加 /proc/sys/net/core/rmem_default 的值
此參數控制通訊端使用的接收緩衝區的預設大小。此值必須小於/proc/sys/net/core/rmem_max 的值。
使用 setsockopt 以設定一較大的 SO_RCVBUF 值
此參數以位元組控制通訊端接收緩衝區的最大大小。使用「getsockopt」系統呼叫，以決定緩衝區當前的值。 更多有關此參數的詳細資訊，請參閱 man page： 
$ man 7 socket

6.3.5. 配置接收端縮放比例（RSS）

接收端縮放比例（RSS），又稱多佇列接收，均分網路接收程序於數個硬體基礎的接收佇列，使多個 CPU 能夠處理傳入的網路流量。RSS 可以減少因單一 CPU 過載而造成的接收中斷處理的瓶頸，也可以降低網路延遲。
欲決定您網路介面卡是否支援 RSS，請檢查多中斷請求佇列是否與「/proc/interrupts」聯繫。例如：若您對「p1p1」介面有興趣： 
# egrep 'CPU|p1p1' /proc/interrupts
   CPU0    CPU1    CPU2    CPU3    CPU4    CPU5
89:   40187       0       0       0       0       0   IR-PCI-MSI-edge   p1p1-0
90:       0     790       0       0       0       0   IR-PCI-MSI-edge   p1p1-1
91:       0       0     959       0       0       0   IR-PCI-MSI-edge   p1p1-2
92:       0       0       0    3310       0       0   IR-PCI-MSI-edge   p1p1-3
93:       0       0       0       0     622       0   IR-PCI-MSI-edge   p1p1-4
94:       0       0       0       0       0    2475   IR-PCI-MSI-edge   p1p1-5
此前置結果顯示 NIC 驅動程式「p1p1」介面建立了 6 個接收佇列（p1p1-0 至 p1p1-5）。 這也顯示有多少中斷是由各個佇列處理，以及哪一 CPU 處理了中斷。在此情況下，將會有 6 個佇列，因為在預設情況下，此特定 NIC 驅動程式建立一個 CPU 對一個佇列，且此系統有 6 個 CPU。這是一個在 NIC 驅動程式裏較為常見的模式。
另外，您可以檢查「ls -1 /sys/devices/*/*/device_pci_address/msi_irqs」的輸出，於網路驅動程式負載之後。例如：若您對一個有 0000:01:00.0 PCI 位置的裝置有興趣，您可以列出其裝置的中斷請求佇列，用以下命令： 
# ls -1 /sys/devices/*/*/0000:01:00.0/msi_irqs
101
102
103
104
105
106
107
108
109
在預設情況下，RSS 是啟動的。RSS 的佇列數量（或應該處理網路活動的 CPU ）是設定在一個合適的網路裝置驅動程式。bnx2x 驅動程式是設定在「num_queues」。sfc 驅動程式是設定在「rss_cpus」參數。除此之外，RSS 通常是設定在「/sys/class/net/device/queues/rx-queue/」，其中「device」為網路裝置的名稱（例如： 「eth1」）且「 rx-queue」為合適的接收佇列名稱。
設定 RSS時，Red Hat 建議限制佇列數量至一個佇列對一個實體 CPU 核心。超線程在分析工具中，通常代表分隔的核心，但為所有的核心（包括如超線程的邏輯核心）設定佇列並沒有被證實是對網路效能有益。
RSS 啟動時，RSS 將以各個 CPU 排列的處理數量，在可使用的 CPU 當中均分網路處理，然而，您也可以使用 ethtool --show-rxfh-indir 與 --set-rxfh-indir 參數，以修改網路活動應如何分配，以及權衡較其他活動更為重要的特定網路活動。
irqbalance daemon 可以連同 RSS 一起用於降低跨節點記憶體轉換的可能性，以及快取線回升（cache line bouncing）。這將降低處理網路封包的延遲。

6.3.6. 配置接收封包操控

接收封包操控 （RPS）與 RSS 相似，兩者皆用於引導封包至特定 CPU 處理。然而，RPS 是置入在軟體層面，並協助避免單一網路介面卡的硬體佇列成為網路流量的瓶頸。
RPS 與以硬體為基礎的 RSS 相比，有以下數個好處：
  • RPS 可以與任何網路介面卡一起使用。
  • 非常容易增加軟體篩選至 RPS 以處理新的通訊協定。
  • RPS 並不會增加網路裝置的硬體中斷率。然而，RPS 會引入處理器之間的中斷。
RPS 是按網路裝置和接收佇列設定，位於「/sys/class/net/device/queues/rx-queue/rps_cpus」檔案，其中「device」為網路裝置的名稱（例如：「eth0」），且「rx-queue 」為合適的接收佇列名稱（例如：「rx-0」）。
「rps_cpus」檔案的預設值為「0」。這將停用 RPS，如此，處理網路中斷的 CPU 亦能處理套件。
欲啟動 RPS，請使用應當處理來自特定網路裝置和接收佇列的 CPU ，來設定合適的「rps_cpus」檔案。
「rps_cpus」檔案使用逗號分格 CPU 點陣圖（ comma-delimited CPU bitmaps）。因此，欲使 CPU 能夠為介面上的接收佇列處理中斷，請設定點陣圖中 CPU 的位置值至 1。例如：欲使用值為 0、 1、2 和 3 的 CPU 處理中斷，請設定 「rps_cpus」值至「00001111」 （1+2+4+8），或 「f」（十六進位值為15）。
對於單一傳輸佇列的網路裝置，可以透過設定 RPS 使用同一記憶體網域的 CPU ，達到最佳效能。在非 NUMA 系統上，這意味著所有現有的 CPU 皆可使用。若網路中斷率非常的高，排除處理網路中斷的 CPU 也可能改善效能。
對於多佇列的網路裝置，設定 RPS 和 RSS 兩者通常沒有益處，因為在預設情況下，RSS 的設定是為對應 CPU 至個接收佇列。然而，若硬體佇列較 CPU 佇列少，且 RPS 是設定去使用同一記憶體網域的 CPU，RPS 可能保持有益。

6.3.7. 配置接收封包操控 （RFS）

接收封包操控（RFS）擴展 RPS 行為以增加 CPU 快取命中率，並因此減少網路延遲。在 RPS 僅僅根據佇列長度而轉發套件，RFS 使用 RPS 後端計算最合適的 CPU，然後根據消耗套件的應用程式的位置，轉發套件。這將增加 CPU 緩存效率。
在預設情況下，RFS 是停用的。欲啟動 RFS，您必須編輯以下兩個檔案：
/proc/sys/net/core/rps_sock_flow_entries
設定此檔案值至使用中的並行連線的最大期望值。對於中等伺服器載量，我們建議其值為「32768」。 實際上，所有輸入的值皆會四捨五入至最近的次方。
/sys/class/net/device/queues/rx-queue/rps_flow_cnt
以一個您欲設定的網路裝置名稱取代「device」（例如：「eth0」），並以一個您欲設定的接收佇列取代 「rx-queue」（例如：「rx-0」）。
設定此檔案的值至「rps_sock_flow_entries」 ，除以「N」，其中「N 」為裝置上接收佇列的數量。例如：若「rps_flow_entries」被設定為「32768」，且有 16 個接收佇列，「rps_flow_cnt」應該設定為「2048」。對於單一佇列裝置，「rps_flow_cnt」的值與「rps_sock_flow_entries」的值相同。
自一單一傳送者接收到的資料並不會傳送至一個以上的 CPU。若自一單一傳送者接收到的資料量大於單一 CPU 能夠處理的數量，請設定一個較大的框架大小，以減少中斷次數以及 CPU 處理的工作量。或者，考慮使用 NIC 承載選項或更快速的 CPU。
考慮使用「numactl」或「taskset」 連同 RFS，以釘選應用程式至特定核心、通訊端或 NUMA 節點。這能夠避免套件被不合乎規程的方式受處理。

6.3.8. 設定加速 RFS

加速 RFS （Accelerated RFS）透過增加硬體協助來加強 RFS 速度。如同 RFS，套件的轉寄是根據消耗該套件的應用程式的位置。然而，不同於傳統 RFS 的是。封包是直接傳送至 CPU，而此 CPU 是消耗資料的本機線程：執行應用程式的 CPU，或者一緩存層級的本機 CPU 。
增速 RFS 只在以下情況符合時方可行使：
  • 增速 RFS 必須由網路介面卡支援。增速 RFS 是由輸出 ndo_rx_flow_steer() netdevice 功能的介面卡支援。
  • ntuple 篩選必須是啟動的。
一旦這些條件符合，CPU 至佇列對應將會根據傳統 RFS 設定自動將低。亦即 CPU 至佇列對應的降低，是根據驅動程式為各個接收佇列設定的 IRQ 親和性。有關設定傳統 RFS 的詳細資訊，請參閱〈節 6.3.7, “配置接收封包操控 （RFS）”〉。
Red Hat 建議在任何適當的情況下，以及在網路介面卡支援硬體增速時，使用增速 RFS。