linux軟中斷查看

❶ linux下怎麼查看cpu運行狀態

輸入命令top-n1|grepCpu

us 用戶空間佔用CPU的百分比。

sy 內核空間佔用CPU的百分比。

ni 改變過優先順序的進程佔用CPU的百分比

id 空閑CPU百分比

wa IO等待佔用CPU的百分比

hi 硬中斷（HardwareIRQ）佔用CPU的百分比

si 軟中斷（SoftwareInterrupts）佔用CPU的百分比

❷ linux系統的軟中斷的中斷事件有哪些

軟中斷就是信號中斷，能發送信號的事件就能發送中斷，比如鍵盤中斷SIGINT，SIGTSTP，SIGSTOP, 時鍾中斷SIGALRM,浮點中斷等等

❸ Manjaro Linux如何查看C P U佔用了

cat /proc/cpuinfo |grep cores |wc -l
lscpu
查看cpu使用率：top
第三行：CPU信息

0.0%us【user space】— 用戶空間佔用CPU的百分比。

0.3%sy【sysctl】— 內核空間佔用CPU的百分比。

0.0%ni【】— 改變過優先順序的進程佔用CPU的百分比

99.7%id【idolt】— 空閑CPU百分比

0.0%wa【wait】— IO等待佔用CPU的百分比

0.0%hi【Hardware IRQ】— 硬中斷佔用CPU的百分比

0.0%si【Software Interrupts】— 軟中斷佔用CPU的百分比

❹ 系統的軟中斷CPU使用率升高，我該怎麼辦

[TOC]
上一期我給你講了軟中斷的基本原理，我們先來簡單復習下。

中斷是一種非同步的事件處理機制，用來提高系統的並發處理能力。中斷事件發生，會觸發執行中斷處理程序，而中斷處理程序被分為上半部和下半部這兩個部分。

Linux 中的軟中斷包括網路收發、定時、調度、RCU 鎖等各種類型，我們可以查看 proc 文件系統中的 /proc/softirqs ，觀察軟中斷的運行情況。

在 Linux 中，每個 CPU 都對應一個軟中斷內核線程，名字是 ksoftirqd/CPU 編號。當軟中斷事件的頻率過高時，內核線程也會因為 CPU 使用率過高而導致軟中斷處理不及時，進而引發網路收發延遲、調度緩慢等性能問題。

軟中斷 CPU 使用率過高也是一種最常見的性能問題。今天，我就用最常見的反向代理伺服器 Nginx 的案例，教你學會分析這種情況。

接下來的案例基於 Ubuntu 18.04，也同樣適用於其他的 Linux 系統。我使用的案例環境是這樣的：

這里我又用到了三個新工具，sar、 hping3 和 tcpmp，先簡單介紹一下：

本次案例用到兩台虛擬機，我畫了一張圖來表示它們的關系。

你可以看到，其中一台虛擬機運行 Nginx ，用來模擬待分析的 Web 伺服器；而另一台當作 Web 伺服器的客戶端，用來給 Nginx 增加壓力請求。使用兩台虛擬機的目的，是為了相互隔離，避免「交叉感染」。

接下來，我們打開兩個終端，分別 SSH 登錄到兩台機器上，並安裝上面提到的這些工具。

同以前的案例一樣，下面的所有命令都默認以 root 用戶運行，如果你是用普通用戶身份登陸系統，請運行 sudo su root 命令切換到 root 用戶。

安裝完成後，我們先在第一個終端，執行下面的命令運行案例，也就是一個最基本的 Nginx 應用：

然後，在第二個終端，使用 curl 訪問 Nginx 監聽的埠，確認 Nginx 正常啟動。假設 192.168.58.99 是 Nginx 所在虛擬機的 IP 地址，運行 curl 命令後你應該會看到下面這個輸出界面：

接著，還是在第二個終端，我們運行 hping3 命令，來模擬 Nginx 的客戶端請求：

現在我們再回到第一個終端，你應該發現了異常。是不是感覺系統響應明顯變慢了，即便只是在終端中敲幾個回車，都得很久才能得到響應？這個時候應該怎麼辦呢？

雖然在運行 hping3 命令時，我就已經告訴你，這是一個 SYN FLOOD 攻擊，你肯定也會想到從網路方面入手，來分析這個問題。不過，在實際的生產環境中，沒人直接告訴你原因。

所以，我希望你把 hping3 模擬 SYN FLOOD 這個操作暫時忘掉，然後重新從觀察到的問題開始，分析系統的資源使用情況，逐步找出問題的根源。

那麼，該從什麼地方入手呢？剛才我們發現，簡單的 SHELL 命令都明顯變慢了，先看看系統的整體資源使用情況應該是個不錯的注意，比如執行下 top 看看是不是出現了 CPU 的瓶頸。我們在第一個終端運行 top 命令，看一下系統整體的資源使用情況。

這里你有沒有發現異常的現象？我們從第一行開始，逐個看一下：

那為什麼系統的響應變慢了呢？既然每個指標的數值都不大，那我們就再來看看，這些指標對應的更具體的含義。畢竟，哪怕是同一個指標，用在系統的不同部位和場景上，都有可能對應著不同的性能問題。

