linux吞吐量

❶ linux是什麼意思

linux的意思：

n.【商,計】一種計算搜辯機念宴操作系統

3.Linuxsystemsusuallydo a better job with getting thekeybindings right,.

Linux系統通常對關鍵值綁定有更好的支持，但在一定程度上依賴於您所仔漏銀使用的窗口管理器。

❷ 關於 Linux 網路，你必須知道這些

我們一起學習了文件系統和磁碟 I/O 的工作原理，以及相應的性能分析和優化方法。接下來，我們將進入下一個重要模塊—— Linux 的網路子系統。

由於網路處理的流程最復雜，跟我們前面講到的進程調度、中斷處理、內存管理以及 I/O 等都密不可分，所以，我把網路模塊作為最後一個資源模塊來講解。

同 CPU、內存以及 I/O 一樣，網路也是 Linux 系統最核心的功能。網路是一種把不同計算機或網路設備連接到一起的技術，它本質上是一種進程間通信方式，特別是跨系統的進程間通信，必須要通過網路才能進行。隨著高並發、分布式、雲計算、微服務等技術的普及，網路的性能也變得越來越重要。

說到網路，我想你肯定經常提起七層負載均衡、四層負載均衡，或者三層設備、二層設備等等。那麼，這里說的二層、三層、四層、七層又都是什麼意思呢？

實際上，這些層都來自國際標准化組織制定的開放式系統互聯通信參考模型（Open System Interconnection Reference Model），簡稱為 OSI 網路模型。

但是 OSI 模型還是太復雜了，也沒能提供一個可實現的方法。所以，在 Linux 中，我們實際上使用的是另一個更實用的四層模型，即 TCP/IP 網路模型。

TCP/IP 模型，把網路互聯的框架分為應用層、傳輸層、網路層、網路介面層等四層，其中，

為了幫你更形象理解 TCP/IP 與 OSI 模型的關系，我畫了一張圖，如下所示：

當然了，雖說 Linux 實際按照 TCP/IP 模型，實現了網路協議棧，但在平時的學習交流中，我們習慣上還是用 OSI 七層模型來描述。比如，說到七層和四層負載均衡，對應的分別是 OSI 模型中的應用層和傳輸層（而它們對應到 TCP/IP 模型中，實際上是四層和三層）。

OSI引入了服務、介面、協議、分層的概念，TCP/IP借鑒了OSI的這些概念建立TCP/IP模型。

OSI先有模型，後有協議，先有標准，後進行實踐；而TCP/IP則相反，先有協議和應用再提出了模型，且是參照的OSI模型。

OSI是一種理論下的模型，而TCP/IP已被廣泛使用，成為網路互聯事實上的標准。

有了 TCP/IP 模型後，在進行網路傳輸時，數據包就會按照協議棧，對上一層發來的數據進行逐層處理；然後封裝上該層的協議頭，再發送給下一層。

當然，網路包在每一層的處理邏輯，都取決於各層採用的網路協議。比如在應用層，一個提供 REST API 的應用，可以使用 HTTP 協議，把它需要傳輸的 JSON 數據封裝到 HTTP 協議中，然後向下傳遞給 TCP 層。

而封裝做的事情就很簡單了，只是在原來的負載前後，增加固定格式的元數據，原始的負載數據並不會被修改。

比如，以通過 TCP 協議通信的網路包為例，通過下面這張圖，我們可以看到，應用程序數據在每個層的封裝格式。

這些新增的頭部和尾部，增加了網路包的大小，但我們都知道，物理鏈路中並不能傳輸任意大小的數據包。網路介面配置的最大傳輸單元（MTU），就規定了最大的 IP 包大小。在我們最常用的乙太網中，MTU 默認值是 1500（這也是 Linux 的默認值）。

一旦網路包超過 MTU 的大小，就會在網路層分片，以保證分片後的 IP 包不大於 MTU 值。顯然，MTU 越大，需要的分包也就越少，自然，網路吞吐能力就越好。

