一 CPU 調優
1 系統拓撲
1 概述
在現代計算機技術中，大部分的系統都是擁有多個處理器的，多個處理器之間的連接並連接其他資源則需要通過系統拓撲來調節以產生影響
2 現代計算機技術的兩種拓撲類型
1 SMP(對稱多處理器)
SMP(對稱多處理器)拓撲允許所有的處理器同時訪問內存，然而，由於內存訪問權限的共享性和平等性，固然會迫使所有的CPU和SMP系統序列化的內存訪問權限侷限性能加，目前這種情況是不被接受的，因此，現在服務器系統都是NUMA(非一致性內存訪問)機制。
2 NUMA 拓撲(非一致性內存訪問機制)
比起 SMP 拓撲，NUMA(非一致性內存訪問)拓撲是近來纔開發的，在NUMA系統中，多個處理器物理分組至一個socket，每個socket都由一個專用內存區，對該內存進行本地訪問的服務器系統稱爲一個節點。
同一個節點上的服務器能夠高速訪問該節點的存儲體，但訪問其他節點的存儲體速度就比較慢，因此，訪問非本地存儲體會造成性能的損失。
3 NUMA 拓撲調節注意事項
考慮到性能損失，服務器執行應用程序時，NUMA 拓撲結構系統中對性能敏感的應用程序應訪問同一節點的內存，並且應儘可能地避免訪問任何遠程內存。
因此，在調節 NUMA 拓撲結構系統中的應用程序性能時，重要的是要考慮這一應用程序的執行點以及最靠近此執行點的存儲體。
在 NUMA 拓撲結構系統中，/sys 文件系統包含處理器、內存及外圍設備的連接信息。
/sys/devices/system/cpu 目錄包含處理器在系統中相互連接的詳情。 /sys/devices/system/node 目錄包含系統中 NUMA 的節點信息以及節點間的相對距離。
4 確定系統拓撲結構
1 使用 numactl --hardware 指令描述系統的拓撲結構
[root@python ~]# numactl --hardware
available: 1 nodes (0) # 內存只有一個
node 0 cpus: 0 1 2 3
node 0 size: 4095 MB
node 0 free: 177 MB
node distances:
node 0
0: 102 使用 lscpu 指令來查詢
其指令由util-linux 數據包提供，包括CPU體系結構信息，如CPU數量，線程數，內核數，socket數量以及NUMA節點數等。
[root@python ~]# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 2
座： 2
NUMA 節點： 1
廠商 ID： GenuineIntel
CPU 系列： 6
型號： 158
型號名稱： Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
步進： 9
CPU MHz： 3408.003
BogoMIPS： 6816.00
虛擬化： VT-x
超管理器廠商： VMware
虛擬化類型： 完全
L1d 緩存： 32K
L1i 緩存： 32K
L2 緩存： 256K
L3 緩存： 6144K
NUMA 節點0 CPU： 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ibrs ibpb stibp tpr_shadow vnmi ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid mpx rdseed adx smap clflushopt xsaveopt xsavec arat spec_ctrl intel_stibp arch_capabilities2 調度
系統調度器決定運行線程的處理器和運行的時間。但由於調度器主要關注的是保持系統繁忙，因此可能不會爲應用程序的性能而對線程進行最佳調度。
例，在NUMA系統中，一個處理器在節點B可用，一個應用程序在節點A運行，要使在節點B的處理器保持忙碌，調度器會把應用程序的一個線程轉移到節點B。但是，線程上的應用程序仍然需要訪問在節點A的內存。由於該線程目前在節點B運行，並且對於此線程來說節點A的內存已不再是本地內存，訪問起來就要花更長的時間。較於在節點A等待可用的處理器，並且在能夠進行本地內存訪問的源節點上執行線程，此線程在節點B結束運行可能就更加費時。
1 內核滴答信號
滴答信號: 早起Linux 版本中，Linux內核會定期終端每個CPU已查看需要完成的任務，查看的結果用來決定進程調度及負載均衡，這便是滴答信號
缺點：此標記不會考慮內核是否有任務要執行，這使得即使空閒的內核也會被迫定期進入高能狀態，這阻止了系統有效的利用x86代處理器的深睡眠狀態
按需中斷:
默認的redhat 6和7內核不再中斷趨於低功率狀態的空閒CPU， 當一個或幾個任務在運行時，按需中斷取代了定時中斷，使得CPU可以更長久的處於空閒狀態或低功率狀態用以減少電量的消耗。
動態無時鐘設置：
Linux redhat 7 提供一種動態的無時鐘設置(nohz_full)，通過用戶空間的任務來減少內核干擾以進一步改善其確定性。這一設置可以在指定的內核中通過 nohz_full 內核參數來啓用。當這一設置在一個內核中啓用時，所有的計時活動將會被移動至無延遲敏感性的內核。這對於高性能計算和實時計算工作負載來說都很有用，因爲其用戶空間任務對由於內核計時器滴答信號造成的微秒級的延遲尤爲敏感。
2 中斷請求管理(Interrupt ReQuest)
中斷請求或 IRQ 是請求及時關注的信號，是從硬件發送至處理器的。系統中的每個設備都分配到一個或多個 IRQ 號，以便能發送獨一的中斷信號。當啓用中斷時，收到中斷請求的處理器會立即暫停執行當前應用程序線程，這是爲了處理該中斷請求。 因爲中斷了正常的運行，高中斷率會嚴重降低系統性能，但減少中斷事件是可能的，可以設置中斷關聯或發送一批低優先率的中斷（“組合中斷”）來處理此種情況。
3 監控和診斷性能問題
1 turbostat
Turbostat 在規定的間隔中給出計時器的結果以協助管理員識別服務器異常，例如過度耗電，無法進入深睡 眠狀態或是創建了不必要的系統管理中斷（SMIs）。
turbostat 工具是 內核工具 數據包的一部分。支持在 AMD 64 和 Intel® 64 處理器的系統中使用。需要 root 特權來運行，處理器支持時間戳計時器以及 APERF 和 MPERF 型號的特定寄存器。
2 numastat
numastat 工具會列舉每個 NUMA 節點內存數據給所有的進程和操作系統，並會告知管理員進程內存是散佈於系統還是集中於某個節點。
通過處理器的 top 輸出進行交互參照 numastat 輸出，以確認進程線程是在同一個節點運行，此節點是進程內存分配節點。
[root@centos8 ~]# numastat
node0
numa_hit 4372424
numa_miss 0
numa_foreign 0
interleave_hit 19604
local_node 4372424
other_node 0
numa_hit 爲這個節點成功的分配嘗試次數
numa_miss 由於在目的節點中內存較低而嘗試爲這個節點分配到另一個節點的數目，每個numa_miss事件都在另一個節點中有對應的numa_foregin 事件。
numa_foreign 最初要爲這個節點但最後分配另一個節點的分配數，每個numa_foregin 事件都在另一個節點中有對應的numa_miss 事件
3 /proc/中斷
/proc/interrupts 文件列舉了從一個特殊的 I/O 設備發送至各處理器的中斷數量，顯示了中斷請求 （IRQ）數量、系統中各處理器處理該類型中斷請求的數量，發送的中斷類型以及以逗號分隔開的迴應所列中斷請求的設備列表。
如果一個特定的應用程序或是設備生成大量的中斷請求給遠程處理器處理，其性能就會受到影響。這種情況 下，當應用程序或設備在處理中斷請求時，可以在同一節點設置一個處理器，以此來緩解性能不佳的狀況。將 中斷處理分配給特定處理器的方法.
4 配置建議
默認情況下，Redhat 7 使用無時鐘內核，其不會中斷空閒CPU來減少用電量，並允許較新的處理器利用深睡眠狀態。
紅帽企業版 Linux 7 同樣提供一種動態的無時鐘設置（默認禁用），這對於延遲敏感型的工作負載來說是很有幫助的，例如高性能計算或實時計算。
5 配置內核滴答信號時間
要啓用特定內核中的動態無時鐘性能，在內核命令行中用 nohz_full 參數進行設定。在16 核的系統中，設定 nohz_full=1-15 可以在 1 到 15 內核中啓用動態無時鐘內核性能，並將所有的計時移動至唯一未設定的內核中（0 內核）。這種性能可以在啓動時暫時啓用，也可以在 /etc/default/grub 文件中永久啓用。 要持續此性能，請運行 grub2-mkconfig -o /boot/grub2/grub.cfg 指令來保存配置。
啓動動態無時鐘性能需要一些手一動管理
當系統啓動時，必須手動將rcu線程移動到對延遲不敏感的內核，這種情況下爲0內核。
for i in `pgrep rcu` ; do taskset -pc 0 $i ; done在內核命令行上使用 isolcpus 參數來將特定的內核與用戶空間任務隔離開。 可以選擇性地爲輔助性內核設置內核回寫式 bdi-flush 線程的 CPU 關聯：
echo 1 > /sys/bus/workqueue/devices/writeback/cpumask 驗證動態無時鐘配置是否正常運行，執行以下命令，其中 stress 是在 CPU 中運行 1 秒的程序。
perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1默認的內核計時器配置在繁忙 CPU 中顯示1000 次滴答記號：
# perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1 1000 irq_vectors:local_timer_entry 動態無時鐘內核配置下，用戶只會看到一次滴答記號：
# perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1
1 irq_vectors:local_timer_entry6 設置硬件性能策略
x86_energy_perf_policy 工具允許管理員定義性能與能效的相對重要性。當處理器在性能與能效間權衡選 擇時，此信息可用來改變支持這一特徵的處理器。
默認情況下適用於所有在 performance 模式下的處理器，它要求處理器的支持，由 CPUID.06H.ECX.bit3 顯示，且必須在有 root 特權的情況下運行。 x86_energy_perf_policy 由 kernel-tools 數據包提供。如何使用 x86_energy_perf_policy
7 使用taskset 設置處理器關聯
taskset 工具由 util-linux 數據包提供。Taskset 允許管理員恢復和設置進程中的處理器關聯，或通過特定的 處理器關聯來啓動一個進程。
1 使用 taskset 設置CPU的親和性
taskset搜索並設定運行進程的CPU親和性(根據進程ID)，他還可以用於啓動給CPU親和性的進程，這個就可以將指定的進程與指定的CPU或者一組CPU進行捆綁，但taskset不保證本地內存分配。
如果想需要本地內存分配給額外性能利益，則建議使用numacl
CPU的親原形使用位掩碼錶示，最低位對應第一個邏輯CPU，且最高位對應最後一個邏輯CPU，這些掩碼通常是十六進制，因此 0x00000001 代表處理器0 表示爲0001 0x00000009 代表處理器3 和 1 表示爲1001
設置CPU和進程的親和性
要想設定運行進程的CPU親和性，執行 taskset -p mask pid 進行處理
要啓動給定親和性的進程，執行
taskset mask --program -c 指定綁定在哪個cpu上
taskset -c 0,1,2,3 --myprogram 查看進程運行在哪個CPU上
ps axo pid,psr PSR 運行在哪個處理器上
ps axo pid,psr | grep pid 
上述綁定方式只能實現一個進程運行在這個CPU上，但不能保證別的進程不運行在對應的CPU上，如果需要，必須在操作系統日誌啓動之前執行某些進程目前不能使用，隔離出來.
[root@master ~]# cat /etc/rc.local
taskset -c 1,2 httpd
[root@master ~]# ps axo pid,psr | grep -E "1296|1298"
1296 2
1298 2此方式能保證進程運行在該CPU，但不能保證CPU中的內存數據運行在本地中
8 使用numactl 管理 NUMA 關聯
管理員可以通過特定的調度或者內存安裝策略來使用Numactl 運行進程，numactl也可以爲共享內存片段或文件設置永久性策略，並設置處理器關聯和進程的內存關聯
在NUMA系統系統中，處理器和內存條之間的距離越大，其訪問內存條的速度就越慢，應該講對性能敏感的程序配置爲可以從最近的內存條分配內存，最好是使用在同一 NUMA 節點的內存和 CPU
注意事項
對性能敏感的多線程應用程序經配置後在特定的 NUMA 節點上運行會比在特定的處理器上運行好處更多。這是否適合則取決於用戶系統及應用程序的需求。如果多個應用程序線程訪問同一緩存數據，那麼對那些線程進行配置，使其在同一處理器上運行可能是合適的。但是，如果在同一處理器上運行的多線程訪問及緩存的是不同數據，那麼每個線程可能會收回之前線程訪問的緩存數據。這就意味着每個線程會“缺失”緩存，會浪費運行 時間來從磁盤中獲取數據並在緩存中替代它。
/sys 文件系統包含有CPU,內存和外設，其連接是通過.NUMA進行互聯的，特別是/sys/devices/system/cpu 目錄中包含有關係統的CPU是圖和處理連接信息的，
/sys/devices/system/node 目錄包含有關係統中NUMA 節點以及節點間的相對距離的信息
/proc 內核級別的信息
/sys 硬件，內存相關的信息
numactl參數詳解
--show
顯示當前進程的NUMA策略設置
--hardware
顯示系統中可用節點的清單
--membind 內存親原性
只從指定節點分配內存，當使用這個參數時，如果這些節點中的內存不足則分配會失敗，這個參數的用法是
Numactl --membind=nodes program ，其中nodes 是您要從中分配內存的節點列表，program 是要從哪個節點分配內存的程序，節點號可以採用逗號分開的列表，範圍或者兩者的結合方式提供，
--cpunodebind 綁定CPU和內存
只執行屬於指定節點的CPU中的命令（及其子進程），這個參數的用法是numactl --cpunodebind=nodes progrpm ,其中nodes 是指定程序要捆綁的CPU 所屬節點列表，節點號可以採用逗號分開的列表，範圍或者兩者的結合方式提供
--physcpubind
只執行指定CPU 中的命令，這個參數的用法是numactl --physcpubind=cpu program，其中CPU 是用逗號分隔開的物理CPU 號列表，這些數據在/proc/cpuinfo 的processor字段中顯示，program是隻在那些CPU中執行的程序，還要將CPU指定爲與當前cpuset 相關聯
--localalloc
指定永遠要在當前節點中分配的內存，將進程調度到那個CPU上，這個進程就在對應的內存節點上運行和存儲數據
--preferred
在可能的情況下分配內存到指定節點中的內存，如果內存無法分配到指定的節點，則返回其他節點。
Numactl --preferred=nodes 必須在啓動程序時指定
必須在啓動腳本上執行
[root@python ~]# numactl --show
policy: default
preferred node: current (當前節點)
physcpubind: 0 1 2 3
cpubind: 0
nodebind: 0
membind: 09 使用 numad 進行自動化 NUMA 關聯管理
1 概述
numad 是一種自動化的 NUMA 關聯管理後臺程序。它對系統中的 NUMA 拓撲及資源用量進行監控，以便動 態地改善 NUMA 資源配置及管理。
numad 也同樣提供預先安置諮詢服務，這一服務可以通過不同的作業管理系統來查詢，併爲處理器 CPU 的 初始綁定及內存資源提供幫助。無論 numad 是以可執行程序或服務在運行，這一預先安置諮詢都可用。
根據系統負載，numad 可對基本性能有50%的提高，要達到此性能的優勢，numad會週期性的訪問 /proc 文件系統中的信息以便架空每個節點中可用的系統資源，該守護進程然後會嘗試在有足夠內存和CPU資源的NUMA節點中放置大量進程已優化NUMA性能，目前進程管理閾爲至少是一個CPU的50%，且至少有300MB內存，numad會嘗試維護資源換使用水平，並在需要時通過在NUMA節點間一共進程平衡分配。
numad 還提供預佈置建議服務，可以通過各種任務管理系統進行查詢以便提供CPU起始捆綁以及進程內存資源的支持，這個預佈置建議服務無論系統中是否運行numad都可以使用。
2 numad 有兩種使用方式
1 作爲服務使用
將 numad 作爲服務運行時，它嘗試基於當前系統的工作負載來動態調整系統。其活動記錄在 /var/log/numad.log。 如需啓動服務，運行： # systemctl start numad.service 如需重啓後服務持久，運行：
# chkconfig numad on 2 作爲可執行文件使用
在命令行使用 numad
將 numad 作爲執行表使用，只需運行：
numadnumad 運行的時候，其活動被記錄在 /var/log/numad.log。
它會持續運行直到被以下命令終止：
numad -i 0終止 numad 不會移除它所做的提高 NUMA 關聯的變更。如果系統使用有顯著的變化，再次運行 numad 能 調整關聯來提高新條件下的性能。
如需將 numad 管理限制爲特定進程，
用下列選項來啓動它：
numad -S 0 -p pid -p pid該選項將指定的 pid 添加到顯式的包含列表中。當指定的進程達到 numad 進程的顯著門限值，指 定的進程纔會被管理。
-S 0它將進程掃描的類型設置爲 0，這會將 numad 管理限制到顯式包的進程。
4 調度策略
1 概述
Linux 調度器執行大量的調度原則，以此決定線程運行的位置和時長。調度原則主要有兩類：普通原則和實時原則。普通線程用於普通優先級任務，實時原則用於具有時效性且必須無中斷完成的任務。
實時線程不受時間間隔的控制，這意味着它們將一直運行直至它們阻攔、退出、主動讓步或是被更高優先權的線程預先安置。最低優先權的實時線程會先於其他普通原則的線程進行調度。
2 調度原則
調度程序複製保證系統中的CPU處於忙碌狀態，Linux 調度程序採用調度策略，他可以決定何時以及在具體CPU何種線程運行的時間
1 實時策略(優先級進行掃描)
1 SCHED_FIFO
靜態優先調度策略，每一個線程有固定的優先級權限，該調度程序根據優先級權限順序掃描，sched_fifo線程列表，並調度準備好運行的最高優先權限的線程，這個線程會運行到他阻斷，退出或者被更好的線程搶佔準備運行的時候,這一策略建議無法運行較長時間且具有時效性的任務使用
即使是最低優先權的實時線程也會比非實時策略線程提前調度，如果只有一個實時線程，則sched_fifo優先權值就無所謂了，只有那些內核線程的優先級纔是實時的優先級，一個 SCHED_FIFO 線程的優先級級別可以是 1 至 99 之間的任何整數，99 是最高優先 級。紅帽建議一開始使用較小的數字，在確定了延遲問題後再增加優先級。
由於實時線程不受時間間隔的控制，紅帽不推薦設置 99 優先級。這會使同優先級的進程成爲遷移線程 或監控線程，如果線程進入一個計算機迴路且這些線程被阻攔，它們將無法運行。這種情況下，單處理 器系統最終會暫停。
管理員可以限制 SCHED_FIFO 的帶寬以防止實時應用程序的程序員啓用獨佔處理器的實時任務。
/proc/sys/kernel/sched_rt_period_us
該參數以微秒爲單位來定義時間，是百分之百的處理器帶寬。默認值爲 1000000 μs, 或1秒。
/proc/sys/kernel/sched_rt_runtime_us該參數以微秒爲單位來定義時間，用來運行實時線程。默認值爲 950000 μs, 或0.95秒
2 SCHED_RR
輪訓調度，也會爲sched_rr 線程提供1-99之間的固定優先權，但有相同優先權的線程使用特定或者時間片輪訓方式進行調度，sched_rr_get_interval 系統調用所有時間片返回的數值，但用戶無法設定時間篇持續大時間，這個策略對於具有相同優先級運行的多線程是有幫助的。
修改進程的實時優先級
[root@python ~]# chrt -h
Show or change the real-time scheduling attributes of a process.
Set policy:
chrt [options] <priority> <command> [<arg>...]
chrt [options] --pid <priority> <pid>
Get policy:
chrt [options] -p <pid>
Policy options:
-b, --batch set policy to SCHED_BATCH
-d, --deadline set policy to SCHED_DEADLINE
-f, --fifo set policy to SCHED_FIFO
-i, --idle set policy to SCHED_IDLE
-o, --other set policy to SCHED_OTHER
-r, --rr set policy to SCHED_RR (default)
Scheduling options:
-R, --reset-on-fork set SCHED_RESET_ON_FORK for FIFO or RR
-T, --sched-runtime <ns> runtime parameter for DEADLINE
-P, --sched-period <ns> period parameter for DEADLINE
-D, --sched-deadline <ns> deadline parameter for DEADLINE
Other options:
-a, --all-tasks operate on all the tasks (threads) for a given pid
-m, --max show min and max valid priorities
-p, --pid operate on existing given pid
-v, --verbose display status information
-h, --help 顯示此幫助並退出
-V, --version 輸出版本信息並退出chrt 指定優先級 -p 指定pid
如果不指定使用的，則默認使用RR調度策略
2 一般策略(用戶進程)
守護進程和批處理進程
交互進程
SCHED_OTHER 或者 SCHED_NORMAL
SCHED_OTHER redhat 7 默認調度策略，該策略使用完全公平調度程序(CFS)提供對所有使用此策略線程的提供公平訪問時間段，CFS建立了動態優先權限列表，部分是根據每個進程線程的niceness 值，這樣可爲用戶提供一些間接控制進程優先權的權利，但這個動態優先權列表只能由CFS直接修改，此調度算法適用於具有大量線程或數據吞吐量優先時最有用，因爲其能夠隨着時間而更爲有效的調度線程。
用於低優先權任務
SCHED_BATCH
SCHED_IDLE
3 常用的調度策略
sched rr
chrt -r
1-99 數字越大，優先級越高
sched_other
自動內核自動提供動態優先級手動 nice renice
100-139 數字越小，優先級越高
4 策略選擇
爲程序線程選擇正確的調度程序策略不總是那麼直接了當的任務，通常應在關鍵時間或者需要迅速調度期望不能延長運行時間的重要任務中實施策略，一般策略通常可以產生比實時策略好的數據流量結果，因爲它們讓調度進程更有效的運行(及就是它們不需要經常重新調度佔先的進程)，
如果需要管理大量進程，且擔心數據流量(每秒的網絡數據包，寫入磁盤等)，那麼請使用SCHED_OTHER,並讓系統爲你管理CPU
如果擔心事件響應時間延遲，則使用SCHED_FIFO，如果只有少量的線程，則可以考慮隔離CPU插槽，並將線程移動到那個插槽的核中以便沒有其他線程與之競爭。
3隔離CPU
1 isolcpus 開機隔離CPU
用戶可以使用isolcpus開機參數來從調度器隔離一個或多個CPU，以此防止調度在此CPU上調度任何用戶空間的線程。
一旦CPU被隔離，用戶需要手動分配進程至被隔離的CPU，或者使用CPU相關係統呼叫或者numactl命令
將系統中第三和第六 CPU 隔離至第八 CPU，添加如下至內核命令行：
isolcpus=2,5-7 2 Tuna 工具隔離CPU
用戶也可使用 Tuna 工具來隔離CPU。Tuna 可以隨時隔離 CPU，不僅僅侷限於啓動時。但這種隔離方法與 isolcpus 參數略有不同，並且目前尚未實現與 isolcpus 相關的性能收益。
在超過 32 個處理器的系統中，用戶須將 smp_affinity 的值限定爲分散的 32 位組。例如，如果一開始只 想使用 64 位處理器系統中的 32 位處理器來處理一箇中斷請求，可以運行：
echo 0xffffffff,00000000 > /proc/irq/IRQ_NUMBER/smp_affinity3 使用 tuna 配置 CPU，線程和中端關聯
Tuna 能夠控制CPU，線程及中斷關聯，並能夠給其所能控制的每類實體提供大量操作，
要從一個或多個特定的 CPU 中移除所有線程，請運行如下命令，使用想要隔離的 CPU 數量來替換 CPUs。
tuna --cpus CPUs --isolate 要在可運行特定線程的 CPU 列表中加入一個 CPU，請運行如下命令，使用想要加入的 CPU 數量來替換 CPUs。
tuna --cpus CPUs --include要將一箇中斷請求移動至特定的 CPU，請運行如下命令，用 CPU 數量替換 CPU，用想要移動且使用逗號分 隔的中斷請求列表替換 IRQs。
tuna --irqs IRQs --cpus CPU --move 此外，用戶可以使用如下命令來找到所有 sfc1* 模式的中斷請求。
tuna -q sfc1* -c7 -m -x 要改變一個線程的策略和優先級，請運行如下命令，使用想要改變的線程替換 thread，使用需要的線程運行策 略名稱替換 policy，用從 0（最低優先級）至 99（最高優先級）間的一個整數替換 level。
tuna --threads thread --priority policy:level4 中斷和中斷請求(IRQ) 調解
RIQ中斷請求是用於服務的請求，從硬件層面發出，可使用專用硬件線路或者跨硬件總線的信息數據包發出中斷。
啓用中斷後，接受IRQ 後會提示切換到中斷上下文，內核中斷調度代碼會搜索IRQ 號碼機器關聯的註冊中斷服務路由ISR 列表，並按順序調用ISR，ISR 會確認中斷並忽略來自同一IRQ 的多餘中斷，然後在延遲的句柄中排隊完成中斷處理，並忽略以後的中斷來結束ISR
[root@master ~]# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
0: 148 0 0 0 0 0 0 0 IO-APIC-edge timer
1: 13 0 0 0 0 0 0 0 IO-APIC-edge i8042
8: 1 0 0 0 0 0 0 0 IO-APIC-edge rtc0/proc/interrupts 文件列出每個IO 設備中每個CPU 的中斷數，每個CPU 核處理的中斷數，中斷類型，。以及用逗號分開的註冊爲接受中斷的驅動程序列表
IRQ 有一個關聯的“類似”屬性 smp_affinity ，該參數可以定義運行IRQ 執行ISR 的CPU和，文件中，可以提高程序的性能，方法是爲一個或多個具體的CPU 核分配中斷類似性和程序線程類似性，這可讓緩存在指定的中斷和程序線程之間共享
具體IRQ 數的中斷近似性值是保存的相關的/proc.irq.IRE_NUMBER/smp_affinity 文件中，可以作爲root 用戶查看並修改該值，保存在這個文件中的值是一個十六進制字節掩碼，代表系統中所有CPU 核。
[root@master ~]# grep eth0 /proc/interrupts
18: 24909 0 0 0 0 0 0 0 IO-APIC-fasteoi eth0
[root@master ~]# cat /proc/irq/18/smp_affinity f 表示所有CPU
00000000,00000000,00000000,000000ff
對於某些特定的硬件，在其註冊時就會保存在某些CPU 上
對於某些公共的硬件，如網卡，硬盤等有可能是內核不斷的調度的
大多數硬件都是CPU0 上處理的
Smp_affinity 的默認值是f，及可爲系統中的任意CPU 提供IRQ，將這個值設定爲1，如下
[root@master ~]# echo 1 > /proc/irq/18/smp_affinity
[root@master ~]# cat /proc/irq/18/smp_affinity
00000000,00000000,00000000,00000001隔離中斷
將某些在指定的CPU上的中斷進行調整到另外的cpu上，然後再進行綁定
[root@master ~]# echo 1 > /proc/irq/18/smp_affinity
[root@master ~]# cat /proc/irq/18/smp_affinity
00000000,00000000,00000000,00000001某特定進程綁定在特定CPU上，且該CPU 不處理任何其他請求，也不處理任何中斷，避免中斷上下文和進程上下文之間的切換
二 內存調優
1 注意事項
對於適中的工作負載，紅帽企業版 Linux 7 會默認優化。如果用戶的應用程序或用例需要大量的內存，那麼改變系統處理虛擬內存可以提高應用程序的性能。
2 頁面和內存管理
1 頁面管理
物理內存管理區稱爲頁面，每一個頁面的物理位置都映射到一個虛擬位置以便於處理器能夠訪問內存，這種映射存儲於一種叫做頁面表的數據結構中。物理內存被組織成葉匡，而線性地址被組織成頁面,數據的存放都是以頁面的格式進行定義的,頁面的數據有可能被映射到非連續的物理葉匡中,
默認情況下，一個頁面大約有4kb，1M 內存等於256個頁面，1GB 內存等於256000個頁面，CPU有內嵌的內存單元，這些單元中包含着這些列表，每個頁面都使用也表條目參考。,由於頁面的默認大小很小，因此用戶需要很多頁面來管理大量內存，其頁面表只能存儲有限的地址映射，增加其存儲地址映射的數量既昂貴又困難，因此要考慮到將性能等級保持在內存需求範圍內,32 位系統一般支持4k的頁面葉匡和4M的,64 位 4k 和 2M 的葉匡。
2 超大轉義後備緩衝器(huge TLB)
將物理內存地址轉義爲虛擬內存地址是內存管理的一部分，物理地址和虛擬地址的映射關係保存在名爲頁表的數據結構中，因爲每個地址映射讀取頁表會很消耗時間和資源，所以最近使用的地址都有緩存，這個緩存就是轉移後備緩衝器 .
但TLB 只能緩存大量的地址映射，如果所要求的地址映射沒有在TLB中，則必須扔讀取頁表已決定物理到虛擬地址的映射，這就是TLB缺失，因爲內存要求與用來緩存TLB 中地址映射之間的關係，所以有大內存要求的程序比使用較少內存的程序更容易受TLB缺失的影響，因爲每一個缺失都涉及頁表讀取，因此儘量避免這些缺失很重要。
超大轉移後備緩衝器（huge TLB）可以很大片管理內存，以便一次可以緩存更多地址，這樣可以減少TLB 缺失的可能性，進而改進有大內存要求的程序的程序性能。
紅帽企業版 Linux 提供大型轉換後背緩衝區 （大型 TLB），可以將內存分爲大片段進行管理。這使大量的地址映射能同時進行緩存，以此降低 TLB 缺失的可能性，並提高需要大內存的應用程序的性能。
3 大內存和透明頁
當數據訪問時，是裝入時長訪問的數據，而不是裝入所有數據，此時如果需要訪問其他沒有被裝載的數據，則會發生數據異常，此時需要通過IO的方式來進行查詢處理
對於非常吃內存的進程，進行開啓其大內存頁的功能，這就是一種調優方式
讓系統管理大量內存的兩種方式
1 增加硬件內存管理單元的頁表數
2 增加大頁面第一種方式很貴，現在的處理器中的硬件內存管理單元只支持數百或者數千條頁條目，另外適用於管理數千頁面硬件和內存管理算法可能無法很好的管理百萬甚至數億頁面，這會造成性能問題，但程序序號使用比內存管理單元更多的頁面，該系統就會回退到緩慢的基於軟件的內存管理，從而造成整個系統運行緩慢。
超大頁面時2MB和1GB大小的內存塊，2MB使用的頁表可管理多GB，而1GB頁是TB內存的最佳選擇
超大頁面必須在引導時分配，他們很難手動管理，且經常需要更改代碼以便可以有效使用，因此紅帽企業版Linux 也部署了透明超大頁面（THP）
THP 是一個提取層，可自動創建。管理和使用超大頁面的大多數方面超大頁面必須引導時配置，而透明大頁面可以隨時配置
THP 系統管理員和開發者減少了很多使用超大頁面的複雜性，因爲THP的目的是改進性能，所以其開發者已在各種系統、配置和負載中測試並優化的THP ，這樣可讓THP 的默認設置改進大多數系統配置性能
Varish 和透明大頁面不兼容，大頁面可能會導致內存泄露
Varish 在2M的頁面上性能很一般
透明大頁面管理職能用於異步內存段的管理
紅帽企業版 Linux 通過靜態大型分頁來給每個頁面管理大內存的能力，靜態大型分頁可以分配到1GB大小，但其難以管理，必須在啓動時就分配好。
透明大型分頁很大程度上是之餘靜態大型頁面的一個自動選擇。透明大型頁面大小爲 2 MB 且默認啓動。它們有時會干擾對延遲敏感的應用程序，因此常常在延遲嚴重時被禁用。
2 監控及診斷性能問題
紅帽企業版Linux 7 提供大量有用工具來監控系統性能與系統用內存相關的性能問題
1 vmstat 監控內存使用量
Vmstat 由procps-ng 數據包提供，輸出用戶系統進程，內存，網頁，字塊輸入/輸出，中斷以及CPU的活動等報告，
具體見下:
2 用 valgrind 分析應用程序的內存使用量
1 安裝
Valgrind 是一個爲用戶提供空間二進制文件測量方法的框架。它包含大量的工具來概述和分析程序性能。本章列出的 valgrind 工具能幫助用戶檢測內存錯誤，例如未初始化的內存使用和不適當的內存分配及解除分配。
要使用 valgrind 或其工具，請安裝 valgrind 數據包：
yum install valgrind2 memcheck
memcheck 是默認的valgrind工具，其檢測並報告出大量難以檢測和診斷到的內存錯誤，如
不應發生的內存訪問
使用未定義或者未初始化的值
不正確的釋放堆地址
指示字重疊
內存泄漏
memcheck 只能報告這些錯誤，但並不能阻止它們發生，如果程序以通常會引起段錯誤的方式來訪問內存的話，段錯誤仍然會發生，但memcheck會在發生錯誤之前立即記錄一條信息
由於 memcheck使用測量工具，通過memchek執行的應用程序會比平常運行起來慢10-30倍。
要在應用程序上運行 memcheck， 請執行以下指令：
valgrind --tool=memcheck application用戶也可以使用以下選項來使 memcheck 的輸出集中在特定的問題類型上。
3 參數詳解
--leak-check
在應用程序結束運行後，memcheck 會搜索內存泄露問題。默認值爲 --leakcheck=summary，在找到內存泄露時會顯示其數量。用戶可以指定 --leak-check=yes 或 --leak-check=full 來輸出每個泄露問題的詳情。禁用請設定 --leak-check=no。
--undef-value-errors
默認值爲 --undef-value-errors=yes，使用未定義的值時會報錯。用戶還可設定 --undef-value-errors=no ，這將禁用此報告並略微提高 Memcheck 的速度。
--ignore-ranges
在查看可尋址內存時指定一個或多個 memcheck 應忽略的範圍，例如， --ignoreranges=0xPP-0xQQ,0xRR-0xSS。
3 cache grind
使用 cache grind 分析緩存使用量
cachegrind 會模擬應用程序與系統緩存層析結構和分支預測器之間的交互作用，他會追蹤模擬的以及指令和數據緩存使用情況，以此檢測出該級緩存與代碼間不良的交互作用。它也會追蹤最後一級緩存（第二或第三極）以便追蹤內存訪問。這樣的情況下，使用 cachegrind 的應用程序運行起來會比通常慢 20-100 倍。
Cachegrind 會收集應用程序執行期間的統計數據，並且將概要輸出至操作檯。要在應用程序中運行
cachegrind ，請執行以下指令：
valgrind --tool=cachegrind application用戶也可以使用以下選項來讓 cachegrind 的輸出集中在一個特定的問題上。
參數詳解
--I1
指定大小、關聯性以及第一級指令緩存行大小的方法如下：--I1=size,associativity,line_size。
--D1
指定大小、關聯性以及第一級數據緩存行大小的方法如下：--
D1=size,associativity,line_size.。
--LL
指定大小、關聯性以及最後一級緩存行大小的方法如下：--
LL=size,associativity,line_size。
--cache-sim
啓用或禁用緩存訪問和缺失數量的集合是默認啓用的（--cache-sim=yes）。禁用此集合以及 --branch-sim 來使 cachegrind 不收集信息。
--branch-sim
啓用或禁用分支指令及錯誤預測數量的集合是默認啓用的（--branch-sim=yes）。禁用此集合以及 --cache-sim 來使 cachegrind 不收集信息。
Cachegrind 寫入詳細的分析信息至每個進程 cachegrind.out.pid 文件，其中， pid 是進程標識符。這一詳細信息可以使用 cg_annotate 工具進行進一步處理，方法如下：
cg_annotate cachegrind.out.pidCachegrind 也提供 cg_diff 工具，可以更爲容易地在代碼變化前後對程序性能進行記錄。要對比輸出文
件，請執行以下命令：先用原始配置輸出文件替代，再用後續配置輸出文件替代。
cg_diff first second4 使用massif分析堆棧空間
Massif 測量特定應用程序的堆空間。它測量可用空間和額外用來記錄和調準的空間。massif 有助於用戶瞭解減少應用程序內存使用的方法，以便提高運行速度，減少應用程序耗盡系統交換空間的可能性。使用massif 執行的應用程序運行起來比平常通常慢 20 倍左右。
要在一個應用程序中運行 massif，請執行如下命令：
valgrind --tool=massif application用戶也可以使用以下選項來將 massif 的輸出集中在一個特定的問題上。
--heap
設定 massif 是否分析堆。默認值爲 --heap=yes。要禁用堆分析可設置爲 --heap=no。
--heap-admin
堆分析啓用時要設定每個用於管理的數據塊字節數。默認值爲 8 字節。
--stacks
設定 massif 是否分析堆。默認值爲 --stack=no 是由於堆分析會大大減緩 massif。將這一選項設置爲 --stack=yes 來啓用堆分析。要注意的是，massif 會假設主要的堆始於零值，這是爲了更好地顯示與所分析的應用程序相關的堆尺寸的變化。
--time-unit
設定 massif 收集分析數據的間隔。默認值爲 i（執行指令）。用戶也可以指定 ms（毫秒或實時）和 B（分配或收回的堆棧字節數）。檢查分配的字節數有利於短期運行的應用程序及測試，因爲對於不同的硬件來說，它是最具重複性的。
Massif 將分析數據輸出至 massif.out.pid 文件中，該文件中的 pid 是指定應用程序的進程標識符。ms_print 工具將此分析數據繪成圖表，以此顯示執行應用程序的內存消耗，也包括峯值內存分配點負責分配的站點詳情。要繪製 massif.out.pid 文件中的數據，請執行以下指令：
ms_print massif.out.pid3 配置工具
1 簡介
內存使用量往往是通過設置一個或多個內核的參數值來進行配置的，這些參數可以通過改變在/proc文件系統中的文件內容來進行暫時的設置，或者是通過設置系統核心參數工具來進行永久設置，此工具由procps-ng數據包提供
例如，要將 overcommit_memory 參數暫時設置爲 1，請運行以下指令：
echo 1 > /proc/sys/vm/overcommit_memory要永久設置這個值，請運行以下指令：
sysctl vm.overcommit_memory=1 暫時設置一個參數有利於決定此參數對系統的影響。用戶可以在確定了參數值有預期的效果之後再將其設置爲 永久值。
2 配置大頁面
大頁面依賴於連續的內存區域，因此最好在啓動時，也就是內存變爲判斷之前就定義好大頁面，爲此，可添加一下參數至內核啓動命令行:
hugepages
啓動時在內核中定義 2MB 定值大頁面的數量。默認值爲 0。只有在系統擁有足夠的物理持續性空閒 頁面時才能進行分配（或是收回）大頁面。此參數保留的頁面不能用於其他目的。
此值可以在啓動後通過改變 /proc/sys/vm/nr_hugepages 文件值來調節。 更多詳情請參閱相關內核文檔，默認安裝於 /usr/share/doc/kernel-doc- kernel_version/Documentation/vm/hugetlbpage.txt 中。
/proc/sys/vm/nr_overcommit_hugepages
通過超量使用內存來定義系統所能創建和使用的最大數量的額外大頁面。在此文件中寫入任何非零 的值，表示系統包含此數目的大頁面，在不變的頁面池耗盡後，這些大頁面便來自於內核的常規頁 面池。由於這些額外的大頁面是未使用過的，因此它們會釋放並返回至內核的常規頁面池中。
3 配置系統內存容量
虛擬內存參數
此處參數都早/proc/sys/vm中，除非另有標明
dirty_ratio: 一個百分比值，當整個系統內存的這一百分比值被修改時，系統會通過運行pdflush 將改動寫入磁盤，默認是20%。
dirty_background_ratio: 一個百分比值，當整個系統內存的這一百分比值被修改時，系統會在後臺將改動寫入磁盤，默認是10%。
overcommit_memory: 定義用來決定接受或拒絕一個大內存請求的注意事項
默認值爲0，默認情況下，內核執行探索發內存超量使用，是通過估算可用內存大小和由於太大而失敗的請求來進行處理的，但是由於內存分配使用的是探索算法而不是精確算法，這一設置導致超載內存是可能的。
當這一個參數設置成1時，內核不執行內存超量使用處理，這增加了內存超量的可能性，但也提高了內存密集型任務的性能。
當這一參數設置成2時，內核拒絕請求，及請求的內存大於或等於總的可用交換空間，以及在overcommit_ratio中指定的物理RAM的百分比，這減少了超量使用內存的風險，但僅在系統交換空間大於物理內存時推薦此設置。
overcommit_ratio
當 overcommit_memory 設置爲2時，設定所考慮的物理RAM的百分比，默認值爲50.
max_map_count
定義一個進程可以使用的最大內存映射區域數量，默認(65530) 適用於大部分情況，如果應用程序需要映射超過此數量的文件，可增加此值。
min_free_kbytes
指定千字節的最小數量，使之在整個系統中都保持空閒，這是用來給每個低內存區決定一個合適的值，每一個低內存區都是按照其大小比例分配了大量保留的空閒頁面。
警告:
極值會損壞用戶的系統。將 min_free_kbytes 設置爲一個極小的值以防止系統回收內存，回收內存會導致系統鎖死，以及 OOM-killing 進程。但是，將 min_free_kbytes 設置過高 （例如，整個系統內存的 5–10% ）會使系統立即進入一種內存不足的狀態，導致系統花太多時間來回收內存。
oom_adj
在系統內存不足，並且panic_on_oom參數設置成0的情況下，oom_killer 功能會結束進程，直至系統可以恢復，從提高的oom_score 進程開始。
oom_adj 參數有助於確定一個進程的oom_score,此參數以每一個進程標識符爲單位進行設置，值爲-17時會禁用進程的oom_killer,其他有效值從-16到15 由一個調整過的進程而產生的進程會繼續該進程的 oom_score。
swappiness
一個從 0 到 100 的值可以控制系統交換的程度。高值優先考慮系統效率，並在進程不活躍時主動交換物理內存耗盡的進程。低值優先考慮響應度，並且儘可能久地避免交換物理內存耗盡的進程,默認值爲 60。
4 文件系統參數
此處中的參數都在/proc/sys/fs內，除非另有標明。
aio-max-hr
定義在異步輸入/輸出環境中允許的最大事件數量，默認值爲65536,修改此值不會預分配或改變任何內核數據結構的大小。
file-max
定義內核分配最大的文件句柄數量，默認值與內核中的files_stat.max_files 值相匹配，將此值設置爲最大值NR_FILE(8192,在紅帽企業版Linux中)或是以下結果:
(mempages * (PAGE_SIZE / 1024)) / 10增加此值可以解決由於缺少可用文件句柄而引起的錯誤
5 內核參數
此處中的參數都在/proc/sys/kernel內，除非另有標明。
msgmax
msgmax 以字節爲單位，定義任何一個在信息隊列中的信息可能的最大值，該值不能超過隊列的大小(msgmnb),默認值爲65536Z
msgmnb
以字節爲單位，定義每一個信息隊列的最大值，默認是65536
msgmni
定義信息隊列標識符的最大數量(以及隊列的最大數量)，在64位架構的系統中，默認值爲1985.
shmall
定義頁面上共享內存的總量，這些內存是系統可以同時使用的shmmni
定義系統範圍內最大的共享內存片段數量，在所有系統中默認值爲4096
threads-max
定義系統範圍內內核能同時使用的最大線程量，默認值與內核參數max_threads 相同，或爲一下結果:
mempages / (8 * THREAD_SIZE / PAGE SIZE )最小值爲20
三 存儲和文件系統
1 注意事項
存儲和文件系統性能的合理設置很大程度上取決於存儲目的，I/O和文件系統性能會受到下列因素的影響:
1 數據寫入或者讀取模式
2 數據重新排列與底層架構
3 塊大小
4 文件系統大小
5 日誌大小和位置
6 記錄訪問次數
7 確保數據可靠性
8 預取數據
9 預先分配磁盤空間
10 文件碎片
11 資源爭用
2 固態硬盤
SSD(固態硬盤)使用閃存芯片而非旋轉磁盤存儲永久數據，它們爲邏輯塊地址內的全部數據提供恆定的訪問時間，而且不會像它們旋轉的對應物那樣出現可測量的搜尋成本，每千兆字節的存儲空間更昂貴且存儲密度更好，但比HDD延遲時間短，吞吐量更大。
當在SSD上使用塊接近磁盤容量，性能通常會降低，降低的程度因供應商的不同而異，在此情況下，所有設備性能都會降低，啓用放棄有助於緩解性能降低。
默認I/O調度器和虛擬內存選項適用於SSD
3 I/O調度器
1 概述
I/O 調度決定I/O操作何時運行存儲設備上以及運行多久，其也被稱爲I/O elevator(I/O升降機)
2 deadline
除了SATA 磁盤爲所有的塊設備的默認I/O調度器，deadline嘗試爲指向到達I/O調度器的請求提供有保障的延遲，該調度器適合大多數用例，尤其適用於讀取操作比寫入操作更頻繁的請求。
將排隊的I/O請求分類爲讀或者寫批處理，並按照LBA遞增順序執行，默認設置下，讀批處理優先於寫批處理，這是因爲應用更可能阻止讀取I/O，批處理後，deadline檢查寫入操作因等待處理時間而處於多久的"飢餓"狀態，並且適當的調度下一個讀批處理或者寫批處理，解決批處理的請求數量，發出寫批處理的讀批處理數量，以及請求過期前的時間量都是可以配置的。
3 cfg
默認調度只適用於標記爲SATA 硬盤的設備，完全公平調度器，cfg，將進程分爲三個獨立的類別， 實時，盡其所能和空間，實時類別的進程總是先於盡其所能類別進程執行，而盡其所能類別進程總是在空閒類別進程之前執行。這意味着實時類別可以時其盡其所能和空閒進程等待處理器時間而忍受"飢餓"，默認情況下，分配進程到盡其所能類別
cfg 使用歷史數據來因此應用是否會在不就之後發出更多的I/O請求，如果將有更多的I/O請求，cfq空閒則會等待新的I/O，即使有來自其他進程的I/O在等待處理
因爲有空閒趨勢，cfg調度器不應用於連接不會引起大量搜尋的硬件，除非它爲次目的而被調整，cfg調度器也不應用於連接其他斷續工作型調度器。
cfg 行爲是可高度配置的
4 noop
noop I/O調度器執行簡單的FIFO(先進先出)調度算法，請求通過簡單的最後選中的緩存數據在一般塊層合併，對於使用最快存儲的受CPU限制的系統，這是最佳的調度器
4 文件系統
1 XFS
XFS 是一個可靠的，且高度縮放的64位文件系統，是Linux redhat7 中默認的文件系統,XFS使用基於分區的分配，具有一些分配方案，包括預先分配和延遲分配，這兩種都會減少碎片和輔助性能，它也支持促進故障恢復的元數據日誌，當掛載並激活時，能夠對XFS進行碎片化整理和放大，XFS支持最大容量可達500TB的文件系統。以及最大容量爲8EB的文件偏移量。
2 Ext4
Ext4是Ext3文件系統的可縮放擴展，它的默認行爲對大部分工作負載是最佳的，然而，它只支持最大容量爲50TB的文件系統有一集最大容量爲16TB的文件。
3 Btrfs(技術預覽)
Btrfs 是提供縮放性，容錯和方便管理的copy-on-write(寫時複製)文件系統，它包括內置快照和RAID支持，通過數據和元數據校驗來提供數據的完整性，它也是通過數據壓縮提高性能及使用空間的效率，Btrfs作爲一種技術預覽，支持最大容量可達50TB的文件系統。Btrfs是最適合桌面存儲和雲存儲，
4 GFS2
GFS2是具有極高可用性附加裝置的一部分，爲redhat 7 企業版提供簇文件系統支持，GFS2集羣提供所有服務器一致的文件系統圖像，允許服務器在單獨共享文件系統中讀取和寫入。
GFS2 支持最大容量可達150TB的文件系統
5 格式化文件系統注意事項
1 概述
在設備格式化後，文件系統配置的部分決定不能改變，此處必須對格式化後的結果進行準確的預估
2 大小
按照工作負載創建合理大小的文件系統，按相應比例，較小的文件系統的備份次數也較少，且文件系統檢查需要時間和內存也更少，然而，如果您的文件系統太小，性能將因爲大量碎片化而降低
3 塊大小
塊是文件系統中的工作單位，塊大小決定單個塊能存儲多少數據，也因而決定能夠同時讀寫數據的最小量
默認塊大小適用於大部分用例，然而，如果塊大小和通常同時讀寫的數據數量一樣大，或者略大時，文件系統將執行的更好，存儲數據更加有效率，小文件仍將使用一個完整的塊，文件分佈在多個塊中，會造成額外的運行時間開銷，另外一些文件系統受限於一定數量的塊，轉而限制文件系統的最大尺寸
使用mkfs 指令格式化設備時，塊大小作爲文件系統選項的一部分爲被指定，指定塊大小的參數隨文件系統的變化。
4 幾何
文件系統的幾何與文件系統中數據的分佈有關，如果系統使用帶狀存儲器，如RAID，可以格式化設備時，通過重新排列數據和底層存儲幾何的元數據提高性能。
很多數據導出的推薦幾何在使用特定文件系統格式化設備時會被自動設置。如果設備沒有導出這些推薦幾何，或您想要變更推薦設置，那麼您在使用 mkfs 格式化設備時，需要手動指定幾何 。
5 外部日記
日誌文件系統會在執行寫操作之前，將寫操作期間發生的變化記錄到日誌文件中，這會降低系統發生故障，電源故障時日誌的存儲設備損壞的可能性，並加速恢復過程
元數據密集工作負載設計日誌的頻繁更新，大型日誌使用更多內存，但會較少操作的頻繁性，此外，可通過將設備日誌置於和主要存儲一樣快或者更快的專用存儲上，提高帶有元數據密集型工作負載的設備的尋道時間。
確保外部日誌的可靠性，失去外部日誌，設備將導致文件系統的損壞
外部日誌必須在格式化時創建，並在掛載期間制定日誌設備
6 掛載事件注意事項
1 barrier(屏蔽)
文件系統的barrier確保文件系統元數據正確寫入到永久存儲並排序，使用fsync傳輸數據在斷電下得以存留，以前的redhat版本中，啓用文件系統barrier會明顯放慢嚴重依賴fsync的應用程序，或者創建和刪除很多小文件
紅帽企業版Linux 7 中，文件系統barrier性能的得到改善是使禁用的文件系統barrier的性能影響變的極小(小於3%)
2 訪問時間
每次讀取文件，它的元數據隨着訪問時間atime更新，這涉及額外的I/O,在大多數情況下，這項的開銷是小的，因爲在默認情況下，前一次訪問時間早於上一次修改時間(mtime)或者狀態變化(ctime)，redhat 7 只會更新atime。
然而，如果更新元數據耗時，且並不對準確訪問時間做要求，其可以使用noatime掛載選項掛載文件系統，讀取文件時會禁用元數據的更新，它也會啓用nodiratime行爲，讀取目錄時，該行爲禁用元數據的更新
3 預讀
預讀行爲通過預取可能立即需要的數據，並將其加載到可比磁盤上更快檢索的頁面緩存中加速文件系統訪問，預讀值越高，系統預取數據越早。
redhat 企業版Linux 根據對文件系統的檢查，嘗試設置一個合適的預讀值，然後檢查不可能總是準確的，涉及大量數據流的量數據流的順序I/O的工作負載常常受益於高預讀值，redhat 企業版 Linux 7 提供的相關存儲調整配置文件提高預讀值，和使用 LVM 條帶化一樣，但這些調整對於所有工作負載而言並不總是足夠的。
7 維護
定期丟棄文件系統中不可用的塊是對於固態硬盤和精簡裝置粗出的建議做法，有兩種丟棄不使用的塊的做法:
batch discard(批量和丟棄)
這種丟棄方式是fstrim指令的一部分，它丟棄文件系統中和管理員指定的標準相匹配的所有不適用的塊
redhat Linux 7 支持 XFS 和 ext4 格式化設備上的 batch discard，這些設備支持實際丟棄操
作即（ /sys/block/devname/queue/discard_max_bytes 值不爲 0 的 HDD 設備，和/sys/block/sda/queue/discard_granularity 不爲 0 的 SSD 設備）。
online discard(網絡丟棄)
這種方式的丟棄操作在掛載時是discard選項配置。實際運行不受用戶干擾，然而，online discard 只丟棄從使用轉換到空閒的塊，Redhat 7 支持 XFS 和 Ext4格式化設備上的online discard紅帽推薦 batch discard，除非要求用 online discard 維持性能，或 batch discard 不可用於系統工作負載。
預先分配
預先分配將硬盤空間標記爲已經跟將磁盤空間分配給一個文件，爲未將數據寫入該空間，這可用於限制數據碎片和較差的讀取性能，Redhat Linux 7 支持掛載事件內XFS,Ext4和GFS2 設備上預先分配空間/
6 使用system tap 監控存儲
下列的 SystemTap 示例腳本與存儲性能有關，並可能有助於診斷存儲或文件系統性能問題。默認設置下，
安裝它們至 /usr/share/doc/systemtap-client/examples/io 目錄下。
disktop.stp
每 5 秒檢查讀／寫硬盤狀態並輸出在此期間的前十項。
iotime.stp
顯示用在讀操作和寫操作的時間量，以及讀和寫的字節量。
traceio.stp
根據觀察到的累計 I/O 流，顯示每秒前十項可執行文件。
traceio2.stp
在特定設備進行讀和寫操作時，顯示可執行的名稱和進程標識符。
inodewatch.stp
每當在特定主要／次要設備上的特定 inode 上進行讀或者寫操作時，顯示可執行的名稱和進程標識符。
inodewatch2.stp
每當在特定主要／次要設備上的特定 inode 上屬性發生變化時，顯示將可執行的名稱、進程標識符、和屬性。
6 配置工具
1 配置存儲性能的調整配置文件
tuned 和 tuned-adm 提供一些旨在爲特定用例提高性能的配置意見，下面配置文件有利於提高存儲性能尤爲重要
其作用有
1 延遲性能
2 吞吐量性能
如需配置文件系統中的配置文件，請運行下面命令，用您想用的配置文件名稱替代 name。
$ tuned-adm profile nametuned-adm recommend 命令爲系統推薦合適的配置文件，在安裝時它也會爲系統設置默認配置文件，因此可用於返回默認配置文件
2 設置默認I/O調度器
如果設備的掛載選項沒有指定調度器，可使用默認的I/O調度器
如需設置默認I/O調度器，在重啓時通過向內核命令行附加elevator參數來指定想要使用的調度器，或通過編輯/etc/grub2.conf文件
elevator=scheduler_name3 爲設備配置I/O調度器
如需設置特定存儲設備的調度器或者調度器的優先級順序，編輯/sys/block/devname/queue/scheduler 文件，devname 爲你預配置的設備的名稱
[root@python ~]# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
[root@python ~]# echo cfq > /sys/block/sda/queue/scheduler
[root@python ~]# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
[root@python ~]# 4 調整deadline調度器
使用deadline時，排隊的I/O請求將分爲讀批處理和寫批處理，然後按照LBA遞增的執行順序調度，默認設置下，讀批處理優先於寫批處理，這是因爲在讀I/O上引用程序易被阻止，在批處理被處理後，deadline 會檢查寫操作因等待處理器時間而處於多久的"飢餓"狀態，併合理調度下一個讀或者寫批處理。
下面參數形象deadline調度器行爲
fifo_batch
單個批處理中讀操作或者寫操作發出的數量，默認爲16，值越高，吞吐量也會更多，但也會增加延遲
front_merges
如果您的工作負載從不產生正面合併，可調整的參數設置爲0，然而，除非你已經測試了該檢查的開銷，推薦1爲默認值
read_expire
應爲服務調度讀請求中毫秒的數量，默認值爲500(0.5秒)
write_expire
應爲服務器調度寫請求中的毫秒數量，默認值爲5000(5秒)
writes_started
先於寫批處理而處理的讀批處理數量，該值越高，給讀批處理的優先更多
5 調整cfg 調度器
使用cfg時，進程分爲三類，實時，盡其所能和空間，盡其所能進程之間調度所有實時進程，而空間進行之前調度盡其所能進程，默認情況下，進程歸類爲盡其所能，可使用ionice 命令手動調整進程分類
通過使用下面參數進一步調整cfg調度器的行爲，這些參數通過改變/sys/blog/devname/queue/iosched 目錄下的指定文件，基於每個設備設置的
[root@python iosched]# ll
總用量 0
-rw-r--r-- 1 root root 4096 12月 10 23:01 back_seek_max
-rw-r--r-- 1 root root 4096 12月 10 23:01 back_seek_penalty
-rw-r--r-- 1 root root 4096 12月 10 23:01 fifo_expire_async
-rw-r--r-- 1 root root 4096 12月 10 23:01 fifo_expire_sync
-rw-r--r-- 1 root root 4096 12月 10 23:01 group_idle
-rw-r--r-- 1 root root 4096 12月 10 23:01 low_latency
-rw-r--r-- 1 root root 4096 12月 10 23:01 quantum
-rw-r--r-- 1 root root 4096 12月 10 23:01 slice_async
-rw-r--r-- 1 root root 4096 12月 10 23:01 slice_async_rq
-rw-r--r-- 1 root root 4096 12月 10 23:01 slice_idle
-rw-r--r-- 1 root root 4096 12月 10 23:01 slice_sync
-rw-r--r-- 1 root root 4096 12月 10 23:01 target_latency
[root@python iosched]# pwd
/sys/block/sda/queue/ioschedback_seek_max
cfq 將執行向後搜尋千字節計算的最大距離，默認是16kb,向後搜尋通常會損害性能，因此不推薦使用大的值
back_seek_penalty
磁頭在決定向前還是向後移動時，乘法器應用於向後搜尋，默認值爲2，如果磁頭位置是1024kb，並且系統中有等距的請求,back_seek_penalty
應用於向後搜尋距離和磁盤向前移動。
fifo_expire_async
異步(緩衝寫入)請求以毫秒計算可能持續無服務的時間長度，在這個時間過期之後，一個單獨的飢餓的異步請求移動至配送列表，默認值爲250毫秒。
fifo_expire_sync
同步(讀取或者O_DIRECT 寫入)請求以毫秒計算的可能持續無服務的時間長度，在這個時期過期後，一個單獨的"飢餓"的同步請求被移動至配送列表，默認值爲125毫秒。
group_idle
默認情況下，此參數設置爲0，表示禁用，設置爲1(啓用)時，cfg 調度器空閒在控制組中發出I//O的最後進程裏，如使用成比例的重量 I/O 控制組，或 slice_idle 設置爲 0 （在快速存儲上）會有幫助。
group_isolation
默認設置下，該參數設置爲 0（禁用）。設置爲 1（啓用）時，它提供組之間更強的隔離，但是吞吐量會減少，這是因爲公平性用於隨機和順序工作負載。group_isolation 禁用時（設置爲0），公平性只提供給順序工作負載。
low_latency
默認設置下，設置參數爲1(啓用),啓用後。通過爲設備上發出I/O的每個進程提供最大爲300ms的等待時間，CFG 更注重公平性而非吞吐量，設置參數爲0時(禁用)，目標延遲被忽略，每個進程接受完成的時間片
quantum
該參數定義cfg在同一時間發給一個設備的I/O請求的數量，實際上是對隊列深度的限制，默認值爲8個請求，使用的設備可能支持更大的隊列深度，但增加隊列深度會導致延遲，尤其是大的順序寫工作負載
slice_async
該參數定義分配給每個發出異步I/O請求的進程的時間片長度，默認爲40毫秒
slice_idle
該參數指定等待下一步請求時以毫秒計算的cfg空間時間長度，默認爲0（隊列無空間或者 service tree level）.默認值對於外部raid 存儲器的推圖量是理想的，由於增加了搜尋操作的整體數量，從而降低呢哦不non-RAID 存儲器的吞吐量
slice_sync
該參數定義分配給每個發出異步I/O請求的進程的時間片長度，默認值爲100ms
爲快速存儲調整 cfg
不像無法遭受大搜尋 penalty（懲罰）的硬件推薦 cfq 調度器，例如快速外部存儲數列或者固態硬盤。如果
您需要在此存儲上使用 cfq ，需要編輯下列配置文件：
設置 /sys/block/devname/queue/ionice/slice_idle爲0
設置 /sys/block/devname/queue/ionice/quantum 爲64
設置 /sys/block/devname/queue/ionice/group_idle爲 1
6 調整noop 調度器
noop I/O 調度器主要對使用快速存儲的受CPU限制有用，請求在塊層合併，因此通過編輯/sys/block/sdx/queue/ 目錄中的文件中塊層參數，修改noop 行爲
[root@python ~]# echo noop > /sys/block/sda/queue/scheduler
[root@python ~]# cat /sys/block/sda/queue/scheduler
[noop] deadline cfq
[root@python ~]# cd /sys/block/sda/queue/iosched/
[root@python iosched]# ll
總用量 0
[root@python iosched]# cd ..
[root@python queue]# pwd
/sys/block/sda/queue
[root@python queue]# ll
總用量 0
-rw-r--r-- 1 root root 4096 12月 10 23:01 add_random
-r--r--r-- 1 root root 4096 12月 10 23:01 discard_granularity
-r--r--r-- 1 root root 4096 12月 10 23:01 discard_max_bytes
-r--r--r-- 1 root root 4096 12月 10 23:01 discard_zeroes_data
-r--r--r-- 1 root root 4096 12月 10 23:01 hw_sector_size
drwxr-xr-x 2 root root 0 12月 10 23:27 iosched
-rw-r--r-- 1 root root 4096 12月 10 23:01 iostats
-r--r--r-- 1 root root 4096 12月 10 23:01 logical_block_size
-r--r--r-- 1 root root 4096 12月 10 23:01 max_hw_sectors_kb
-r--r--r-- 1 root root 4096 12月 10 23:01 max_integrity_segments
-rw-r--r-- 1 root root 4096 12月 10 23:01 max_sectors_kb
-r--r--r-- 1 root root 4096 12月 10 23:01 max_segments
-r--r--r-- 1 root root 4096 12月 10 23:01 max_segment_size
-r--r--r-- 1 root root 4096 12月 10 23:01 minimum_io_size
-rw-r--r-- 1 root root 4096 12月 10 23:01 nomerges
-rw-r--r-- 1 root root 4096 12月 10 23:01 nr_requests
-r--r--r-- 1 root root 4096 12月 10 23:01 optimal_io_size
-r--r--r-- 1 root root 4096 12月 10 23:01 physical_block_size
-rw-r--r-- 1 root root 4096 12月 3 21:14 read_ahead_kb
-rw-r--r-- 1 root root 4096 12月 10 23:01 rotational
-rw-r--r-- 1 root root 4096 12月 10 23:01 rq_affinity
-rw-r--r-- 1 root root 4096 12月 10 23:27 scheduler
-rw-r--r-- 1 root root 4096 12月 10 23:01 unpriv_sgio
-r--r--r-- 1 root root 4096 12月 10 23:01 write_same_max_bytesadd_random
一些I/O時間會影響 /dev/random的熵池，如果這些影響的負荷變得可測量，該參數可設置爲0
max_sectors_kb
指定I//O請求的最大尺寸(以千字節計算),默認值爲512kb,該參數的最小值是由存儲設備的邏輯塊大小決定的，該參數的最大值是由max_hw_sectors_kb值決定的。
I/O請求大於內部存儲塊大小時，一些固態硬盤會表現不佳，這種情況下，redhat推薦將max_hw_sectors_k減少至內部存儲塊大小
nomerges
大多數工作負載受益於請求合併，然而，禁用合併有助於調試目的，可設置參數爲0禁用合併，默認設置下爲啓用(設置爲1)。
nr_requests
限定同一時間排隊的讀和寫請求的最大數量。默認值爲 128， 即在請求讀或者寫操作的下一個進程進入睡眠模式前有 128 個讀請求和 128 個寫請求排隊。對於延遲敏感應用程序，降低該參數值，並限制存儲上的命令隊列深度，這樣回寫 I/O 便無法填充有寫請求的設備隊列。設備隊列填充時，其他嘗試執行 I/O 操作的進程會進入睡眠模式，直到有可用隊列空間。隨後請求會以 round-robin fashion（循環方式）分配，以防止一個進程持續使用隊列所有點。
optimal_io_siz e
一些存儲設備用此參數報告最佳 I/O 大小。如果報告該值，紅帽建議您儘可能將應用程序發出 I/O與最佳 I/O 大小對齊，並是最佳 I/O 大小的倍數。
read_ahead_kb
定義操作系統在順序讀取操作階段將預先讀取的千字節數量，以便存儲在頁面緩存中可能馬上需要的信息。設備映射程序經常受益於高read_ahead_kb 值 128 KB ；對於訪問將要被映射的設備這是一個良好起點。
旋轉
一些固態硬盤不能正確公佈其固態硬盤狀態，並且會如傳統旋轉磁盤載。如果您的固態硬盤不能將它自動設置它爲 0，那麼請您手動設置，禁用調度器上不必要的搜尋減少邏輯。
rq_affinity
默認設置下，I/O 完成能在不同處理器上進行，而不是限定在發出 I/O 請求的處理器上。將rq_affinity 設置爲 1 以禁用此能力，並只在發出 I/O 請求的處理器上執行完成。這能提高處理器數據緩存的有效性
7 爲性能配置文件系統
如果文件碎片或者資源爭用引起性能損失，性能通常可通過重新配置文件系統而提高性能。然而，在有些用例中，可能需要更改應用程序。
1 調整XFS
XFS 默認格式化和掛載設置適用於大多數工作負載。紅帽建議只在更改特定配置會對您的工作負載有益時對它們進行更改。
1 格式化選項參數
目錄塊大小
目錄塊大小影響每個 I/O 操可檢索或修改的目錄信息數量。目錄塊大小最小值即文件系統塊大小、（默認設置下爲4 KB）。目錄塊大小最大值爲 64 KB。
對於指定的目錄塊大小來說，大的目錄比小的目錄需要更多 I/O。因爲和小目錄塊的系統相比，大目錄塊大小的系統每 I/O 操作會使用更多的處理能力。因此，根據您的工作負載，推薦使用儘可能小的目錄和目錄塊大小。
如文件系統比大量寫和大量讀工作負載的列出項目數量少，紅帽推薦使用以下目錄塊大小，請見如下
〈表 5.1 “爲目錄塊大小推薦的最大目錄項” 〉
目錄塊大小 最大項 （大量讀操作） 最大項 （大量寫操作）
4 KB 100000–200000 1000000–2000000
16 KB 100000–1000000 1000000–10000000
64 KB > 1000000 >10000000在不同大小文件系統中，目錄塊大小對讀和寫工作負載的影響的情況請參見 XFS 文件。
分配組
分配組是獨立的結構，指示自由空間並在文件系統中一節分配 inodes。只要同時操作影響不同分配組，每個分配組能被獨立修改，這樣 XFS 同時執行分配和解除分配操作。因此文件系統中執行的同時操作數量和分配組數量相等。然而，由於執行同時操作的能力受到能夠執行操作的處理器數量的限制，紅帽建議分配組數量應多於或者等於系統中處理器的數量。
多個分配組無法同時修改單獨目錄。因此，紅帽推薦大量創建和移除文件的應用程序不要在單個目錄中存儲所有文件。
增長約束
如果在格式化之後，需要增加文件系統的大小，由於分配組大小在完成格式化之後不能更改，需要考慮佈局必須根據文件系統的最終能力，而非根據初始化能力調節分配組大小，佔據所有使用空間的文件系統中分配組數量不應超過數百，除非分配組處於最大尺寸(1TB),因此，紅帽想大部分文件系統推薦最大增長，允許文件系統是初始大小的十倍。
增長RAID數組的文件系統時，務必考慮額外護理，由於設備大小必須與固定多個分配組大小對齊，以便新分配組表頭在新增加的存儲中正確對齊，由於幾何在格式化之後不能被修改，因此新存儲也必須與已有存儲幾何一致，因此，在同一塊設備上，不能優化不同幾何的存儲。
iNode 大小和內聯屬性
如果iNode有足夠可用空間，XFS能直接將屬性名稱和值寫入inode,由於不需要額外的I/O，這些內聯屬性能夠被獲取和修改，達到比獲取單獨的屬性塊更快的量級。
默認 inode 大小爲 256 bytes。其中只有約 100 bytes 大小可用於屬性存儲，取決於 inode 上存儲的數據範圍指針數量。格式化文件系統時，增加 inode 大小能增加存儲屬性可用的空間數量。
屬性名稱和屬性值兩者都受到最大尺寸 254 bytes 的限制。如果名稱或者值超過 254 bytes 長度，該屬性會被推送到單獨的屬性快，而非存儲在內聯中。
RAID
如果使用軟件 RAID ，mkfs.xfs 會使用合適的帶狀單元和寬度自動配置底層的硬件。然而，如果使用硬件 RAID， 帶狀單元和寬度可能需要手動配置，這是因爲不是所有硬件 RAID 設備輸出此信息。使用 mkfs.xfs -d 選項配置帶狀單元和寬度。更多信息請參見 mkfs.xfs 手冊頁。
日誌大小
直到同步事件被觸發，待定的更改在內存中累計，這個時候它們會被寫入日誌。日誌大小決定同時於進行中的修改數量。它也決定在內存中能夠累計的最大更改數量，因此決定記錄的數據寫入磁盤的頻率。與大日誌相比，小日誌促使數據更頻繁地回寫入磁盤。然而，大日誌使用更多內存來記錄待定的修改，因此有限定內存的系統將不會從大日誌獲益。
日誌與底層帶狀單元對齊時，日誌表現更佳；換言之，它們起止於帶狀單元邊界。使用 mkfs.xfs -d 選項將日誌對齊帶狀單元，更多信息請參見 mkfs.xfs 手冊頁。
使用下列 mkfs.xfs 選項配置日誌大小，用日誌大小替換 logsize ：
# mkfs.xfs -l size=logsize更多詳細信息參見 mkfs.xfs 手冊頁：
$ man mkfs.xfs日誌帶狀單元
日誌寫操作起止於帶狀邊界時（與底層帶狀單元對齊），存儲設備上使用 RAID5 或 RAID6 佈局的日誌寫操作可能會表現更佳。mkfs.xfs 嘗試自動設置合適的日誌帶狀單元，但這取決於輸出該信息的 RAID 設備。如果您的工作負載過於頻繁地觸發同步事件，設置大日誌帶狀單元會降低性能。這是因爲小的寫操作需要填充至日誌帶狀單元，而這會增加延遲。如果您的工作負載受到日誌寫操作延遲的約束，紅帽推薦將日誌帶狀單元設置爲 1 個塊，從而儘可能地觸發非對齊日誌寫操作。支持的最大日誌帶狀單元爲最大日誌緩存的大小（256 KB）。因此底層存儲器可能擁更大的帶狀單元，且該帶狀單元能在日誌中配置。在這種情況下，mkfs.xfs 會發出警告,並設置一個大小爲32 KB 的日誌帶狀單元。使用以下選項之一配置日誌帶狀單元，其中 N 是被用於帶狀單元的塊的數量，size 是以 KB 爲單位的帶狀單元的大小。
mkfs.xfs -l sunit=Nb
mkfs.xfs -l su=size更多詳細信息參見 mkfs.xfs 手冊頁：
$ man mkfs.xfs2 掛載選項
iNode 分配
建議文件系統大於1TB,iNode64參數配置XFS,從而在文件系統中分配iNode和數據，這樣能保證iNode不會被大量分配到文件系統的起始位置，數據也不會被大量分配到文件系統的結束位置，從而提高大文件系統的性能表現。
日誌緩存和數量
日誌緩存越大，將所有變更寫入日誌的I/O操作越少，大日誌緩存能提高有大量I/O密集型總負載的系統表現，該工作負載沒有非易變的寫緩存。
通過 logbsize 掛載選項配置日誌緩存大小，並確定日誌緩存中信息存儲的最大數量。如果未設置日誌帶狀單元，緩存寫操作可小於最大值，因此不需要減少大量同步工作負載中的日誌緩存大小。
默認的日誌緩存大小爲 32 KB。最大值爲 256 KB， 也支持 64 KB、128 KB 或以 2 的倍數爲冪的介於 32 KB 和 256 KB 之間的日誌帶狀單元。
日誌緩存的數量是由 logbufs 掛載選項確定的。日誌緩存的默認值爲 8 （最大值），但能配置的日誌緩存最小值爲2。通常不需要減少日誌緩存的數量，除非內存受限的系統不能爲額外的日誌緩存分配內存。減少日誌緩存的數量會降低日誌的性能，尤其在工作負載對 I/O 延遲敏感的時候。
延延遲變更日誌
內存的變更寫入日誌前,XFS 的選項能集成這些改變。 delaylog 參數允許將頻繁更改的元數據週期性地寫入日誌，而非每次改變都要記錄到日誌中。此選項會增加故障中操作丟失的潛在數量，也會增加用於跟蹤元數據的內存大小。但是，它能通過按量級排序增加元數據的更改速度和可擴展性，爲確保數據和元數據寫入硬盤而使用 fsync、fdatasync 或sync 時，此選項不能減少數據或元數據的完整性。
2 調整 ext4
1 格式化選項
iNode 表初始化
在很大的文件系統上初始化文件系統中的所有iNode會耗時很久，默認設置下回推遲初始化過程(啓用遲緩iNode表初始化)，但是，如果沒ext4驅動，默認設置下回禁用遲緩iNode表初始化，可通過設置lazy_itable_init爲1啓用，那麼在掛載後，內核進程繼續初始化文件系統
2 掛載選項
inode 表初始化率
啓用遲緩 inode 表初始化時，您可通過指定 init_itable 參數值控制初始化發生的速率。執行後臺初始化的時間約等於 1 除以該參數值。默認值爲 10。
自自動文件同步
對現有文件重命名、截斷或重寫後，一些應用程序無法正確執行 fsync。默認設置下，執行這些操作之後，ext4 會自動同步文件。但這樣會比較耗時。
如果不需要此級別的同步，您可在掛載時通過指定 noauto_da_alloc 選項禁用該行爲。如果noauto_da_alloc 已設置，應用程序必須明確使用 fsync 以確保數據的持久化。
日誌 I/O 優先級
默認設置下日誌 I/O 優先級爲 3，該值比常規 I/O 的優先級略高。您可在掛載時使用
journal_ioprio 參數控制日誌 I/O 的優先級。journal_ioprio 的有效值範圍爲從 0 到 7，
其中 0 表示具有最高優先級的 I/O。
3 調整 btrfs
自紅帽企業版 Linux 7.0 起，btrfs 作爲技術預覽而爲用戶提供。如果 btrfs 受到全面支持，本章節將在未來更新。
調整 GFS2
本章節涵蓋 GFS2 文件系統在格式化和掛載時可用的調整參數。
目目錄間距GFS2 掛載點的頂層目錄中創建的所有目錄都是自動間隔，以減少目錄中的碎片並提高寫速度。爲像頂層目錄間隔其他目錄，用 T 屬性標註該目錄，如示，用您想間隔該目錄的路徑替代 dirname。
# chattr +T dirnamechattr 作爲 e2fsprogs 軟件包中的一部份爲用戶提供。
減減少爭用GFS2 使用全域鎖機制，該機制需要簇中節點之間的通信。多節點之間的文件和目錄爭用會降低性能。通過最小化多節點間共享的文件系統區域，您可將緩存失效的風險最小化.
4 網絡
網絡子系統由很多敏感連接的不同部分構成。紅帽企業版 Linux 7 網絡因此旨在爲大多數工作負載提供最佳性能，並且自動優化其性能。因此，不需要時常手動調節網絡性能。本章探討了可以對功能網絡系統做的進一步優化。
1 注意事項
若需要調優，用戶需要對redhat 企業版Linux網絡包的接受有充分認識，
2 基本原理
1 網絡收包處理基本原理
發送至redhatLinux 系統的數據包是由 NIC(網絡接口卡)接受的，數據包置於內核硬件緩衝或者是循環緩衝區中，NIC之後會發送一個硬件終端請求，促使生成一個軟件中斷操作來處理該中斷請求，作爲軟件中斷操作的一部分，數據包會由緩衝區轉移到網絡堆棧，根據數據包及用戶的網絡配置，數據包之後會被轉發，刪除或者轉移到一個應用程序的socket接受隊列，並將從網絡堆棧中刪除，這一進程會持續進行，直到NIC硬件緩衝區中沒有數據包或者一定數量的數據包（在 /proc/sys/net/core/dev_weight 中指定）被轉移。
2 網絡性能影響因素
網絡性能問題最常見的是由硬件故障或者基礎結構層故障造成的
數據包接受瓶頸
雖然網絡堆棧基本上是自我優化的，但是在網絡堆棧處理過程中後很多呆滯瓶頸且降低性能的問題
NIC 硬件緩衝區或循環緩衝區
如果大量數據包被棄置，硬件緩衝區就會成爲瓶頸，要監控系統傳動的數據包，需要使用ethool硬件或軟件中斷隊列
中斷會增加延遲，爭用處理器。
應用程序的socket接收隊列
應用是程序接收隊列的瓶頸是大量的數據包沒有複製到請求的應用程序中，或者是UDP輸入錯誤增加，此錯誤在/proc/net/snmp中。
3 監控和診斷性能問題
1 ss
ss 是一個命令行實用程序，顯示關於 socket的數據信息，允許管理員隨時評估設備性能。ss 列表會默認打開沒有注意到但已建立了連接的 TCP socket，但是會提供大量有用的選項來給管理員篩選特定的 socket數據。
紅帽推薦在紅帽企業版 Linux 7 中使用 ss 來替代 netstat。
2 ip
ip 實用程序允許管理員管理和監控線路、設備、路由策略及通道。ip monitor 指令可以持續監控設備、地址和線路的狀況。
3 dropwatch
Dropwatch 是一個交互工具，用來監控和記錄內核棄置的數據包。
4 ethtool
ethtool 實用程序允許管理員查看和編輯網絡接口卡的設置。它有助於觀察特定設備的數據，例如該設備棄
置的數據包數量。
用戶可以使用 ethtool -S 查看特定設備的計數狀態和想要監控的設備名稱。
ethtool -S devname5 /proc/net/snmp
/proc/net/snmp 文件顯示的數據是snmp用來監控和管理IP，ICMP，TCP和UDP的，定期檢查此文件可以協助管理員識別異常值，從而識別潛在的性能問題，如 UDP輸入錯誤(InErrors)增加，且錯誤在/proc/net/snmp中，就意味着socket接收隊列中出現了瓶頸。
[root@centos8 ~]# cat /proc/net/snmp
Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates
Ip: 1 64 837779 0 0 0 0 0 837749 711025 0 2 0 60 30 0 0 0 0
Icmp: InMsgs InErrors InCsumErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps
Icmp: 28091 13028 0 28088 0 0 0 0 3 0 0 0 0 0 28125 0 28122 0 0 0 0 0 3 0 0 0 0
IcmpMsg: InType3 InType8 OutType0 OutType3
IcmpMsg: 28088 3 3 28122
Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts InCsumErrors
Tcp: 1 200 120000 -1 15481 26 14418 25 4 793658 977256 12557 1 94 0
Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors InCsumErrors IgnoredMulti
Udp: 7245 34 0 884 0 0 0 8577
UdpLite: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors InCsumErrors IgnoredMulti
UdpLite: 0 0 0 0 0 0 0 04 配置工具
1 網絡性能tuned-adm配置文件
tuned-adm 對很多特定用例提供不同配置文件以提高性能
延遲性能
網絡延遲
網絡吞吐量
2 配置硬件緩衝區
如果硬件緩衝區棄置了大量的數據包，那麼有很多可能的解決方法。
減緩輸入流量
篩選傳入的流量，減少加入的多播組數量或減少廣播流量，以降低隊列填充率。
調整硬件緩衝隊列
通過增加隊列的大小以減少傳動的數據包數量，使其不易過剩，用戶可以使用ethtool 指令來更改網絡設備的rx/tx參數
ethtool --set-ring devname value改變隊列的排除率
設備重量是指設備一次可以接收的數據包數量（單個預定處理器訪問）。用戶可以通過提高設備重量以增加隊列的排出比率，這由dev_weight 參數控制。此參數可以通過變/proc/sys/net/core/dev_weight 文件的內容來做臨時更改，或使用 sysctl 進行永久更改，這由 procps-ng 數據包提供。
改變隊列排出率通常是緩解不良網絡性能最簡單的方法。但是，增加設備一次可以接收的數據包數量會消耗處理器額外的時間，在此期間不可調度其他進程，因此可能會導致其他性能問題。
3 配置中斷隊列
如果分析顯示高延遲，系統可能受益於基於輪詢的包接收，而不是基於中斷的包接收。
1 配置繁忙輪訓
繁忙輪詢有助於減少網絡接收路徑中的延遲， 使 socket 層代碼查詢網絡設備的接收隊列並禁用網絡中斷，這可以消除由於中斷和由此產生的環境切換所造成的延誤。但是，它會增加 CPU 的使用率。繁忙輪詢可以防止CPU 進入睡眠狀態，睡眠狀態會造成額外的功耗。
繁忙輪詢是默認禁用的。要在特定 socket 中啓用繁忙輪詢，請按以下指示：
將 sysctl.net.core.busy_poll 設置爲除 0 以外的值。這一參數控制的是 socket 輪詢和選擇位於等待設備隊列中數據包的微秒數。紅帽推薦值爲 50。
添加 SO_BUSY_POLL socket 選項至 socket。
要全局啓用繁忙輪詢， 須將 sysctl.net.core.busy_read 設置爲除了 0 以外的值。這一參數控制了socket 讀取位於等待設備隊列中數據包的微秒數，且設置了 SO_BUSY_POLL 選項的默認值。紅帽推薦在socket 數量少時將值設置爲 50 ， socket 數量多時將值設置爲 100。對於 socket 數量極大時（超過幾百），請使用 epoll。
繁忙輪詢由以下驅動程序支持。紅帽企業版 Linux 7 支持這些驅動程序。
bnx2x
be2net
ixgbe
mlx4
myri10ge
4 配置socket接收隊列
如果分析數據顯示，數據包由於 socket 隊列排出率太慢而被棄置，有幾種方法來解決由此產生的性能問題。
減少傳入流量的速度
減少隊列填充速率可以通過篩選或棄置進入隊列前的數據包，或是減少設備重量。
增加應用程序的 socket 隊列深度
如果分析數據顯示，數據包由於 socket 隊列排出率太慢而被棄置，有幾種方法來解決由此產生的性能問題
減少傳入流量的速度
減少隊列填充速率可以通過篩選或棄置進入隊列前的數據包，或是減少設備重量。
設備重量是指設備一次可以接收的數據包數量，設備重量由dev_weight參數控制，此參數可以通過改變/proc/sys/net/core/dev_weight 文件的內容來做臨時更改，或者是使用sysctl 來做永久更改
[root@centos8 ~]# cat /proc/sys/net/core/dev_weight
64增加隊列深度
增加應用程序的 socket 隊列深度往往是提高 socket 隊列排出率最簡單的方法，但不可能是一個長期的解決方法。
要增加隊列深度就要增加 socket 接收緩衝區的大小，可以做如下變化：
增加 /proc/sys/net/core/rmem_default 值
這一參數控制 socket 使用的接收緩衝區的默認大小，這個值必須小於
/proc/sys/net/core/rmem_max 的值。
使用 setsockopt 配置較大的 SO_RCVBUF 值
這一參數控制的是以字節爲單位的 socket 接收緩衝區的最大值。使用 getsockopt 系統調用來確
定當前緩衝區的值。
5 配置 RSS
RSS(接收端調整)，也叫做多隊列接受，是通過一些基於硬件的接受隊列來分配網絡接受進程，從而使得入站網絡流量可以由多個CPU進行處理，RSS可以用來緩解接受中斷進程中由單個CPU過載而出現的瓶頸，並減少網絡延遲。
要確定您的網絡接口卡是否支持 RSS，須查看多箇中斷請求隊列是否在 /proc/interrupts 中有相關的接口。例如，如果用戶對 p1p1 接口有興趣：
# egrep 'CPU|p1p1' /proc/interruptsCPU0 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 的輸出。
例如，如果用戶對 PCI 地址爲0000:01:00.0 的設備感興趣，可以通過以下指令來列出該設備中斷請求隊列：
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 參數進行配置。通常，這都是在 /sys/class/net/device/queues/rx-queue/ 中進行配置，其中 device 是網絡設備的名稱（比如 eth1），rx-queue 是適當的接收隊列名稱。
配置 RSS 時，紅帽推薦限制每一個物理 CPU 內核的隊列數量。超線程在分析工具中通常代表獨立的內核，但是所有內核的配置隊列，包括如超線程這樣的邏輯內核尚未被證實對網絡性能有益。
啓用時，基於每個隊列的 CPU 進程數量，RSS 在 CPU 間平等地分配網絡進程。但是，用戶可以使用
ethtool --show-rxfh-indir 和 --set-rxfh-indir 參數來更改網絡活動的分配方式，並權衡哪種類型的網絡活動更爲重要。
irqbalance 後臺程序可與 RSS 相結合，以減少跨節點內存及高速緩存行反彈的可能性。這降低了處理網絡數據包的延遲。
6 配置 RPS
RPS（接收端包控制）與 RSS類似，用於將數據包指派至特定的 CPU 進行處理。但是，RPS 是在軟件級別上執行的，這有助於防止單個網絡接口卡的軟件隊列成爲網絡流量中的瓶頸。
較之於基於硬件的 RSS ，RPS 有幾個優點：
RPS 可以用於任何網絡接口卡。
易於添加軟件過濾器至 RPS 來處理新的協議。
RPS 不會增加網絡設備的硬件中斷率。但是會引起內處理器間的中斷。
每個網絡設備和接收隊列都要配置 RPS，在/sys/class/net/device/queues/rxqueue/rps_cpus 文件中，device 是網絡設備的名稱（比如 eth0），rx-queue 是適當的接收隊列名稱（例如 rx-0）。
rps_cpus 文件的默認值爲 0。這會禁用 RPS，以便處理網絡中斷的 CPU 也能處理數據包。
要啓用 RPS，配置適當的 rps_cpus 文件以及特定網絡設備和接收隊列中須處理數據包的 CPU 。
rps_cpus 文件使用以逗號隔開的 CPU 位圖。因此，要讓 CPU 在一個接口爲接收隊列處理中斷，請將它們在位圖裏的位置值設爲 1。例如，用 CPU 0、1、2 和 3 處理中斷，將 rps_cpus 的值設爲 00001111
（1+2+4+8），或 f（十六進制的值爲 15）。
對於單一傳輸隊列的網絡設備，配置 RPS 以在同一內存區使用 CPU 可獲得最佳性能。在非 NUMA 的系統中，這意味着可以使用所有空閒的 CPU。如果網絡中斷率極高，排除處理網絡中斷的 CPU 也可以提高性能。
對於多隊列的網絡設備，配置 RPS 和 RSS 通常都不會有好處，因爲 RSS 配置是默認將 CPU 映射至每個接收隊列。但是，如果硬件隊列比 CPU 少，RPS依然有用，並且配置 RPS 是來在同一內存區使用 CPU。
7 配置 RFS
RFS(接收端流控制) 擴展了RPS 的性能以增加CPU緩存命中率，以此減少網絡延遲，RPS僅基於隊列長度RFS 使用 RPS 後端預測最合適的 CPU，之後會根據應用程序處理數據的位置來轉發數據包。這增加了 CPU 的緩存效率。
RFS 是默認禁用的。要啓用 RFS，用戶須編輯兩個文件：
/proc/sys/net/core/rps_sock_flow_entries
設置此文件至同時活躍連接數的最大預期值。對於中等服務器負載，推薦值爲 32768 。所有輸入的值四捨五入至最接近的2的冪。/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 相結合，以將應用程序固定至特定的內核、 socket 或 NUMA 節點。這可以有助於防止數據處理紊亂。
8 配置加速 RFS
加速 RFS 是通過添加硬件協助來增速的。如同 RFS，數據轉發是基於應用程序處理數據包的位置。但不同於傳統 RFS 的是，數據是直接發送至處理數據線程的本地 CPU：即運行應用程序的 CPU，或是對於在緩存層次結構中的 CPU 來說的一個本地 CPU。
加速 RFS 只有滿足以下條件纔可以使用：
網絡接口卡須支持加速 RFS。加速 RFS 是由輸出 ndo_rx_flow_steer() netdevice 功能的接口卡支持。
ntuple 篩選必須啓用。
一旦滿足了這些條件，隊列映射 CPU 就會基於傳統 RFS 配置自動導出。即隊列映射 CPU 會基於由每個接收隊列的驅動程序配置的 IRQ 關聯而自動導出。從 ＜第 6.3.7 節 “配置 RFS”＞ 中來獲取配置傳統 RFS 的信息,紅帽推薦在可以使用 RFS 以及網絡接口卡支持硬件加速時使用加速 RFS。
5 其他網絡調優參數
net.ipv4.tcp_max_tw_buckets
Timewait 的數量，默認爲8192
net.ipv4.ip_local_port_range= 1024 65000
允許系統打開的端口範圍，前面爲下線，後面爲上線。默認是 32768 61000
注意： 此可用範圍決定了最後timewait狀態的鏈接數量：下面兩個選項可有效降低 tw狀態鏈接數量
net.ipv4.tcp_tw_recycle={0|1}
是否啓用timeout快速回收：注意： 開啓此功能在nat環境下可能會出現嚴重問題，因爲TCP有一種行爲，他可以緩衝每個鏈接最新的時間戳，後續請求如果時間小於緩衝中的時間戳，即被視爲無效並丟棄相應的請求報文，Linux是否啓用這種行爲取決於tcp_timestamp 和 tcp_tw_recycle ，而前一個參數默認是啓動的，所以啓用後面的參數就會激活此功能，
如果是NAT，爲了安全起見，應該禁用tcp_tw_recycle， 另一種解決方案：把tcp_timestamps設置爲0.tcp_tw_recycle 設置爲1 並不會生效，
net.ipv4.tcp_tw_reuse={0|1}
是否開啓tw 重用，即是否允許將time_wait sockets 用於新的TCP 鏈接
net.ipv4.tcp_sycncookies={0|1}
是否開啓SYN cookies ， 及當SYN 等待隊列溢出時，是夠啓用cookies 功能 （是否能夠儘可能容納能多請求）
net.ipv4.tcp_timestapms=0
tcp報文時間錯，關閉可以避免序列號的卷繞 （防止繞一圈回來的問題）
net.ipv4.tcp_max_syn_backlog= 262144
保存的那些尚未收到客戶端確認信息的鏈接請求的最大值，默認爲128，可增大
net.ipv4.tcp_synack_retries= # 表示在服務器端如果沒有收到客戶端相應時發送數據的次數
爲了打開對端鏈接，內核需要發送一個SYN並附帶一個迴應前面的一個SYN的ACK， 這業績所有的三次握手中的第二次，這個設置決定了內核放棄鏈接之前發送SYN+ACK 包的數量，繁忙的服務器上建議設置爲0或者1；
net.ipv4.tcp_syn_Retries=2622144
表示服務器主動發送TCP 鏈接的次數
在內核中放棄建立連接之前發送SYN包的數量，繁忙的服務器上建議設置爲0或者1
net.ipv4.tcp_max_orphans=2622144
系統中最多有多少個TCP套接字不被關聯到任何一個用戶文件句柄上，如果超過這個數字，連接將即可被複位毛病發音出警告信息，這個限制僅僅是爲了防止簡單的Dos，不能過分依賴人文減少這個值，如果需要修改，在確保有足夠內存可能的前提下，應該增大此值。
net.ipv4.tcp_fin_timeout=5
如果套接字由本端要求關閉，這個參數決定了我他保持FIN_WAIT-2狀態的時間，缺省值是60秒
然而，對端可能會出錯或者意外宕機永遠不會關閉鏈接，及時是一個輕量級的web，也可能會有大量的四套接字而內存溢出的風險，fin-wait-2 的危險性比fin-wait-1 要小，因爲每個鏈接最多隻能消耗1.5K內存，但是他們的生存期長一些。
net.ipv4.tcp_keepalive_time=30
當keepalive啓動的時候，TCP 發送keepalive消息的頻度，默認是2小時
以 core 開頭的主要用於定義非TCP 相關的緩衝單位是字節
net.core.rmem_max=8388608
定義內核用於所有類型的鏈接的最大接受緩衝大小
net.core.rmem_Default=65536
定義內核所有類型的鏈接的默認接受緩衝大小
net.core.wmem_max=8338608
定義內核用於所有類型的鏈接的最大發送緩衝大小
net.core.wmem_default=65536
定義內核用於所有類型的鏈接的默認發送緩衝大小
net.ipv4.tcp_mem='8388608 8388608 8388608 '
定義TCP 協議棧使用的內存空間，分別爲最小值，默認值和最大值
net.ipv4.tcp_rmem='4096 37380 8388608
定義TCP 協議棧中用於接受緩衝的內存空間，第一個是最小值，即便當前主機內存空間吃緊，也得保證TCO協議棧至少有次大小的空能空間，第二個值爲默認值，他會覆蓋net.core.rmem_Default 中爲所有協議定義的接受緩衝的大小，第三個值爲最大值，既能用於TCP接受緩衝的最大內存空間
net.ipv4.tcp_wmem='4096 65535 8388608'
定義TCP協議棧用於發送緩衝區的內存空間
5 相關工具詳解
1 irqbalance
是一個命令行工具，在處理器中分配硬件中斷以提高系統性能，默認設置下再後臺程序運行，但只能通過 --oneshot 選項運行一次
以下參數可用於提高性能
--powerthresh
CPU 進入節能模式之前，設定可空閒的 CPU 數量。如果有大於閥值數的 CPU 是大於一個標準的偏差，該差值低於平均軟中斷工作負載，以及沒有 CPU 是大於一個標準偏差，且該偏差高出平均，並有多於一個的 irq 分配給它們，一個 CPU 將處於節能模式。在節能模式中，CPU 不是irqbalance 的一部分，所以它在有必要時纔會被喚醒。
--hintpolicy
決定如何解決 irq 內核關聯提示。有效值爲 exact（總是應用 irq 關聯提示）、subset （irq 是平衡的，但分配的對象是關聯提示的子集）、或者 ignore（irq 完全被忽略）。
--policyscript
通過設備路徑、當作參數的irq號碼以及 irqbalance 預期的零退出代碼，定義腳本位置以執行每個中斷請求。定義的腳本能指定零或多鍵值對來指導管理傳遞的 irq 中 irqbalance。
下列是爲效鍵值對：
ban
有效值爲 true（從平衡中排除傳遞的 irq）或 false（該 irq 表現平衡）。balance_level 允許用戶重寫傳遞的 irq 平衡度。默認設置下，平衡度基於擁有 irq 設備的 PCI 設備種類。有效值爲 none、package、cache、或 core。 numa_node 允許用戶重寫視作爲本地傳送 irq 的 NUMA 節點。如果本地節點的信息沒有限定於 ACPI，則設備被視作與所有節點距離相等。有效值爲識別特定 NUMA 節點的整數（從0開始）和 -1，規定 irq 應被視作與所有節點距離相等。
--banirq
將帶有指定中斷請求號碼的中斷添加至禁止中斷的列表。
您也可以使用 IRQBALANCE_BANNED_CPUS 環境變量來指定被 irqbalance 忽略的 CPU 掩碼。
2 tuna
Tuna 使您能夠控制處理器和調度關聯。此章節包含命令行界面，但是也可使用有相同功能範圍的圖形界面。運行命令行 tuna 啓動圖形工具。
Tuna 接受多種按順序處理的命令行參數。下列命令將負載分配到四個 socket中。
tuna --socket 0 --isolate \n --thread my_real_time_app --move \n --
irq serial --socket 1 --move \n --irq eth* --socket 2 --spread \n --
show_threads --show_irqs--gui
打開圖形用戶界面。
--cpu
取用由 Tuna 控制的 CPU 逗號分隔列表。直到指定新列表前此列表均有效。
--config_file_apply
將配置文件名稱應用於系統。
--config_file_list
列出預加載配置文件。
--cgroup
用於連接 --show_threads。如果啓用控制組，顯示控制組類型，該控制組處理顯示帶有 --show_threads 所屬於的控制組類型。
--affect_children
指定後，Tuna 影響子線程以及父線程。
--filter
過濾顯示，只顯示受影響的實體。
--isolate
取用 CPU 的逗號分隔列表。Tuna 從指定的 CPU 中遷移線程。
--include
取用 CPU 的逗號分隔列表，Tuna 允許所有線程在指定的 CPU 上運行。
--no_kthreads
指定此參數後，Tuna 不影響內核線程。
--move
將選擇的實體移至指定的 CPU 中。
--priority
指定線程調度器策略和優先級。有效調度器策略爲 OTHER、FIFO、 RR、BATCH、或者 IDLE。當策略爲 FIFO 或者 RR，有效的優先級值爲從 1（最低）到 99（最高）的整數。默認值是 1。例如，tuna--threads 7861 --priority=RR:40 爲線程 7861 設定了 RR（輪循）的策略和 40 的優先級。
當策略是 OTHER、BATCH、或者 IDLE，唯一有效優先級值爲 0，它也是默認值。
--show_threads
顯示線程列表。
--show_irqs
顯示 irq 列表。
--irqs
取用受 Tuna 影響的 IRQ 逗號分隔列表 。直到指定新列表之前此列表均有效。使用 + 可將 IRQ 添加至列表，使用 - 可從列表中移除。
--save
將內核線程調度保存至指定文件。
--sockets
取用受 Tuna 控制的 CPU socket逗號分隔列表。該選項考慮了系統的拓撲結構，例如共享單一處理器緩存，且在同一個物理芯片上的核心。
--threads
取用受 Tuna 控制的線程逗號分隔列表。直到指定新列表之前此列表均有效。使用 + 可將線程添加至列表，- 可從列表中移除。
--no_uthreads
禁止影響用戶線程的操作。
--what_is
更多幫助，請參見選定的實體。
--spread
平均分配 --threads 指定的線程至 --cpus 指定的 CPU。
3 ethtool
ethtool 工具允許管理員查看和編輯網絡接口卡設置。這有助於觀察某些設備的統計信息，比如被設備丟棄的數據包的數量。
4 ss
ss 是一個命令行工具，顯示 socket的統計信息，允許管理員超時訪問設備性能。默認設置下，ss 列出打開的非監聽且已建立聯繫的 TCP socket，但向管理員提供一些爲篩選掉特定 socket數據的有用選項。
ss -tmpie 是一個常用命令，顯示所有 TCP socket（t、內部 TCP 信息（i）、 socket內存使用 （m）、
使用 socket的進程 （p）、和詳細的 socket信息（i）。
5 tuned
Tuned 是一個調整的後臺程序，在某種工作負載量下通過設置調整配置文件使操作系統有更好的性能表現。
對其進行配置，使其對 CPU 和網絡使用的變化做出響應，調整設置以提高激活設備的性能，並減少在未激活設備中的能耗。
在 /etc/tuned/tuned-main.conf 文件中編輯 dynamic_tuning 參數以配置動態調整行爲。您也能在調整檢查使用和更新調整細節之間，使用 update_interval 參數以秒爲單位配置時間。
6 tuned-adm
tuned-adm 是一個命令行工具，提供一些不同配置文件以提高一些特定用例性能。它也提供一個評估系統和輸出推薦的調整配置文件的子命令（tuned-adm recommend）。在您系統安裝時它也能設置默認配置文
件，以便能用於返回默認配置文件。
自紅帽企業版 Linux 7 起，tuned-adm 有能力運行所有命令，這些命令是啓用和禁用調整配置文件的一部分。這允許您添加 tuned-adm 中不可用的環境特定檢測。例如在選擇應用何種調整配置文件之前，檢測系統是否是主數據庫節點。
紅帽企業版 Linux 7 在配置定義文件中提供 include 參數，允許您將自己的 tuned-adm 配置文件建立在存在的配置文件基礎上。
以下調整配置文件是隨 tuned-adm 一起提供的，並由紅帽企業版 Linux 7 支持。
吞吐量性能
服務器配置文件的重點在於提高吞吐量。這是默認配置文件，並是爲大多數系統推薦的。
通過設置 intel_pstate 和 max_perf_pct=100，與節約能耗相比，該配置文件更注重性能表現。它能啓用透明大頁面，使用 cpupower 來設置 performance CPU 頻率管理器，並將輸入/輸出調度器設置爲 deadline。它同樣將 kernel.sched_min_granularity_ns 設置爲10 μ s，將 kernel.sched_wakeup_granularity_ns 設置爲 15 μ s，以及將
vm.dirty_ratio 設置 40%。
延遲性能
服務器配置文件的重點在於降低延遲。該配置文件是爲延遲敏感的工作負載所推薦的，其中工作負載會從 c- 狀態調整和透明大頁面增加的 TLB 高效性中獲益。
通過設置 intel_pstate 和 max_perf_pct=100，與節約能耗相比，該配置文件更注重性能表現。它能啓用透明大頁面，使用 cpupower 來設置 performance CPU 頻率管理器，並請求值爲 1 的 cpu_dma_latency。
網絡延遲
服務器配置文件的重點在於降低網絡延遲。通過設置 intel_pstate 和 max_perf_pct=100，與節約能耗相比，該配置文件更注重性能表現。它禁用透明大頁面以及自動 NUMA 平衡 。它使用 cpupower 來設置 performance CPU 頻率管理器，並請求值爲 1 的 cpu_dma_latency。它同樣將 busy_read 和 busy_poll 的時間設置爲 50 μ s，並將 tcp_fastopen 設置爲 3。
網絡吞吐量
服務器配置文件的重點在於提高網絡吞吐量。
通過設置 intel_pstate 和 max_perf_pct=100，與節約能耗，該配置文件更注重性能表現。它能啓用透明大頁面，使用 cpupower 來設置 performance CPU 頻率管理器，它同樣將kernel.sched_min_granularity_ns 設置爲 10 μ
s，kernel.sched_wakeup_granularity_ns 設置爲 15 μ s，以及 vm.dirty_ratio 設置爲 40%。
虛擬來賓
虛擬來賓是一個重點在於優化紅帽企業版 Linux 7 虛擬機器性能的配置文件。
通過設置 intel_pstate 和 max_perf_pct=100，與節約能耗相比，該配置文件更注重性能表現。它降低了虛擬內存的交換。啓用透明大頁面，使用 cpupower 來設置 performance CPU頻率管理器。它也能將 kernel.sched_min_granularity_ns 設置爲 10 μ
s，kernel.sched_wakeup_granularity_ns 設置爲 15 μ s，以及將 vm.dirty_ratio設置爲 40%。
虛擬-主機
虛擬主機是一個重點在於優化紅帽企業版Linux 7虛擬主機的性能的配置文件。
通過設置 intel_pstate 和 max_perf_pct=100，相比節約能耗，該配置文件更注重性能表現。它降低了虛擬內存的交換。它能啓用透明大頁面，更頻繁地重寫髒頁到磁盤。使用 cpupower來設置 performance CPU 頻率管理器，它將 kernel.sched_min_granularity_ns 設置爲 10 μ 秒，kernel.sched_wakeup_granularity_ns 設置爲 15 μ秒，kernel.sched_migration_cost 設置爲 5 μ 秒，以及 vm.dirty_ratio 設置爲
40%
7 perf
perf 提供一些有用的指令，此章節列出了其中一些指令。perf 的更多信息請參見《 紅帽企業版 7 開發者指
南》， 可在下列網站中查找 http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ 或者參見手冊頁。
perf stat
此命令爲常見性能事件提供整體數據，包括執行步驟和消耗所用的時間週期。您可使用選項標誌來收集事件數據，而非默認測量事件。自紅帽企業版 Linux 6.4 起，根據一個或多個特定控制組（c組），可使用 perf stat 篩選監控。
更多信息請參見手冊頁：
$ man perf-stat
perf record
此命令將性能數據記錄到隨後可使用 perf report 分析的文件中。更多信息，請參見手冊頁。$ man perf-record
perf report
此命令從文件中讀取性能數據並分析記錄數據，更多信息，請參見手冊頁。
$ man perf-report
perf list
此命令列出特定機器上有效事件。這些事件因系統性能監控硬件和軟件配置而異。更多信息，請參見手冊頁。
$ man perf-list
perf top
此命令執行與 top 工具相似的功能。它實時生成並顯示性能計數器配置文件。更多信息，請參見手冊頁。
$ man perf-top
perf trace
此命令執行與 strace 工具相似的功能。它監控特定線程或進程使用的系統調用以及該應用程序接收的所有信號。可獲得其他的跟蹤目標。請參見手冊頁以查看完整列表：
$ man perf-trace
8 x86_energy_perf_policy
x86 energyperfpolicy 工具允許管理員定義性能和能效的相對重要性。由 kernel-tools 軟件包提供。
查看當前策略，運行以下命令：
x86_energy_perf_policy -r設置新策略，運行以下命令：
x86_energy_perf_policy profile_name用以下配置文件的其中之一替代配置文件名。
performance
處理器不爲節能而降低性能。這是默認值。
normal
處理器能容忍由潛在的顯著節能所造成的微小性能下降。對於大多數服務器和桌面而言這是合理的節省。
powersave
處理器接受潛在的顯著性能下降，以便充分利用能效。
9 turbostat
turbostat 工具提供系統處於不同狀態所用時間的詳細信息。 Turbostat 由 kernel-tools 軟件包提供。
默認設置下，turbostat 爲整個系統顯示計數器結果的摘要，隨後每隔五秒出現計數器結果，以下列標頭：
pkg
處理器軟件包編號。
core
處理器內核編號。
CPU
LinuxCPU（邏輯處理器）編號。
%c0
cpu 執行完畢的指令間隔百分比。
GHz
當 CPU 處於 c0 狀態時，平均時鐘速度。
TSC
整個間隔進程中的平均時鐘速度。
%c1、 %c3、和 %c6
處理器分別在 c1、c3 或者 c6 狀態下間隔百分比。
%pc3 或者 %pc6
處理器分別在 pc3 或者 pc6 狀態下的間隔百分比。
使用 -i 選項指定計數器結果間的不同週期，例如：運行 turbostat -i 10 改爲每10秒顯示結果。
10 numastat
1 概述
numastat 由 numactl 軟件包提供，並以每個 NUMA 節點爲基礎，爲處理器和操作系統顯示內存統計數據（例如分配時斷時續）。
2 numastat 默認跟蹤類別
numastat 命令的默認跟蹤類別如下所示：
numa_hit
成功分配至該節點的頁面數量。
numa_miss
因預期節內存不足分配至該節點的頁面數量。每個 numa_miss 事件在另一個節點上都有相應的
numa_foreign 事件。
numa_foreign
原本預期分配至此節點，而改爲分配至其他節點的頁面數量。numa_foreign 事件在另外節點上,有一個相應的 numa_miss 事件。
interleave_hit
成功分配至該節點、交叉存取策略頁面數量。
local_node
由節點上進程成功分配至該節點的頁面數量。
other_node
由其他節點的進程分配至該節點的頁面數量。
提供以下任一選項會改變按兆字節內存計算的顯示單元（約兩個小數位），且其他指定的 numastat 行爲也會改變，描述如下：
-c
水平濃縮信息的顯示錶。這有助於含有大量 NUMA 節點的系統，在某種程度上列寬度和列內空間不可預測。使用該選項時，內存的數量四捨五入到最近的兆。
-m
根據單位節點，顯示系統範圍的內存使用信息，與 /proc/meminfo 中的信息類似。
-n
使用更新的格式、兆爲度量單位，顯示和如下原始 numastat 命令相同信息：（numa_hit、numa_miss、numa_foreign、interleave_hit、local_node 和 other_node）。
-p pattern
爲指定模式顯示單位節點內存信息。如果模式的值是由數字組成的，numastat 假定它是數字進程標識符。否則，numastat 從進程命令行查找指定的模式。
假定 -p 選項值後輸入的命令行參數是附加模式，目的是將其過濾 。附加模式擴展，而非縮減過濾器。
-s
將顯示的數據按降序排列，以便將最大的內存消耗者（根據所有列）列在首位。
您也可指定節點，這樣表格將根據節點列分類。使用該選項時，節點值必須馬上採用 -s 選項，具體如下：
numastat -s2
不要在選項和其值之間使用空格符。
-v
顯示更多冗長的信息。即多進程的進程信息將顯示每個進程的細節信息。
-V
顯示 numastat 版本信息。
-z
從顯示的信息中省略表中只爲 0 值的行和列。請注意爲了便於顯示，一些四捨五入後接近 0 的值不會從顯示輸出中被省略。
11 numactl
1 概述
Numactl 允許管理員使用指定的調度或內存放置策略來運行進程。Numactl 也能爲共享的內存段或文件設置永久策略，以及進程的處理器關聯和內存關聯。
2 參數
Numactl 提供許多實用的選項。此附錄概述一部分選項，也爲用戶提供了一些使用建議，但並不詳細。
--hardware
顯示系統中的可用節點，且包含節點間的相對距離的詳細目錄。
--membind
確保內存只由指定節點分配。如果指定地點沒有足夠的可用內存，分配會失敗。
--cpunodebind
確保指定命令及其子進程只在指定的節點上執行。
--phycpubind
確保指定的命令及其子進程只在指定的處理器上執行。
--localalloc
指明內存應當始終從本地節點分配。
--preferred
指定分配內存的優選節點。如果內存不能從指定的節點分配，其他的節點將被用於回退。
12 numad
1 概述
numad 是一個自動 NUMA 關聯管理後臺程序。爲了動態提高 NUMA 資源分配和管理，它在系統內監控
NUMA 的拓撲結構和資源使用。
注意啓用 numad 時 ，其行爲將替代默認的自動 NUMA 平衡的行爲。
2 在命令行使用 numad
將 numad 作爲執行表使用，只需運行：
numadnumad 運行的時候，其活動被記錄在 /var/log/numad.log。它會持續運行直到被以下命令終止：
numad -i 0終止 numad 不會移除它所做的提高 NUMA 關聯的變更。如果系統使用有顯著的變化，再次運行 numad 能調整關聯來提高新條件下的性能。
如需將 numad 管理限制爲特定進程，用下列選項來啓動它：
numad -S 0 -p pid
-p pid
該選項將指定的 pid 添加到顯式的包含列表中。當指定的進程達到 numad 進程的顯著門限值，指定的進程纔會被管理。
-S 0
它將進程掃描的類型設置爲 0，這會將 numad 管理限制到顯式包含的進程
3 將 numad 作爲服務運行
它嘗試基於當前系統的工作負載來動態調整系統。其活動記錄在/var/log/numad.log。
如需啓動服務，運行：
systemctl start numad.service
如需重啓後服務持久，運行：
chkconfig numad on
13 taskset
taskset 工具是由 util-linux 軟件包提供的。它允許管理員檢索和設置正在運行的進程的處理器關聯，或通過
指定的處理器關聯運行進程。
重要taskset 不保證本地內存分配。如果您需要本地內存分配的額外性能收益，紅帽推薦使用 numactl來替代 taskset。
設置正在運行的進程的 CPU 關聯，運行下列命令：
taskset -c processors pid使用處理器的逗號分隔列表或處理器的範圍（例如，1、3、5－7）替換 processors。使用欲重新配置的進程 的進程標識替換 pid 。
用指定的關聯運行進程，運行下列命令：
taskset -c processors -- application用處理器的逗號分隔列表或處理器的範圍替換 processors。使用您欲運行的應用程序的命令、選項和參數替換 application。