仔細看 top 的輸出，兩個 CPU 的使用率雖然分別只有 3.3% 和 4.4%，但都用在了軟中斷上；而從進程列表上也可以看到，CPU 使用率最高的也是軟中斷進程 ksoftirqd。看起來，軟中斷有點可疑了。

根據上一期的內容，既然軟中斷可能有問題，那你先要知道，究竟是哪類軟中斷的問題。停下來想想，上一節我們用了什麼方法，來判斷軟中斷類型呢？沒錯，還是 proc 文件系統。觀察 /proc/softirqs 文件的內容，你就能知道各種軟中斷類型的次數。

不過，這里的各類軟中斷次數，又是什麼時間段里的次數呢？它是系統運行以來的累積中斷次數。所以我們直接查看文件內容，得到的只是累積中斷次數，對這里的問題並沒有直接參考意義。因為，這些中斷次數的變化速率才是我們需要關注的。

那什麼工具可以觀察命令輸出的變化情況呢？我想你應該想起來了，在前面案例中用過的 watch 命令，就可以定期運行一個命令來查看輸出；如果再加上 -d 參數，還可以高亮出變化的部分，從高亮部分我們就可以直觀看出，哪些內容變化得更快。

比如，還是在第一個終端，我們運行下面的命令：

通過 /proc/softirqs 文件內容的變化情況，你可以發現， TIMER（定時中斷）、NET_RX（網路接收）、SCHED（內核調度）、RCU（RCU 鎖）等這幾個軟中斷都在不停變化。

其中，NET_RX，也就是網路數據包接收軟中斷的變化速率最快。而其他幾種類型的軟中斷，是保證 Linux 調度、時鍾和臨界區保護這些正常工作所必需的，所以它們有一定的變化倒是正常的。

那麼接下來，我們就從網路接收的軟中斷著手，繼續分析。既然是網路接收的軟中斷，第一步應該就是觀察系統的網路接收情況。這里你可能想起了很多網路工具，不過，我推薦今天的主人公工具 sar 。

sar 可以用來查看系統的網路收發情況，還有一個好處是，不僅可以觀察網路收發的吞吐量（BPS，每秒收發的位元組數），還可以觀察網路收發的 PPS，即每秒收發的網路幀數。

我們在第一個終端中運行 sar 命令，並添加 -n DEV 參數顯示網路收發的報告：

對於 sar 的輸出界面，我先來簡單介紹一下，從左往右依次是：

我們具體來看輸出的內容，你可以發現：

從這些數據，你有沒有發現什麼異常的地方？

既然懷疑是網路接收中斷的問題，我們還是重點來看 eth0 ：接收的 PPS 比較大，達到 12607，而接收的 BPS 卻很小，只有 664 KB。直觀來看網路幀應該都是比較小的，我們稍微計算一下，664*1024/12607 = 54 位元組，說明平均每個網路幀只有 54 位元組，這顯然是很小的網路幀，也就是我們通常所說的小包問題。

那麼，有沒有辦法知道這是一個什麼樣的網路幀，以及從哪裡發過來的呢？

使用 tcpmp 抓取 eth0 上的包就可以了。我們事先已經知道， Nginx 監聽在 80 埠，它所提供的 HTTP 服務是基於 TCP 協議的，所以我們可以指定 TCP 協議和 80 埠精確抓包。

接下來，我們在第一個終端中運行 tcpmp 命令，通過 -i eth0 選項指定網卡 eth0，並通過 tcp port 80 選項指定 TCP 協議的 80 埠：

從 tcpmp 的輸出中，你可以發現

再加上前面用 sar 發現的， PPS 超過 12000 的現象，現在我們可以確認，這就是從 192.168.0.2 這個地址發送過來的 SYN FLOOD 攻擊。

到這里，我們已經做了全套的性能診斷和分析。從系統的軟中斷使用率高這個現象出發，通過觀察 /proc/softirqs 文件的變化情況，判斷出軟中斷類型是網路接收中斷；再通過 sar 和 tcpmp ，確認這是一個 SYN FLOOD 問題。

SYN FLOOD 問題最簡單的解決方法，就是從交換機或者硬體防火牆中封掉來源 IP，這樣 SYN FLOOD 網路幀就不會發送到伺服器中。

案例結束後，也不要忘了收尾，記得停止最開始啟動的 Nginx 服務以及 hping3 命令。

在第一個終端中，運行下面的命令就可以停止 Nginx 了：

軟中斷 CPU 使用率（softirq）升高是一種很常見的性能問題。雖然軟中斷的類型很多，但實際生產中，我們遇到的性能瓶頸大多是網路收發類型的軟中斷，特別是網路接收的軟中斷。

在碰到這類問題時，你可以借用 sar、tcpmp 等工具，做進一步分析。

有同學說在查看軟中斷數據時會顯示128個核的數據，我的也是，雖然只有一個核，但是會顯示128個核的信息，用下面的命令可以提取有數據的核，我的1核，所以這個命令只能顯示1核，多核需要做下修改

watch -d "/bin/cat /proc/softirqs | /usr/bin/awk 'NR == 1{printf "%13s %s\n"," ",$1}; NR > 1{printf "%13s %s\n",$1,$2}'"