理解了 TCP/IP 網路模型和網路包的封裝原理後，你很容易能想到，Linux 內核中的網路棧，其實也類似於 TCP/IP 的四層結構。如下圖所示，就是 Linux 通用 IP 網路棧的示意圖：

我們從上到下來看這個網路棧，你可以發現，

這里我簡單說一下網卡。網卡是發送和接收網路包的基本設備。在系統啟動過程中，網卡通過內核中的網卡驅動程序注冊到系統中。而在網路收發過程中，內核通過中斷跟網卡進行交互。

再結合前面提到的 Linux 網路棧，可以看出，網路包的處理非常復雜。所以，網卡硬中斷只處理最核心的網卡數據讀取或發送，而協議棧中的大部分邏輯，都會放到軟中斷中處理。

我們先來看網路包的接收流程。

當一個網路幀到達網卡後，網卡會通過 DMA 方式，把這個網路包放到收包隊列中；然後通過硬中斷，告訴中斷處理程序已經收到了網路包。

接著，網卡中斷處理程序會為網路幀分配內核數據結構（sk_buff），並將其拷貝到 sk_buff 緩沖區中；然後再通過軟中斷，通知內核收到了新的網路幀。

接下來，內核協議棧從緩沖區中取出網路幀，並通過網路協議棧，從下到上逐層處理這個網路幀。比如，

最後，應用程序就可以使用 Socket 介面，讀取到新接收到的數據了。

為了更清晰表示這個流程，我畫了一張圖，這張圖的左半部分表示接收流程，而圖中的粉色箭頭則表示網路包的處理路徑。

了解網路包的接收流程後，就很容易理解網路包的發送流程。網路包的發送流程就是上圖的右半部分，很容易發現，網路包的發送方向，正好跟接收方向相反。

首先，應用程序調用 Socket API（比如 sendmsg）發送網路包。

由於這是一個系統調用，所以會陷入到內核態的套接字層中。套接字層會把數據包放到 Socket 發送緩沖區中。

接下來，網路協議棧從 Socket 發送緩沖區中，取出數據包；再按照 TCP/IP 棧，從上到下逐層處理。比如，傳輸層和網路層，分別為其增加 TCP 頭和 IP 頭，執行路由查找確認下一跳的 IP，並按照 MTU 大小進行分片。

分片後的網路包，再送到網路介面層，進行物理地址定址，以找到下一跳的 MAC 地址。然後添加幀頭和幀尾，放到發包隊列中。這一切完成後，會有軟中斷通知驅動程序：發包隊列中有新的網路幀需要發送。

最後，驅動程序通過 DMA ，從發包隊列中讀出網路幀，並通過物理網卡把它發送出去。

多台伺服器通過網卡、交換機、路由器等網路設備連接到一起，構成了相互連接的網路。由於網路設備的異構性和網路協議的復雜性，國際標准化組織定義了一個七層的 OSI 網路模型，但是這個模型過於復雜，實際工作中的事實標准，是更為實用的 TCP/IP 模型。

TCP/IP 模型，把網路互聯的框架，分為應用層、傳輸層、網路層、網路介面層等四層，這也是 Linux 網路棧最核心的構成部分。

我結合網路上查閱的資料和文章中的內容，總結了下網卡收發報文的過程，不知道是否正確：

當發送數據包時，與上述相反。鏈路層將數據包封裝完畢後，放入網卡的DMA緩沖區，並調用系統硬中斷，通知網卡從緩沖區讀取並發送數據。

了解 Linux 網路的基本原理和收發流程後，你肯定迫不及待想知道，如何去觀察網路的性能情況。具體而言，哪些指標可以用來衡量 Linux 的網路性能呢？

實際上，我們通常用帶寬、吞吐量、延時、PPS（Packet Per Second）等指標衡量網路的性能。

除了這些指標，網路的可用性（網路能否正常通信）、並發連接數（TCP 連接數量）、丟包率（丟包百分比）、重傳率（重新傳輸的網路包比例）等也是常用的性能指標。

