程序的不可中斷狀態是系統的一種保護機制，可以保證硬體的互動過程不被意外打斷
所以，短時間的不可中斷狀態是很正常的
當程序長時間都處於不可中斷狀態時，就得當心了
可以使用dstat、pidstat等工具，確認是不是磁碟i/o的問題，進而排查相關的程序和磁碟裝置
除了iowait，軟中斷（softirq）cpu使用率公升高也是最常見的一種效能問題
中斷是系統用來響應硬體裝置請求的一種機制，它會打斷程序的正常排程和執行
然後呼叫核心中的中斷處理程式來響應裝置的請求
舉例1：
比如說你訂了乙份外賣，但是不確定外賣什麼時候送到，也沒有別的方法了解外賣的進度
但是，配送員送外賣是不等人的，到了你這兒沒人取的話，就直接走人了
所以你只能苦苦等著，時不時去門口看看外賣送到沒，而不能幹其他事情
不過呢，如果在訂外賣的時候，你就跟配送員約定好，讓他送到後給你打個**
那你就不用苦苦等待了，就可以去忙別的事情，直到**一響，接**、取外賣就可以了
這裡的「打**」，其實就是乙個中斷
沒接到**的時候，你可以做其他的事情
只有接到了**（也就是發生中斷），才要進行另乙個動作：取外賣
#這個例子可以發現：中斷其實是一種非同步的事件處理機制，可以提高系統的併發處理能力
由於中斷處理程式會打斷其他程序的執行
所以，為了減少對正常程序執行排程的影響，中斷處理程式就需要盡可能快地執行
如果中斷本身要做的事情不多，那麼處理起來也不會有太大問題
但如果中斷要處理的事情很多，中斷服務程式就有可能要執行很長時間
特別是，中斷處理程式在響應中斷時，還會臨時關閉中斷
這就會導致上一次中斷處理完成之前，其他中斷都不能響應，也就是說中斷有可能會丟失
舉例2：
還是以取外賣為例
假如訂了2份外賣，乙份主食和乙份飲料，並且是由2個不同的配送員來配送
這次不用時時等待著，兩份外賣都約定了**取外賣的方式
但是，問題又來了，
當第乙份外賣送到時，配送員給你打了個長長的**，商量發票的處理方式
與此同時，第二個配送員也到了，也想給你打**
但是很明顯，因為**佔線（也就是關閉了中斷響應），
第二個配送員的**是打不通的
所以，第二個配送員很可能試幾次後就走掉了（也就是丟失了一次中斷）
為了解決中斷處理程式執行過長和中斷丟失的問題，linux將中斷處理過程分成了兩個階段，
也就是上半部和下半部：
1.上半部用來快速處理中斷，它在中斷禁止模式下執行，主要處理跟硬體緊密相關的或時間敏感的工作
2.下半部用來延遲處理上半部未完成的工作，通常以核心執行緒的方式執行
比如說前面取外賣的例子2，
上半部就是你接聽**，告訴配送員你已經知道了，其他事兒見面再說，然後**就可以結束通話了
下半部才是取外賣的動作，以及見面後商量發票處理的動作
這樣，第乙個配送員不會占用你太多時間
當第二個配送員過來時，照樣能正常打通你的**
舉例3網絡卡接收資料報的例子
網絡卡接收到資料報後，會通過硬體中斷的方式，通知核心有新的資料到了
這時，核心就應該呼叫中斷處理程式來響應它
這種情況下的上半部和下半部分別負責什麼工作呢？
對上半部來說，既然是快速處理，其實就是要把網絡卡的資料讀到記憶體中
然後更新一下硬體暫存器的狀態（表示資料已經讀好了）
最後再傳送乙個軟中斷訊號，通知下半部做進一步的處理
而下半部被軟中斷訊號喚醒後，需要從記憶體中找到網路資料
再按照網路協議棧，對資料進行逐層解析和處理，直到把它送給應用程式
所以，這兩個階段也可以這樣理解：
1.上半部直接處理硬體請求，也就是我們常說的硬中斷，特點是快速執行
2.下半部則是由核心觸發，也就是我們常說的軟中斷，特點是延遲執行
實際上，上半部會打斷cpu正在執行的任務，然後立即執行中斷處理程式
而下半部以核心執行緒的方式執行，並且每個cpu都對應乙個軟中斷核心執行緒
名字為「ksoftirqd/cpu編號」
比如說，0號cpu對應的軟中斷核心執行緒的名字就是ksoftirqd/0
不過要注意的是，軟中斷不只包括了剛剛所講的硬體裝置中斷處理程式的下半部，一些核心自定義的事件也屬於軟中斷
比如核心排程和rcu鎖（read-copy update的縮寫，rcu是linux核心中最常用的鎖之一）等
proc檔案系統
它是一種核心空間和使用者空間進行通訊的機制，可以用來檢視核心的資料結構，或者用來動態修改核心的配置
/proc/softirqs 提供了軟中斷的運**況
/proc/interrupts 提供了硬中斷的運**況
檢視/proc/softirqs檔案的內容，可以看到各種型別軟中斷在不同cpu上的累積執行次數
[root@local_sa_192-168-1-6 ~]# cat /proc/softirqs
cpu0 cpu1
hi: 3 0
timer: 1028114 1356422
net_tx: 5 2
net_rx: 1136736 1506885
block: 53674 20745
block_iopoll: 0 0
tasklet: 304787 3691
sched: 798684 1147665
hrtimer: 0 0
rcu: 260305 241500
# 在檢視/proc/softirqs檔案內容時，要特別注意以下這兩點
1.要注意軟中斷的型別，也就是這個介面中第一列的內容
從第一列可以看到，軟中斷包括了10個類別，分別對應不同的工作型別
比如net_rx表示網路接收中斷，而net_tx表示網路傳送中斷
2.要注意同一種軟中斷在不同cpu上的分布情況，也就是同一行的內容
正常情況下，同一種中斷在不同cpu上的累積次數應該差不多
比如這個介面中，net_rx在cpu0和cpu1上的中斷次數基本是同乙個數量級，相差不大
tasklet在不同cpu上的分布並不均勻
tasklet是最常用的軟中斷實現機制，每個tasklet只執行一次就會結束
並且只在呼叫它的函式所在的cpu上執行
因此，使用tasklet特別簡便，當然也會存在一些問題
比如說由於只在乙個cpu上執行導致的排程不均衡
再比如因為不能在多個cpu上並行執行帶來了效能限制
軟中斷實際上是以核心執行緒的方式執行的，每個cpu都對應乙個軟中斷核心執行緒
這個軟中斷核心執行緒就叫做ksoftirqd/cpu編號
那要怎麼檢視這些執行緒的執行狀況呢？
# ps命令就可以做到，比如執行下面的指令
[root@local_sa_192-168-1-6 ~]# ps aux|grep softirq
root 6 0.0 0.0 0 0 ? s 11月16 0:00 [ksoftirqd/0]
root 14 0.0 0.0 0 0 ? s 11月16 0:00 [ksoftirqd/1]
# 這些執行緒的名字外面都有中括號，這說明ps無法獲取它們的命令列引數
一般來說，ps的輸出中，名字括在中括號裡的，一般都是核心執行緒
linux中的中斷處理程式分為上半部和下半部
上半部對應硬體中斷，用來快速處理中斷
下半部對應軟中斷，用來非同步處理上半部未完成的工作
linux中的軟中斷包括網路收發、定時、排程、rcu鎖等各種型別
可以通過檢視/proc/softirqs來觀察軟中斷的運**況
大量的網路小包會導致效能問題嗎？
會，大量的小網路包會導致頻繁的硬中斷和軟中斷，消耗cpu的效能
怎麼理解Linux軟中斷？
如果覺得該文章不錯，可以嘗試購買該課程學習。傳送門 中斷是系統用來響應硬體裝置請求的一種機制，它會打斷程序的正常排程和執行，然後呼叫核心中的中斷處理程式來響應裝置的請求。舉個生活中的例子 比如說你訂了乙份外賣，但是不確定外賣什麼時候送到，也沒有別的方法了解外賣的進度，但是，配送員送外賣是不等人的，到...
Linux 怎麼理解Linux軟中斷？
為了解決中斷處理程式執行過長和中斷丟失的問題，linux 將中斷處理過程分成了兩個階段，也就是上半部和下半部 舉個最常見的網絡卡接收資料報的例子，讓你更好地理解。網絡卡接收到資料報後，會通過硬體中斷的方式，通知核心有新的資料到了。這時，核心就應該呼叫中斷處理程式來響應它。你可以自己先想一下，這種情況...
Linux怎麼取消軟鏈結
linux下取消軟連線，做個案例來說明 1.先建立乙個軟連線 1 2 3 4 5 6 7 8 9 10 11 12 13 root rekfan.comtest ls il 總計 0 1491138 rw r r 1 root root 48 07 14 14 17 file1 1491139 rw...