❺ 如何查看linux軟中斷信息

先說說環境1.硬體:DELL R410
2.網卡:板載1000M BCM5709
2.OS: RHEL 5.5 x86_64
3.KERNEL: 2.6.18-194.el5
所出現的問題
1.網卡毫無徵兆的down掉，而且沒有任何log信息
2.當流量增大時，不到理論上限的1/3時機器出現網路延遲嚴重，伴隨大量的丟包
3.機器的cpu軟中斷不均衡，只有1個cpu處理軟中斷，並且該cpu的軟中斷周期性的達到100%
4.內外網網卡做nat丟包數據量不一致，差別很大，不在同一個數量級
想必第一個問題，大部分使用bcm網卡，rhel 5.3以後得機器都會遇到這種情況，網上的資料比較的多，我也不多啰嗦了，直接升級網卡驅動就可以解決了。第二，三，四其實是同一個問題都是由於網卡中斷過多，cpu處理不過來(准確的說，cpu分配不均衡，導致只有一個cpu處理，處理不過來)，引起丟包，那麼為什麼兩個網卡丟包的數量級不一樣呢，下面從原理上進行解釋，既然是做nat多出口，那麼就有大量的路由信息，是一個網路應用，當一個數據包請求nat時，數據包先被網卡驅動的數據接收，網卡收到數據時，觸發中斷。在中斷執行常式中，把skb掛入輸入隊列，並觸發軟中斷。稍後的某個時刻，當軟中斷執行時，再從該隊列中把skb取下來，投遞給上層協議。

❻ Linux-怎麼理解軟中斷

中斷是系統用來響應硬體設備請求的一種機制，它會打斷進程的正常調度和執行，然後調用內核中的中斷處理程序來響應設備的請求。

你可能要問了，為什麼要有中斷呢？我可以舉個生活中的例子，讓感受一下中斷的魅力。

比如你訂了一份外賣，但是不確定外賣什麼時候送到，也沒有別的方法了解外賣的進度，但是，配送員送外賣是不等人的，到了你這兒沒人取的話，就直接走人了，所以你只能苦苦等著，時不時去門口看看外賣送到沒，而不能幹其他事情。

不過呢，如果在訂外賣的時候，你就跟配送員約定好，讓他送到後給你打個電話，那你就不用苦苦等待了，就可以去忙別的事情，直到電話一響，接電話、取外賣就可以了。

這里的「打電話」，其實就是一個中斷。沒接到電話的時候，你可以做其他的事情；只有接到了電話（也就是發生中斷），你才要進行另一個動作：取外賣。

這個例子你就可以發現， 中斷其實是一種非同步的事件處理機制，可以提高系統的並發處理能力。

由於中斷處理程序會打斷其他進程的運行，所以， 為了減少對正常進程運行調度的影響，中斷處理程序就需要盡可能快地運行。 如果中斷本身要做的事情不多，那麼處理起來也不會有太大問題；但如果中斷要處理的事情很多，中斷服務程序就有可能要運行很長時間。

特別是，中斷處理程序在響應中斷時，還會臨時關閉中斷。這就會導致上一次中斷處理完成之前，其他中斷都不能響應，也就是說中斷有可能會丟失。

那麼還是以取外賣為例。假如你訂了 2 份外賣，一份主食和一份飲料，並且是由 2 個不同的配送員來配送。這次你不用時時等待著，兩份外賣都約定了電話取外賣的方式。但是，問題又來了。

當第一份外賣送到時，配送員給你打了個長長的電話，商量發票的處理方式。與此同時，第二個配送員也到了，也想給你打電話。

但是很明顯，因為電話占線（也就是關閉了中斷響應），第二個配送員的電話是打不通的。所以，第二個配送員很可能試幾次後就走掉了（也就是丟失了一次中斷）。

如果你弄清楚了「取外賣」的模式，那對系統的中斷機制就很容易理解了。事實上，為了解決中斷處理程序執行過長和中斷丟失的問題，Linux 將中斷處理過程分成了兩個階段，也就是 上半部和下半部：

比如說前面取外賣的例子，上半部就是你接聽電話，告訴配送員你已經知道了，其他事兒見面再說，然後電話就可以掛斷了；下半部才是取外賣的動作，以及見面後商量發票處理的動作。

這樣，第一個配送員不會佔用你太多時間，當第二個配送員過來時，照樣能正常打通你的電話。

除了取外賣，我再舉個最常見的網卡接收數據包的例子，讓你更好地理解。

網卡接收到數據包後，會通過 硬體中斷 的方式，通知內核有新的數據到了。這時，內核就應該調用中斷處理程序來響應它。你可以自己先想一下，這種情況下的上半部和下半部分別負責什麼工作呢？

對上半部來說，既然是快速處理，其實就是要把網卡的數據讀到內存中，然後更新一下硬體寄存器的狀態（表示數據已經讀好了），最後再發送一個 軟中斷 信號，通知下半部做進一步的處理。

而下半部被軟中斷信號喚醒後，需要從內存中找到網路數據，再按照網路協議棧，對數據進行逐層解析和處理，直到把它送給應用程序。