分析網路問題的第一步，通常是查看網路介面的配置和狀態。你可以使用 ifconfig 或者 ip 命令，來查看網路的配置。我個人更推薦使用 ip 工具，因為它提供了更豐富的功能和更易用的介面。

以網路介面 eth0 為例，你可以運行下面的兩個命令，查看它的配置和狀態：

你可以看到，ifconfig 和 ip 命令輸出的指標基本相同，只是顯示格式略微不同。比如，它們都包括了網路介面的狀態標志、MTU 大小、IP、子網、MAC 地址以及網路包收發的統計信息。

第一，網路介面的狀態標志。ifconfig 輸出中的 RUNNING ，或 ip 輸出中的 LOWER_UP ，都表示物理網路是連通的，即網卡已經連接到了交換機或者路由器中。如果你看不到它們，通常表示網線被拔掉了。

第二，MTU 的大小。MTU 默認大小是 1500，根據網路架構的不同（比如是否使用了 VXLAN 等疊加網路），你可能需要調大或者調小 MTU 的數值。

第三，網路介面的 IP 地址、子網以及 MAC 地址。這些都是保障網路功能正常工作所必需的，你需要確保配置正確。

第四，網路收發的位元組數、包數、錯誤數以及丟包情況，特別是 TX 和 RX 部分的 errors、dropped、overruns、carrier 以及 collisions 等指標不為 0 時，通常表示出現了網路 I/O 問題。其中：

ifconfig 和 ip 只顯示了網路介面收發數據包的統計信息，但在實際的性能問題中，網路協議棧中的統計信息，我們也必須關注。你可以用 netstat 或者 ss ，來查看套接字、網路棧、網路介面以及路由表的信息。

我個人更推薦，使用 ss 來查詢網路的連接信息，因為它比 netstat 提供了更好的性能（速度更快）。

比如，你可以執行下面的命令，查詢套接字信息：

netstat 和 ss 的輸出也是類似的，都展示了套接字的狀態、接收隊列、發送隊列、本地地址、遠端地址、進程 PID 和進程名稱等。

其中，接收隊列（Recv-Q）和發送隊列（Send-Q）需要你特別關注，它們通常應該是 0。當你發現它們不是 0 時，說明有網路包的堆積發生。當然還要注意，在不同套接字狀態下，它們的含義不同。

當套接字處於連接狀態（Established）時，

當套接字處於監聽狀態（Listening）時，

所謂全連接，是指伺服器收到了客戶端的 ACK，完成了 TCP 三次握手，然後就會把這個連接挪到全連接隊列中。這些全連接中的套接字，還需要被 accept() 系統調用取走，伺服器才可以開始真正處理客戶端的請求。

與全連接隊列相對應的，還有一個半連接隊列。所謂半連接是指還沒有完成 TCP 三次握手的連接，連接只進行了一半。伺服器收到了客戶端的 SYN 包後，就會把這個連接放到半連接隊列中，然後再向客戶端發送 SYN+ACK 包。

類似的，使用 netstat 或 ss ，也可以查看協議棧的信息：

這些協議棧的統計信息都很直觀。ss 只顯示已經連接、關閉、孤兒套接字等簡要統計，而 netstat 則提供的是更詳細的網路協議棧信息。

比如，上面 netstat 的輸出示例，就展示了 TCP 協議的主動連接、被動連接、失敗重試、發送和接收的分段數量等各種信息。

接下來，我們再來看看，如何查看系統當前的網路吞吐量和 PPS。在這里，我推薦使用我們的老朋友 sar，在前面的 CPU、內存和 I/O 模塊中，我們已經多次用到它。

給 sar 增加 -n 參數就可以查看網路的統計信息，比如網路介面（DEV）、網路介面錯誤（EDEV）、TCP、UDP、ICMP 等等。執行下面的命令，你就可以得到網路介面統計信息：

這兒輸出的指標比較多，我來簡單解釋下它們的含義。

其中，Bandwidth 可以用 ethtool 來查詢，它的單位通常是 Gb/s 或者 Mb/s，不過注意這里小寫字母 b ，表示比特而不是位元組。我們通常提到的千兆網卡、萬兆網卡等，單位也都是比特。如下你可以看到，我的 eth0 網卡就是一個千兆網卡：

其中，Bandwidth 可以用 ethtool 來查詢，它的單位通常是 Gb/s 或者 Mb/s，不過注意這里小寫字母 b ，表示比特而不是位元組。我們通常提到的千兆網卡、萬兆網卡等，單位也都是比特。如下你可以看到，我的 eth0 網卡就是一個千兆網卡：

我們通常使用帶寬、吞吐量、延時等指標，來衡量網路的性能；相應的，你可以用 ifconfig、netstat、ss、sar、ping 等工具，來查看這些網路的性能指標。

小狗同學問到： 老師，您好 ss —lntp 這個 當session處於listening中 rec-q 確定是 syn的backlog嗎？
A: Recv-Q為全連接隊列當前使用了多少。 中文資料里這個問題講得最明白的文章： https://mp.weixin.qq.com/s/yH3PzGEFopbpA-jw4MythQ

看了源碼發現，這個地方講的有問題.關於ss輸出中listen狀態套接字的Recv-Q表示全連接隊列當前使用了多少,也就是全連接隊列的當前長度,而Send-Q表示全連接隊列的最大長度

❸ linux查看系統網卡信息命令

查看網路信息命令 ifconfig
或者ip add show
希望可以幫助你，請採納，謝謝

❹ Linux 磁碟IO

磁碟結構與數據存儲方式, 數據是如何存儲的，又通過怎樣的方式被訪問？

機械硬碟主要由磁碟碟片、磁頭、主軸與傳動軸等組成；數據就存放在磁碟碟片中

現代硬碟尋道都是採用CHS( Cylinder Head Sector )的方式，硬碟讀取數據時，讀寫磁頭沿徑向移動，移到要讀取的扇區所在磁軌的上方，這段時間稱為 尋道時間(seek time) 。 因讀寫磁頭的起始位置與目標位置之間的距離不同，尋道時間也不同 。磁頭到達指定磁軌後，然後通過碟片的旋轉，使得要讀取的扇區轉到讀寫磁頭的下方，這段時間稱為 旋轉延遲時間(rotational latencytime) 。然後再讀寫數據，讀寫數據也需要時間，這段時間稱為 傳輸時間(transfer time) 。

固態硬碟主要由主控晶元、快閃記憶體顆粒與緩存組成；數據就存放在快閃記憶體晶元中
通過主控晶元進行定址， 因為是電信號方式， 沒有任何物理結構， 所以定址速度非常快且與數據存儲位置無關

如何查看系統IO狀態

查看磁碟空間

調用 open , fwrite 時到底發生了什麼?

在一個IO過程中，以下5個API/系統調用是必不可少的
Create 函數用來打開一個文件，如果該文件不存在，那麼需要在磁碟上創建該文件
Open 函數用於打開一個指定的文件。如果在 Open 函數中指定 O_CREATE 標記，那麼 Open 函數同樣可以實現 Create 函數的功能
Clos e函數用於釋放文件句柄
Write 和 Read 函數用於實現文件的讀寫過程

O_SYNC (先寫緩存, 但是需要實際落盤之後才返回, 如果接下來有讀請求, 可以從內存讀 ), write-through
O_DSYNC (D=data, 類似O_SYNC, 但是只同步數據, 不同步元數據)
O_DIRECT (直接寫盤, 不經過緩存)
O_ASYNC (非同步IO, 使用信號機制實現, 不推薦, 直接用aio_xxx)
O_NOATIME (讀取的時候不更新文件 atime(access time))

sync() 全局緩存寫回磁碟
fsync() 特定fd的sync()
fdatasync() 只刷數據, 不同步元數據

mount noatime(全局不記錄atime), re方式(只讀), sync(同步方式)

一個IO的傳奇一生 這里有一篇非常好的資料，講述了整個IO過程；
下面簡單記錄下自己的理解的一次常見的Linux IO過程， 想了解更詳細及相關源碼，非常推薦閱讀上面的原文