所以，這兩個階段你也可以這樣理解：

實際上，上半部會打斷 CPU 正在執行的任務，然後立即執行中斷處理程序。而下半部以內核線程的方式執行，並且每個 CPU 都對應一個軟中斷內核線程，名字為 「ksoftirqd/CPU 編號」，比如說， 0 號 CPU 對應的軟中斷內核線程的名字就是 ksoftirqd/0。

不過要注意的是，軟中斷不只包括了剛剛所講的硬體設備中斷處理程序的下半部，一些內核自定義的事件也屬於軟中斷，比如內核調度和 RCU 鎖（Read-Copy Update 的縮寫，RCU 是 Linux 內核中最常用的鎖之一）等。

不知道你還記不記得，前面提到過的 proc 文件系統。它是一種內核空間和用戶空間進行通信的機制，可以用來查看內核的數據結構，或者用來動態修改內核的配置。其中：

運行下面的命令，查看 /proc/softirqs 文件的內容，你就可以看到各種類型軟中斷在不同 CPU 上的累積運行次數：

在查看 /proc/softirqs 文件內容時，你要特別注意以下這兩點。
第一，要注意軟中斷的類型，也就是這個界面中第一列的內容。從第一列你可以看到，軟中斷包括了 10 個類別，分別對應不同的工作類型。比如 NET_RX 表示網路接收中斷，而 NET_TX 表示網路發送中斷。

第二，要注意同一種軟中斷在不同 CPU 上的分布情況，也就是同一行的內容。正常情況下，同一種中斷在不同 CPU 上的累積次數應該差不多。比如這個界面中，NET_RX 在 CPU0 和 CPU1 上的中斷次數基本是同一個數量級，相差不大。

不過你可能發現，TASKLET 在不同 CPU 上的分布並不均勻。TASKLET 是最常用的軟中斷實現機制，每個 TASKLET 只運行一次就會結束 ，並且只在調用它的函數所在的 CPU 上運行。

因此，使用 TASKLET 特別簡便，當然也會存在一些問題，比如說由於只在一個 CPU 上運行導致的調度不均衡，再比如因為不能在多個 CPU 上並行運行帶來了性能限制。

另外，剛剛提到過，軟中斷實際上是以內核線程的方式運行的，每個 CPU 都對應一個軟中斷內核線程，這個軟中斷內核線程就叫做 ksoftirqd/CPU 編號。那要怎麼查看這些線程的運行狀況呢？

其實用 ps 命令就可以做到，比如執行下面的指令：

注意，這些線程的名字外面都有中括弧，這說明 ps 無法獲取它們的命令行參數（cmline）。一般來說，ps 的輸出中，名字括在中括弧里的，一般都是內核線程。

Linux 中的中斷處理程序分為上半部和下半部：
上半部對應硬體中斷，用來快速處理中斷。
下半部對應軟中斷，用來非同步處理上半部未完成的工作。

Linux 中的軟中斷包括網路收發、定時、調度、RCU 鎖等各種類型，可以通過查看 /proc/softirqs 來觀察軟中斷的運行情況。

❼ linux怎樣使用top命令查看系統狀態

top命令是Linux下常用的性能分析工具，能夠實時顯示系統中各個進程的資源佔用狀況，類似於Windows的任務管理器。
top顯示系統當前的進程和其他狀況,是一個動態顯示過程,即可以通過用戶按鍵來不斷刷新當前狀態.如果在前台執行該命令,它將獨占前台,直到用戶終止該程序為止. 比較准確的說,top命令提供了實時的對系統處理器的狀態監視.它將顯示系統中CPU最「敏感」的任務列表.該命令可以按CPU使用.內存使用和執行時間對任務進行排序；而且該命令的很多特性都可以通過互動式命令或者在個人定製文件中進行設定.
下面詳細介紹它的使用方法。
統計信息區前五行是系統整體的統計信息。第一行是任務隊列信息，同 uptime 命令的執行結果。其內容如下：
01:06:48 當前時間
up 1:22 系統運行時間，格式為時:分
1 user 當前登錄用戶數
load average: 0.06, 0.60, 0.48 系統負載，即任務隊列的平均長度。三個數值分別為 1分鍾、5分鍾、15分鍾前到現在的平均值。

第二、三行為進程和CPU的信息。當有多個CPU時，這些內容可能會超過兩行。內容如下：

total 進程總數
running 正在運行的進程數
sleeping 睡眠的進程數
stopped 停止的進程數
zombie 僵屍進程數
Cpu(s):
0.3% us 用戶空間佔用CPU百分比
1.0% sy 內核空間佔用CPU百分比
0.0% ni 用戶進程空間內改變過優先順序的進程佔用CPU百分比
98.7% id 空閑CPU百分比
0.0% wa 等待輸入輸出的CPU時間百分比
0.0%hi：硬體CPU中斷佔用百分比
0.0%si：軟中斷佔用百分比
0.0%st：虛擬機佔用百分比

最後兩行為內存信息。內容如下：