Linux IO體系結構

[站外圖片上傳中...(image-38a7b-1644137945193)]

Superblock 超級描述了整個文件系統的信息。為了保證可靠性，可以在每個塊組中對superblock進行備份。為了避免superblock冗餘過多，可以採用稀疏存儲的方式，即在若干個塊組中對superblock進行保存，而不需要在所有的塊組中都進行備份
GDT 組描述符表 組描述符表對整個組內的數據布局進行了描述。例如，數據塊點陣圖的起始地址是多少？inode點陣圖的起始地址是多少？inode表的起始地址是多少？塊組中還有多少空閑塊資源等。組描述符表在superblock的後面
數據塊點陣圖 數據塊點陣圖描述了塊組內數據塊的使用情況。如果該數據塊已經被某個文件使用，那麼點陣圖中的對應位會被置1，否則該位為0
Inode點陣圖 Inode點陣圖描述了塊組內inode資源使用情況。如果一個inode資源已經使用，那麼對應位會被置1
Inode表 （即inode資源）和數據塊。這兩塊占據了塊組內的絕大部分空間，特別是數據塊資源

一個文件是由inode進行描述的。一個文件佔用的數據塊block是通過inode管理起來的 。在inode結構中保存了直接塊指針、一級間接塊指針、二級間接塊指針和三級間接塊指針。對於一個小文件，直接可以採用直接塊指針實現對文件塊的訪問；對於一個大文件，需要採用間接塊指針實現對文件塊的訪問

最簡單的調度器。它本質上就是一個鏈表實現的 fifo 隊列，並對請求進行簡單的 合並 處理。
調度器本身並沒有提供任何可以配置的參數

讀寫請求被分成了兩個隊列， 一個用訪問地址作為索引，一個用進入時間作為索引，並且採用兩種方式將這些request管理起來；
在請求處理的過程中，deadline演算法會優先處理那些訪問地址臨近的請求，這樣可以最大程度的減少磁碟抖動的可能性。
只有在有些request即將被餓死的時候，或者沒有辦法進行磁碟順序化操作的時候，deadline才會放棄地址優先策略，轉而處理那些即將被餓死的request

deadline演算法可調整參數
read_expire : 讀請求的超時時間設置(ms)。當一個讀請求入隊deadline的時候，其過期時間將被設置為當前時間＋read_expire，並放倒fifo_list中進行排序
write_expire :寫請求的超時時間設置(ms)
fifo_batch :在順序（sort_list）請求進行處理的時候，deadline將以batch為單位進行處理。每一個batch處理的請求個數為這個參數所限制的個數。在一個batch處理的過程中，不會產生是否超時的檢查，也就不會產生額外的磁碟尋道時間。這個參數可以用來平衡順序處理和飢餓時間的矛盾，當飢餓時間需要盡可能的符合預期的時候，我們可以調小這個值，以便盡可能多的檢查是否有飢餓產生並及時處理。增大這個值當然也會增大吞吐量，但是會導致處理飢餓請求的延時變長
writes_starved :這個值是在上述deadline出隊處理第一步時做檢查用的。用來判斷當讀隊列不為空時，寫隊列的飢餓程度是否足夠高，以時deadline放棄讀請求的處理而處理寫請求。當檢查存在有寫請求的時候，deadline並不會立即對寫請求進行處理，而是給相關數據結構中的starved進行累計，如果這是第一次檢查到有寫請求進行處理，那麼這個計數就為1。如果此時writes_starved值為2，則我們認為此時飢餓程度還不足夠高，所以繼續處理讀請求。只有當starved >= writes_starved的時候，deadline才回去處理寫請求。可以認為這個值是用來平衡deadline對讀寫請求處理優先順序狀態的，這個值越大，則寫請求越被滯後處理，越小，寫請求就越可以獲得趨近於讀請求的優先順序
front_merges :當一個新請求進入隊列的時候，如果其請求的扇區距離當前扇區很近，那麼它就是可以被合並處理的。而這個合並可能有兩種情況，一個是向當前位置後合並，另一種是向前合並。在某些場景下，向前合並是不必要的，那麼我們就可以通過這個參數關閉向前合並。默認deadline支持向前合並，設置為0關閉