Mem:
191272k total 物理內存總量
173656k used 使用的物理內存總量
17616k free 空閑內存總量
22052k buffers 用作內核緩存的內存量
Swap:
192772k total 交換區總量
0k used 使用的交換區總量
192772k free 空閑交換區總量
123988k cached 緩沖的交換區總量,內存中的內容被換出到交換區，而後又被換入到內存，但使用過的交換區尚未被覆蓋，該數值即為這些內容已存在於內存中的交換區的大小,相應的內存再次被換出時可不必再對交換區寫入。

進程信息區統計信息區域的下方顯示了各個進程的詳細信息。首先來認識一下各列的含義。

序號 列名 含義
a PID 進程id
b PPID 父進程id
c RUSER Real user name
d UID 進程所有者的用戶id
e USER 進程所有者的用戶名
f GROUP 進程所有者的組名
g TTY 啟動進程的終端名。不是從終端啟動的進程則顯示為 ?
h PR 優先順序
i NI nice值。負值表示高優先順序，正值表示低優先順序
j P 最後使用的CPU，僅在多CPU環境下有意義
k %CPU 上次更新到現在的CPU時間佔用百分比
l TIME 進程使用的CPU時間總計，單位秒
m TIME+ 進程使用的CPU時間總計，單位1/100秒
n %MEM 進程使用的物理內存百分比
o VIRT 進程使用的虛擬內存總量，單位kb。VIRT=SWAP+RES
p SWAP 進程使用的虛擬內存中，被換出的大小，單位kb。
q RES 進程使用的、未被換出的物理內存大小，單位kb。RES=CODE+DATA
r CODE 可執行代碼佔用的物理內存大小，單位kb
s DATA 可執行代碼以外的部分(數據段+棧)佔用的物理內存大小，單位kb
t SHR 共享內存大小，單位kb
u nFLT 頁面錯誤次數
v nDRT 最後一次寫入到現在，被修改過的頁面數。
w S 進程狀態(D=不可中斷的睡眠狀態,R=運行,S=睡眠,T=跟蹤/停止,Z=僵屍進程)
x COMMAND 命令名/命令行
y WCHAN 若該進程在睡眠，則顯示睡眠中的系統函數名
z Flags 任務標志，參考 sched.h

默認情況下僅顯示比較重要的 PID、USER、PR、NI、VIRT、RES、SHR、S、%CPU、%MEM、TIME+、COMMAND 列。可以通過下面的快捷鍵來更改顯示內容。
更改顯示內容通過 f 鍵可以選擇顯示的內容。按 f 鍵之後會顯示列的列表，按 a-z 即可顯示或隱藏對應的列，最後按回車鍵確定。
按 o 鍵可以改變列的顯示順序。按小寫的 a-z 可以將相應的列向右移動，而大寫的 A-Z 可以將相應的列向左移動。最後按回車鍵確定。
按大寫的 F 或 O 鍵，然後按 a-z 可以將進程按照相應的列進行排序。而大寫的 R 鍵可以將當前的排序倒轉。

命令使用
top使用格式
top [-] [d] [p] [q] [c] [C] [S] [s] [n]

參數說明

d 指定每兩次屏幕信息刷新之間的時間間隔。當然用戶可以使用s交互命令來改變之。
p 通過指定監控進程ID來僅僅監控某個進程的狀態。
q 該選項將使top沒有任何延遲的進行刷新。如果調用程序有超級用戶許可權，那麼top將以盡可能高的優先順序運行。
S 指定累計模式
s 使top命令在安全模式中運行。這將去除交互命令所帶來的潛在危險。
i 使top不顯示任何閑置或者僵死進程。
c 顯示整個命令行而不只是顯示命令名

其他實用命令
下面介紹在top命令執行過程中可以使用的一些交互命令。從使用角度來看，熟練的掌握這些命令比掌握選項還重要一些。這些命令都是單字母的，如果在命令行選項中使用了s選項，則可能其中一些命令會被屏蔽掉。

Ctrl+L 擦除並且重寫屏幕。
h或者? 顯示幫助畫面，給出一些簡短的命令總結說明。
k 終止一個進程。系統將提示用戶輸入需要終止的進程PID，以及需要發送給該進程什麼樣的信號。一般的終止進程可以使用15信號；如果不能正常結束那就使用信號9強制結束該進程。默認值是信號15。在安全模式中此命令被屏蔽。
i 忽略閑置和僵死進程。這是一個開關式命令。
q 退出程序。
r 重新安排一個進程的優先順序別。系統提示用戶輸入需要改變的進程PID以及需要設置的進程優先順序值。輸入一個正值將使優先順序降低，反之則可以使該進程擁有更高的優先權。默認值是10。
S 切換到累計模式。
s 改變兩次刷新之間的延遲時間。系統將提示用戶輸入新的時間，單位為s。如果有小數，就換算成m s。輸入0值則系統將不斷刷新，默認值是5 s。需要注意的是如果設置太小的時間，很可能會引起不斷刷新，從而根本來不及看清顯示的情況，而且系統負載也會大大增加。
f或者F 從當前顯示中添加或者刪除項目。
o或者O 改變顯示項目的順序。
l 切換顯示平均負載和啟動時間信息。
m 切換顯示內存信息。
t 切換顯示進程和CPU狀態信息。
c 切換顯示命令名稱和完整命令行。
M 根據駐留內存大小進行排序。
P 根據CPU使用百分比大小進行排序。
T 根據時間/累計時間進行排序。
W 將當前設置寫入~/.toprc文件中。這是寫top配置文件的推薦方法。