在調度一個request時，首先需要選擇一個一個合適的cfq_group。Cfq調度器會為每個cfq_group分配一個時間片，當這個時間片耗盡之後，會選擇下一個cfq_group。每個cfq_group都會分配一個vdisktime，並且通過該值採用紅黑樹對cfq_group進行排序。在調度的過程中，每次都會選擇一個vdisktime最小的cfq_group進行處理。
一個cfq_group管理了7棵service tree，每棵service tree管理了需要調度處理的對象cfq_queue。因此，一旦cfq_group被選定之後，需要選擇一棵service tree進行處理。這7棵service tree被分成了三大類，分別為RT、BE和IDLE。這三大類service tree的調度是按照優先順序展開的

通過優先順序可以很容易的選定一類Service tree。當一類service tree被選定之後，採用service time的方式選定一個合適的cfq_queue。每個Service tree是一棵紅黑樹，這些紅黑樹是按照service time進行檢索的，每個cfq_queue都會維護自己的service time。分析到這里，我們知道，cfq演算法通過每個cfq_group的vdisktime值來選定一個cfq_group進行服務，在處理cfq_group的過程通過優先順序選擇一個最需要服務的service tree。通過該Service tree得到最需要服務的cfq_queue。該過程在 cfq_select_queue 函數中實現

一個cfq_queue被選定之後，後面的過程和deadline演算法有點類似。在選擇request的時候需要考慮每個request的延遲等待時間，選擇那種等待時間最長的request進行處理。但是，考慮到磁碟抖動的問題，cfq在處理的時候也會進行順序批量處理，即將那些在磁碟上連續的request批量處理掉

cfq調度演算法的參數
back_seek_max :磁頭可以向後定址的最大范圍，默認值為16M
back_seek_penalty :向後定址的懲罰系數。這個值是跟向前定址進行比較的

fifo_expire_async :設置非同步請求的超時時間。同步請求和非同步請求是區分不同隊列處理的，cfq在調度的時候一般情況都會優先處理同步請求，之後再處理非同步請求，除非非同步請求符合上述合並處理的條件限制范圍內。當本進程的隊列被調度時，cfq會優先檢查是否有非同步請求超時，就是超過fifo_expire_async參數的限制。如果有，則優先發送一個超時的請求，其餘請求仍然按照優先順序以及扇區編號大小來處理
fifo_expire_sync :這個參數跟上面的類似，區別是用來設置同步請求的超時時間
slice_idle :參數設置了一個等待時間。這讓cfq在切換cfq_queue或service tree的時候等待一段時間，目的是提高機械硬碟的吞吐量。一般情況下，來自同一個cfq_queue或者service tree的IO請求的定址局部性更好，所以這樣可以減少磁碟的定址次數。這個值在機械硬碟上默認為非零。當然在固態硬碟或者硬RAID設備上設置這個值為非零會降低存儲的效率，因為固態硬碟沒有磁頭定址這個概念，所以在這樣的設備上應該設置為0，關閉此功能
group_idle :這個參數也跟上一個參數類似，區別是當cfq要切換cfq_group的時候會等待一段時間。在cgroup的場景下，如果我們沿用slice_idle的方式，那麼空轉等待可能會在cgroup組內每個進程的cfq_queue切換時發生。這樣會如果這個進程一直有請求要處理的話，那麼直到這個cgroup的配額被耗盡，同組中的其它進程也可能無法被調度到。這樣會導致同組中的其它進程餓死而產生IO性能瓶頸。在這種情況下，我們可以將slice_idle ＝ 0而group_idle ＝ 8。這樣空轉等待就是以cgroup為單位進行的，而不是以cfq_queue的進程為單位進行，以防止上述問題產生
low_latency :這個是用來開啟或關閉cfq的低延時（low latency）模式的開關。當這個開關打開時，cfq將會根據target_latency的參數設置來對每一個進程的分片時間（slice time）進行重新計算。這將有利於對吞吐量的公平（默認是對時間片分配的公平）。關閉這個參數（設置為0）將忽略target_latency的值。這將使系統中的進程完全按照時間片方式進行IO資源分配。這個開關默認是打開的

target_latency :當low_latency的值為開啟狀態時，cfq將根據這個值重新計算每個進程分配的IO時間片長度
quantum :這個參數用來設置每次從cfq_queue中處理多少個IO請求。在一個隊列處理事件周期中，超過這個數字的IO請求將不會被處理。這個參數只對同步的請求有效
slice_sync :當一個cfq_queue隊列被調度處理時，它可以被分配的處理總時間是通過這個值來作為一個計算參數指定的。公式為： time_slice = slice_sync + (slice_sync/5 * (4 - prio)) 這個參數對同步請求有效
slice_async :這個值跟上一個類似，區別是對非同步請求有效
slice_async_rq :這個參數用來限制在一個slice的時間范圍內，一個隊列最多可以處理的非同步請求個數。請求被處理的最大個數還跟相關進程被設置的io優先順序有關

通常在Linux上使用的IO介面是同步方式的，進程調用 write / read 之後會阻塞陷入到內核態，直到本次IO過程完成之後，才能繼續執行，下面介紹的非同步IO則沒有這種限制，但是當前Linux非同步IO尚未成熟

目前Linux aio還處於較不成熟的階段，只能在 O_DIRECT 方式下才能使用(glibc_aio)，也就是無法使用默認的Page Cache機制

正常情況下，使用aio族介面的簡要方式如下：

io_uring 是 2019 年 5 月發布的 Linux 5.1 加入的一個重大特性 —— Linux 下的全新的非同步 I/O 支持，希望能徹底解決長期以來 Linux AIO 的各種不足
io_uring 實現非同步 I/O 的方式其實是一個生產者-消費者模型:

邏輯卷管理
RAID0
RAID1
RAID5（糾錯）
條帶化

Linux系統性能調整：IO過程
Linux的IO調度
一個IO的傳奇一生
理解inode
Linux 文件系統是怎麼工作的？
Linux中Buffer cache性能問題一探究竟
Asynchronous I/O and event notification on linux
AIO 的新歸宿：io_uring
Linux 文件 I/O 進化史（四）：io_uring —— 全新的非同步 I/O

❺ 一般優化linux的內核，需要優化什麼參數

作為高性能WEB伺服器，只調整Nginx本身的參數是不行的，因為Nginx服務依賴於高性能的操作系統。

以下為常見的幾個Linux內核參數優化方法。

• net.ipv4.tcp_max_tw_buckets

對於tcp連接，服務端和客戶端通信完後狀態變為timewait，假如某台伺服器非常忙，連接數特別多的話，那麼這個timewait數量就會越來越大。
畢竟它也是會佔用一定的資源，所以應該有一個最大值，當超過這個值，系統就會刪除最早的連接，這樣始終保持在一個數量級。
這個數值就是由net.ipv4.tcp_max_tw_buckets這個參數來決定的。
CentOS7系統，你可以使用sysctl -a |grep tw_buckets來查看它的值，默認為32768，
你可以適當把它調低，比如調整到8000，畢竟這個狀態的連接太多也是會消耗資源的。
但你不要把它調到幾十、幾百這樣，因為這種狀態的tcp連接也是有用的，
如果同樣的客戶端再次和服務端通信，就不用再次建立新的連接了，用這個舊的通道，省時省力。

• net.ipv4.tcp_tw_recycle = 1

該參數的作用是快速回收timewait狀態的連接。上面雖然提到系統會自動刪除掉timewait狀態的連接，但如果把這樣的連接重新利用起來豈不是更好。
所以該參數設置為1就可以讓timewait狀態的連接快速回收，它需要和下面的參數配合一起使用。

• net.ipv4.tcp_tw_reuse = 1