附常用操作:
top //每隔5秒顯式所有進程的資源佔用情況
top -d 2 //每隔2秒顯式所有進程的資源佔用情況
top -c //每隔5秒顯式進程的資源佔用情況，並顯示進程的命令行參數(默認只有進程名)
top -p 12345 -p 6789//每隔5秒顯示pid是12345和pid是6789的兩個進程的資源佔用情況
top -d 2 -c -p 123456 //每隔2秒顯示pid是12345的進程的資源使用情況，並顯式該進程啟動的命令行參數

❽ linux 內核軟中斷 是在中斷狀態嗎

先說說環境
1.硬體:DELL R410
2.網卡:板載1000M BCM5709
2.OS: RHEL 5.5 x86_64
3.KERNEL: 2.6.18-194.el5
所出現的問題
1.網卡毫無徵兆的down掉，而且沒有任何log信息
2.當流量增大時，不到理論上限的1/3時機器出現網路延遲嚴重，伴隨大量的丟包
3.機器的cpu軟中斷不均衡，只有1個cpu處理軟中斷，並且該cpu的軟中斷周期性的達到100%
4.內外網網卡做nat丟包數據量不一致，差別很大，不在同一個數量級
想必第一個問題，大部分使用bcm網卡，rhel 5.3以後得機器都會遇到這種情況，網上的資料比較的多，我也不多啰嗦了，直接升級網卡驅動就可以解決了。第二，三，四其實是同一個問題都是由於網卡中斷過多，cpu處理不過來(准確的說，cpu分配不均衡，導致只有一個cpu處理，處理不過來)，引起丟包，那麼為什麼兩個網卡丟包的數量級不一樣呢，下面從原理上進行解釋，既然是做nat多出口，那麼就有大量的路由信息，是一個網路應用，當一個數據包請求nat時，數據包先被網卡驅動的數據接收，網卡收到數據時，觸發中斷。在中斷執行常式中，把skb掛入輸入隊列，並觸發軟中斷。稍後的某個時刻，當軟中斷執行時，再從該隊列中把skb取下來，投遞給上層協議。
如果在這個過程當中cpu沒有及時處理完這個隊列導致網卡的buffer滿了，網卡將直接丟棄該數據包。這里牽涉到2個隊列，一個是tx，一個是rx，它的隊列的大小默認都是255，可以通過ethtool -g eth0(你指定的網卡)，為了防止丟包，當時我通過ethtool -G eth0 rx xxx 把它調大了，但是調大以後，還是杯水車薪啊，通過ethtool -S eth0 |grep rx_fw_discards,發現數值還是不停的在增長，也就是說還在不停的丟包，cpu處理不過來，這時候找到網上有人在利用lvs時也遇到這個問題，cpu軟中斷分配不均衡，只有一個cpu處理軟中斷的問題，網上的資料五花八門，有建議使用修改設備中斷方式。即通過修改設置中斷/proc/irq/${網卡中斷號}/smp_affinit這時候，我也修改過，沒有什麼實質的效果，
從官方的bug報告，https://bugzilla.redhat.com/show_bug.cgi?id=520888，其中提到rhel5.6已經修復了這個bug，這其中也提到目前我們的版本可以升級內核到kernel-2.6.18-194.3.1.el5可以解決這個問題。
紅帽子官方修復報告中的說明如下：http://rhn.redhat.com/errata/RHSA-2010-0398.html，我們升級了這個內核算是解決單核處理軟中斷的問題，升級後各個cpu已經能夠平均的分配這個軟中斷，也不丟包了，那麼為什麼cpu處理不過來這個軟中斷呢，數據量並不是特別的大啊，上層應用接到這個數據包後，通過路由協議，找到某個出口給nat出去，找nat出口是需要查找路由表，查詢路由表是一件很耗時的工作，而每一個不同源地址，不同目的地址的數據包都得重新查找一次路由表，導致cpu處理不過來，為了提高路由查詢的效率。Linux內核引用了路由緩存，用於減少對路由表的查詢。Linux的路由緩存是被設計來與協議無關的獨立子系統，查看路由緩存可以通過命令route -Cn,由於路由緩存當中是採用hash演算法進行才找，它的查找速度非常之快，既然是cache就有超時這一概念。系統默認為10分鍾，可以通過這個文件進行查看和修改/proc/sys/net/ipv4/route/secret_interval。而當路由緩存當中未找到或者已經超時的路由信息才開始查找路由表，查詢到的結果保存在路由緩存中。如果路由表越大，那麼查詢的時間就越長，一個新的連接進來後或者是老連接cache超時後，佔用大量的cpu查詢時間，導致cpu周期性的軟中斷出現100%，而兩個網卡丟包的情況來看不均衡也是因為用戶的數據包是經過其中一個網卡進來後查詢路由表耗時過長，cpu處理不過來，導致那塊網卡的隊列滿了，丟包嚴重。當然在路由表變動不大的情況下可以加大cache的時間，修改上述內容後，從我監測的情況來看，扛流量能力得到了大大的提升。