該參數設置為1，將timewait狀態的連接重新用於新的TCP連接，要結合上面的參數一起使用。

• net.ipv4.tcp_syncookies = 1

tcp三次握手中，客戶端向服務端發起syn請求，服務端收到後，也會向客戶端發起syn請求同時連帶ack確認，
假如客戶端發送請求後直接斷開和服務端的連接，不接收服務端發起的這個請求，服務端會重試多次，
這個重試的過程會持續一段時間（通常高於30s），當這種狀態的連接數量非常大時，伺服器會消耗很大的資源，從而造成癱瘓，
正常的連接進不來，這種惡意的半連接行為其實叫做syn flood攻擊。
設置為1，是開啟SYN Cookies，開啟後可以避免發生上述的syn flood攻擊。
開啟該參數後，服務端接收客戶端的ack後，再向客戶端發送ack+syn之前會要求client在短時間內回應一個序號，
如果客戶端不能提供序號或者提供的序號不對則認為該客戶端不合法，於是不會發ack+syn給客戶端，更涉及不到重試。

• net.ipv4.tcp_max_syn_backlog

該參數定義系統能接受的最大半連接狀態的tcp連接數。客戶端向服務端發送了syn包，服務端收到後，會記錄一下，
該參數決定最多能記錄幾個這樣的連接。在CentOS7，默認是256，當有syn flood攻擊時，這個數值太小則很容易導致伺服器癱瘓，
實際上此時伺服器並沒有消耗太多資源（cpu、內存等），所以可以適當調大它，比如調整到30000。

• net.ipv4.tcp_syn_retries

該參數適用於客戶端，它定義發起syn的最大重試次數，默認為6，建議改為2。

• net.ipv4.tcp_synack_retries

該參數適用於服務端，它定義發起syn+ack的最大重試次數，默認為5，建議改為2，可以適當預防syn flood攻擊。

• net.ipv4.ip_local_port_range

該參數定義埠范圍，系統默認保留埠為1024及以下，以上部分為自定義埠。這個參數適用於客戶端，
當客戶端和服務端建立連接時，比如說訪問服務端的80埠，客戶端隨機開啟了一個埠和服務端發起連接，
這個參數定義隨機埠的范圍。默認為32768 61000，建議調整為1025 61000。

• net.ipv4.tcp_fin_timeout

tcp連接的狀態中，客戶端上有一個是FIN-WAIT-2狀態，它是狀態變遷為timewait前一個狀態。
該參數定義不屬於任何進程的該連接狀態的超時時間，默認值為60，建議調整為6。

• net.ipv4.tcp_keepalive_time

tcp連接狀態里，有一個是established狀態，只有在這個狀態下，客戶端和服務端才能通信。正常情況下，當通信完畢，
客戶端或服務端會告訴對方要關閉連接，此時狀態就會變為timewait，如果客戶端沒有告訴服務端，
並且服務端也沒有告訴客戶端關閉的話（例如，客戶端那邊斷網了），此時需要該參數來判定。
比如客戶端已經斷網了，但服務端上本次連接的狀態依然是established，服務端為了確認客戶端是否斷網，
就需要每隔一段時間去發一個探測包去確認一下看看對方是否在線。這個時間就由該參數決定。它的默認值為7200秒，建議設置為30秒。

• net.ipv4.tcp_keepalive_intvl

該參數和上面的參數是一起的，服務端在規定時間內發起了探測，查看客戶端是否在線，如果客戶端並沒有確認，
此時服務端還不能認定為對方不在線，而是要嘗試多次。該參數定義重新發送探測的時間，即第一次發現對方有問題後，過多久再次發起探測。
默認值為75秒，可以改為3秒。

• net.ipv4.tcp_keepalive_probes

第10和第11個參數規定了何時發起探測和探測失敗後再過多久再發起探測，但並沒有定義一共探測幾次才算結束。
該參數定義發起探測的包的數量。默認為9，建議設置2。
設置和範例
在Linux下調整內核參數，可以直接編輯配置文件/etc/sysctl.conf，然後執行sysctl -p命令生效