❾ LINUX軟中斷通信

我也是初學者，這里抄一段《Linux設備驅動程序》書上的給你：

Linux的中斷宏觀分為兩種：軟中斷和硬中斷。聲明一下，這里的軟和硬的意思是指和軟體相關以及和硬體相關，而不是軟體實現的中斷或硬體實現的中斷。軟中斷就是「信號機制」。軟中斷不是軟體中斷。Linux通過信號來產生對進程的各種中斷操作，我們現在知道的信號共有31個，其具體內容這里略過。
一般來說，軟中斷是由內核機制的觸發事件引起的（例如進程運行超時），但是不可忽視有大量的軟中斷也是由於和硬體有關的中斷引起的，例如當列印機埠產生一個硬體中斷時，會通知和硬體相關的硬中斷，硬中斷就會產生一個軟中斷並送到操作系統內核里，這樣內核就會根據這個軟中斷喚醒睡眠在列印機任務隊列中的處理進程。
硬中斷就是通常意義上的「中斷處理程序」，它是直接處理由硬體發過來的中斷信號的。當硬中斷收到它應當處理的中斷信號以後，就回去自己驅動的設備上去看看設備的狀態寄存器以了解發生了什麼事情，並進行相應的操作。
對於軟中斷，我們不做討論，那是進程調度里要考慮的事情。由於我們討論的是設備驅動程序的中斷問題，所以焦點集中在硬中斷里。我們這里討論的是硬中斷，即和硬體相關的中斷。
要中斷，是因為外設需要通知操作系統她那裡發生了一些事情，但是中斷的功能僅僅是一個設備報警燈，當燈亮的時候中斷處理程序只知道有事情發生了，但發生了什麼事情還要親自到設備那裡去看才行。也就是說，當中斷處理程序得知設備發生了一個中斷的時候，它並不知道設備發生了什麼事情，只有當它訪問了設備上的一些狀態寄存器以後，才能知道具體發生了什麼，要怎麼去處理。
設備通過中斷線向中斷控制器發送高電平告訴操作系統它產生了一個中斷，而操作系統會從中斷控制器的狀態位知道是哪條中斷線上產生了中斷。PC機上使用的中斷控制器是8259，這種控制器每一個可以管理8條中斷線，當兩個8259級聯的時候共可以控制15條中斷線。這里的中斷線是實實在在的電路，他們通過硬體介面連接到CPU外的設備控制器上。
並不是每個設備都可以向中斷線上發中斷信號的，只有對某一條確定的中斷線勇有了控制權，才可以向這條中斷線上發送信號。由於計算機的外部設備越來越多，所以15條中斷線已經不夠用了，中斷線是非常寶貴的資源。要使用中斷線，就得進行中斷線的申請，就是IRQ(Interrupt Requirement)，我們也常把申請一條中斷線成為申請一個IRQ或者是申請一個中斷號。
IRQ是非常寶貴的，所以我們建議只有當設備需要中斷的時候才申請佔用一個IRQ，或者是在申請IRQ時採用共享中斷的方式，這樣可以讓更多的設備使用中斷。無論對IRQ的使用方式是獨占還是共享，申請IRQ的過程都是一樣的，分為3步：
1．將所有的中斷線探測一遍，看看哪些中斷還沒有被佔用。從這些還沒有被佔用的中斷中選一個作為該設備的IRQ。
2．通過中斷申請函數申請選定的IRQ，這是要指定申請的方式是獨占還是共享。
3．根據中斷申請函數的返回值決定怎麼做：如果成功了萬事大吉，如果沒成功則或者重新申請或者放棄申請並返回錯誤。
Linux中的中斷處理程序很有特色，它的一個中斷處理程序分為兩個部分：上半部（top half）和下半部(bottom half)。之所以會有上半部和下半部之分，完全是考慮到中斷處理的效率。
上半部的功能是「登記中斷」。當一個中斷發生時，他就把設備驅動程序中中斷常式的下半部掛到該設備的下半部執行隊列中去，然後就沒事情了--等待新的中斷的到來。這樣一來，上半部執行的速度就會很快，他就可以接受更多她負責的設備產生的中斷了。上半部之所以要快，是因為它是完全屏蔽中斷的，如果她不執行完，其它的中斷就不能被及時的處理，只能等到這個中斷處理程序執行完畢以後。所以，要盡可能多得對設備產生的中斷進行服務和處理，中斷處理程序就一定要快。
但是，有些中斷事件的處理是比較復雜的，所以中斷處理程序必須多花一點時間才能夠把事情做完。可怎麼樣化解在短時間內完成復雜處理的矛盾呢，這時候 Linux引入了下半部的概念。下半部和上半部最大的不同是下半部是可中斷的，而上半部是不可中斷的。下半部幾乎做了中斷處理程序所有的事情，因為上半部只是將下半部排到了他們所負責的設備的中斷處理隊列中去，然後就什麼都不管了。下半部一般所負責的工作是察看設備以獲得產生中斷的事件信息，並根據這些信息（一般通過讀設備上的寄存器得來）進行相應的處理。如果有些時間下半部不知道怎麼去做，他就使用著名的鴕鳥演算法來解決問題--說白了就是忽略這個事件。
由於下半部是可中斷的，所以在它運行期間，如果其它的設備產生了中斷，這個下半部可以暫時的中斷掉，等到那個設備的上半部運行完了，再回頭來運行它。但是有一點一定要注意，那就是如果一個設備中斷處理程序正在運行，無論她是運行上半部還是運行下半部，只要中斷處理程序還沒有處理完畢，在這期間設備產生的新的中斷都將被忽略掉。因為中斷處理程序是不可重入的，同一個中斷處理程序是不能並行的。
在Linux Kernel 2.0以前，中斷分為快中斷和慢中斷（偽中斷我們這里不談），其中快中斷的下半部也是不可中斷的，這樣可以保證它執行的快一點。但是由於現在硬體水平不斷上升，快中斷和慢中斷的運行速度已經沒有什麼差別了，所以為了提高中斷常式事務處理的效率，從Linux kernel 2.0以後，中斷處理程序全部都是慢中斷的形式了--他們的下半部是可以被中斷的。
但是，在下半部中，你也可以進行中斷屏蔽--如果某一段代碼不能被中斷的話。你可以使用cti、sti或者是save_flag、restore_flag來實現你的想法。
在處理中斷的時候，中斷控制器會屏蔽掉原先發送中斷的那個設備，直到她發送的上一個中斷被處理完了為止。因此如果發送中斷的那個設備載中斷處理期間又發送了一個中斷，那麼這個中斷就被永遠的丟失了。
之所以發生這種事情，是因為中斷控制器並不能緩沖中斷信息，所以當前一個中斷沒有處理完以前又有新的中斷到達，他肯定會丟掉新的中斷的。但是這種缺陷可以通過設置主處理器(CPU)上的「置中斷標志位」（sti）來解決，因為主處理器具有緩沖中斷的功能。如果使用了「置中斷標志位」，那麼在處理完中斷以後使用sti函數就可以使先前被屏蔽的中斷得到服務。
有時候需要屏蔽中斷，可是為什麼要將這個中斷屏蔽掉呢？這並不是因為技術上實現不了同一中斷常式的並行，而是出於管理上的考慮。之所以在中斷處理的過程中要屏蔽同一IRQ來的新中斷，是因為中斷處理程序是不可重入的，所以不能並行執行同一個中斷處理程序。在這里我們舉一個例子，從這里子例中可以看出如果一個中斷處理程序是可以並行的話，那麼很有可能會發生驅動程序鎖死的情況。當驅動程序鎖死的時候，你的操作系統並不一定會崩潰，但是鎖死的驅動程序所支持的那個設備是不能再使用了--設備驅動程序死了，設備也就死了。
A是一段代碼，B是操作設備寄存器R1的代碼，C是操作設備寄存器R2的代碼。其中激發PS1的事件會使A1產生一個中斷，然後B1去讀R1中已有的數據，然後代碼C1向R2中寫數據。而激發PS2的事件會使A2產生一個中斷，然後B2刪除R1中的數據，然後C2讀去R2中的數據。
如果PS1先產生，且當他執行到A1和B1之間的時候，如果PS2產生了，這是A2會產生一個中斷，將PS2中斷掉（掛到任務隊列的尾部），然後刪除了 R1的內容。當PS2運行到C2時，由於C1還沒有向R2中寫數據，所以C2將會在這里被掛起，PS2就睡眠在代碼C2上，直到有數據可讀的時候被信號喚醒。這是由於PS1中的B2原先要讀的R1中的數據被PS2中的B2刪除了，所以PS1頁會睡眠在B1上，直到有數據可讀的時候被信號喚醒。這樣一來，喚醒PS1和PS2的事件就永遠不會發生了，因此PS1和PS2之間就鎖死了。
由於設備驅動程序要和設備的寄存器打交道，所以很難寫出可以重入的代碼來，因為設備寄存器就是全局變數。因此，最簡潔的辦法就是禁止同一設備的中斷處理程序並行，即設備的中斷處理程序是不可重入的。
有一點一定要清楚：在2.0版本以後的Linux kernel中，所有的上半部都是不可中斷的（上半部的操作是原子性的）；不同設備的下半部可以互相中斷，但一個特定的下半部不能被它自己所中斷（即同一個下半部不能並）。
由於中斷處理程序要求不可重入，所以程序員也不必為編寫可重入的代碼而頭痛了。編寫可重入的設備驅動程序是可以的，編寫可重入的中斷處理程序是非常難得，幾乎不可能。
我們都知道，一旦競爭條件出現了，就有可能會發生死鎖的情況，嚴重時可能會將整個系統鎖死。所以一定要避免競爭條件的出現。只要注意一點：絕大多數由於中斷產生的競爭條件，都是在帶有中斷的
內核進程被睡眠造成的。所以在實現中斷的時候，一定要相信謹慎的讓進程睡眠，必要的時候可以使用cli、sti或者save_flag、restore_flag。