導航:首頁 > 操作系統 > linuxio中斷

linuxio中斷

發布時間:2023-01-10 19:54:09

linux查看磁碟io的幾種方法

linux查看磁碟io的幾種方法

怎樣才能快速的定位到並發高是由於磁碟io開銷大呢?可以通過三種方式:

第一種:用 top 命令 中的cpu 信息觀察

Top可以看到的cpu信息有:

Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.3% us, 1.0% sy, 0.0% ni, 98.7% id, 0.0% wa, 0.0% hi, 0.0% si

具體的解釋如下:

Tasks: 29 total 進程總數

1 running 正在運行的進程數

28 sleeping 睡眠的進程數

0 stopped 停止的進程數

0 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

0.0% si

0.0% wa 的百分比可以大致的體現出當前的磁碟io請求是否頻繁。如果 wa的數量比較大,說明等待輸入輸出的的io比較多。

第二種:用vmstat

vmstat 命令報告關於線程、虛擬內存、磁碟、陷阱和 CPU 活動的統計信息。由 vmstat 命令生成的報告可以用於平衡系統負載活動。系統范圍內的這些統計信息(所有的處理器中)都計算出以百分比表示的平均值,或者計算其總和。

輸入命令:

vmstat 2 5

如果發現等待的進程和處在非中斷睡眠狀態的進程數非常多,並且發送到塊設備的塊數和從塊設備接收到的塊數非常大,那就說明磁碟io比較多。

vmstat參數解釋:

Procs

r: 等待運行的進程數 b: 處在非中斷睡眠狀態的進程數 w: 被交換出去的可運行的進程數。此數由 linux 計算得出,但 linux 並不耗盡交換空間

Memory

swpd: 虛擬內存使用情況,單位:KB

free: 空閑的內存,單位KB

buff: 被用來做為緩存的內存數,單位:KB

Swap

si: 從磁碟交換到內存的交換頁數量,單位:KB/秒

so: 從內存交換到磁碟的交換頁數量,單位:KB/秒

IO

bi: 發送到塊設備的塊數,單位:塊/秒

bo: 從塊設備接收到的塊數,單位:塊/秒

System

in: 每秒的中斷數,包括時鍾中斷

cs: 每秒的環境(上下文)切換次數

CPU

按 CPU 的總使用百分比來顯示

us: CPU 使用時間

sy: CPU 系統使用時間

id: 閑置時間

准測

更多vmstat使用信息

第二種:用iostat

安裝:

Iostat 是 sysstat 工具集的一個工具,需要安裝。

Centos的安裝方式是:

yum install sysstat

Ubuntu的安裝方式是:

aptitude install sysstat

使用:

iostat -dx 顯示磁碟擴展信息

root@fileapp:~# iostat -dx

r/s 和 w/s 分別是每秒的讀操作和寫操作,而rKB/s 和wKB/s 列以每秒千位元組為單位顯示了讀和寫的數據量

如果這兩對數據值都很高的話說明磁碟io操作是很頻繁。

+++++++++++++++++++++++++++++++++++++

linux wa%過高,iostat查看io狀況

1, 安裝  iostat  

yum install sysstat

之後就可以使用 iostat 命令了,

2,入門使用

iostat -d -k 2

參數 -d 表示,顯示設備(磁碟)使用狀態;-k某些使用block為單位的列強制使用Kilobytes為單位;2表示,數據顯示每隔2秒刷新一次。

tps:該設備每秒的傳輸次數(Indicate the number of transfers per second that were issued to the device.)。"一次傳輸"意思是"一次I/O請求"。多個邏輯請求可能會被合並為"一次I/O請求"。"一次傳輸"請求的大小是未知的。kB_read/s:每秒從設備(drive expressed)讀取的數據量;

kB_wrtn/s:每秒向設備(drive expressed)寫入的數據量;

kB_read:讀取的總數據量;kB_wrtn:寫入的總數量數據量;這些單位都為Kilobytes。

指定監控的設備名稱為sda,該命令的輸出結果和上面命令完全相同。

iostat -d sda 2

默認監控所有的硬碟設備,現在指定只監控sda。 

3, -x 參數

iostat還有一個比較常用的選項 -x ,該選項將用於顯示和io相關的擴展數據。

iostat -d -x -k 1 10

輸出信息的含義



4, 常見用法

iostat -d -k 1 10        #查看TPS和吞吐量信息(磁碟讀寫速度單位為KB)

iostat -d -m 2            #查看TPS和吞吐量信息(磁碟讀寫速度單位為MB)

iostat -d -x -k 1 10      #查看設備使用率(%util)、響應時間(await) iostat -c 1 10 #查看cpu狀態

5, 實例分析

iostat -d -k 1 | grep vda

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

sda10            60.72        18.95        71.53  395637647 1493241908

sda10          299.02      4266.67      129.41      4352        132

sda10          483.84      4589.90      4117.17      4544      4076

sda10          218.00      3360.00      100.00      3360        100

sda10          546.00      8784.00      124.00      8784        124

sda10          827.00    13232.00      136.00      13232        136

上面看到,磁碟每秒傳輸次數平均約400;每秒磁碟讀取約5MB,寫入約1MB。

iostat -d -x -k 1

Device:    rrqm/s wrqm/s  r/s  w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz  await  svctm  %util

sda          1.56  28.31  7.84 31.50  43.65    3.16    21.82    1.58    1.19    0.03    0.80  2.61  10.29

sda          1.98  24.75 419.80  6.93 13465.35  253.47  6732.67  126.73    32.15    2.00    4.70  2.00  85.25

sda          3.06  41.84 444.90 54.08 14204.08 2048.98  7102.04  1024.49    32.57    2.10    4.21  1.85  92.24

可以看到磁碟的平均響應時間<5ms,磁碟使用率>80。磁碟響應正常,但是已經很繁忙了。

可以看到磁碟的平均響應時間<5ms,磁碟使用率>90。磁碟響應正常,但是已經很繁忙了。

await:  每一個IO請求的處理的平均時間(單位是微秒毫秒)。這里可以理解為IO的響應時間,一般地系統IO響應時間應該低於5ms,如果大於10ms就比較大了

svctm    表示平均每次設備I/O操作的服務時間(以毫秒為單位)。如果svctm的值與await很接近,表示幾乎沒有I/O等待,磁碟性能很好,

如果await的值遠高於svctm的值,則表示I/O隊列等待太長,  系統上運行的應用程序將變慢。

%util: 在統計時間內所有處理IO時間,除以總共統計時間

所以該參數暗示了設備的繁忙程度

。一般地,如果該參數是100%表示設備已經接近滿負荷運行了(當然如果是多磁碟,即使%util是100%,因為磁碟的並發能力,所以磁碟使用未必就到了瓶頸)。

也可以使用下面的命令,同時顯示cpu和磁碟的使用情況

等待時間超過5ms, 磁碟io有問題

⑵ linux執行db2 sql的sh腳本操作中斷

oracle 10g的DBMS_XPLAN包中display_cursor函數不同於display函數,display_cursor用於顯示SQL語句的真實的執行計劃,在大多數情況下,
顯示真實的執行計劃有助於更好的分析SQL語句的全過程,尤其是運行此SQL語句實時的I/O開銷。通過對比預估的I/O與真實的I/O開銷來判斷
SQL語句所存在問題,如缺少統計信息,SQL語句執行的次數,根據實際中間結果集的大小來選擇合適的連接方式等。本文僅僅講述
display_cursor函數的使用。

一、display_cursor函數用法
1、display_cursor函數語法

DBMS_XPLAN.DISPLAY_CURSOR(
sql_id IN VARCHAR2 DEFAULT NULL,
cursor_child_no IN NUMBER DEFAULT NULL,
format IN VARCHAR2 DEFAULT 'TYPICAL');

2、display_cursor函數參數描述
sql_id
指定位於庫緩存執行計劃中SQL語句的父游標。默認值為null。當使用默認值時當前會話的最後一條SQL語句的執行計劃將被返回
可以通過查詢V$SQL 或V$SQLAREA的SQL_ID列來獲得SQL語句的SQL_ID。
cursor_child_no
指定父游標下子游標的序號。即指定被返回執行計劃的SQL語句的子游標。默認值為0。如果為null,則sql_id所指父游標下所有子游標
的執行計劃都將被返回。
format
控制SQL語句執行計劃的輸出部分,即哪些可以顯示哪些不顯示。使用與display函數的format參數與修飾符在這里同樣適用。
除此之外當在開啟statistics_level=all時或使用gather_plan_statistics提示可以獲得執行計劃中實時的統計信息
有關詳細的format格式描述請參考:dbms_xplan之display函數的使用 中format參數的描述

下面給出啟用統計信息時format新增的修飾符
iostats 控制I/O統計的顯示
last 默認,顯示所有執行計算過的統計。如果指定該值,則只顯示最後一次執行的統計信息
memstats 控制pga相關統計的顯示
allstats 此為iostats memstats的快捷方式,即allstats包含了iostats和memstats
run_stats_last 等同於iostats last。只能用於oracle 10g R1
run_stats_tot 等同於iostats。只能用於oracle 10g R1

抓一個最近一小時最消耗IO的SQL:
SELECT sql_id, COUNT(*)
FROM gv$active_session_history ash, gv$event_name evt
WHERE ash.sample_time > SYSDATE - 1 / 24
AND ash.session_state = 'WAITING'
AND ash.event_id = evt.event_id
AND evt.wait_class = 'User I/O'
GROUP BY sql_id
ORDER BY COUNT(*) DESC;

執行上面的SQL:
SQL> SELECT sql_id, COUNT(*)
FROM gv$active_session_history ash, gv$event_name evt
2 3 WHERE ash.sample_time > SYSDATE - 1 / 24
4 AND ash.session_state = 'WAITING'
5 AND ash.event_id = evt.event_id
6 AND evt.wait_class = 'User I/O'
7 GROUP BY sql_id
8 ORDER BY COUNT(*) DESC;

SQL_ID COUNT(*)
------------- ----------
g7fu6qba82m6b 668
63r47zyphdk06 526
9f5m4wd88nc1h 514
593p47drw5fhk 232
br91w16jzy4fu 120
4fvwyjpnh6tp7 78
gm0nrbfuj8kzr 70
2184k363hw4xd 68
gc4dajs7g5myy 46
8vrk9sfuwfdgq 42
ccpnb4dwdmq21 40

查看SQL的執行計劃:
SELECT * FROM TABLE(dbms_xplan.display_cursor('g7fu6qba82m6b'));

在SQLPLUS中執行:
SQL> set pagesize 2000
SQL> SELECT * FROM TABLE(dbms_xplan.display_cursor('g7fu6qba82m6b'));

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------
SQL_ID g7fu6qba82m6b, child number 0
-------------------------------------
UPDATE "CPDDS_PDATA"."CDM_LEDGER" SET "CSTM_NAME" = :a1,"CSTM_NO" =
:a2,"PAPER_TYPE" = :a3,"PAPER_NO" = :a4,"CURR_TYPE" = :a5,"SVT_NO" =
:a6,"BAL_DIR" = :a7,"BAL" = :a8,"AVAL_BAL" = :a9,"NORM_FRATIO" =
:a10,"PK_BAL" = :a11,"DR_ACCU" = :a12,"CR_ACCU" = :a13,"LAST_TRAN_DATE" =
:a14,"LAST_TRAN_TIME" = :a15,"PRT_LINE_NUM" = :a16,"NOREG_PK_REC_NUM" =
:a17,"PK_NO" = :a18,"PWD" = :a19,"FLAG" = :a20,"FRZ_FLAG" =
:a21,"CARD_HOLD_FLAG" = :a22,"PK_HOLD_FLAG" = :a23,"BGN_INT_DATE" =
:a24,"OPEN_DATE" = :a25,"ACC_HOLD_FLAG" = :a26,"CLS_DATE" =
:a27,"OPEN_TLR" = :a28,"CLS_TLR" = :a29,"CLS_INT" = :a30,"OPEN_INST" =
:a31,"ADD_NUM" = :a32,"DAC" = :a33,"FRZ_TIMES1" = :a34,"FRZ_TIMES2" =
:a35,"HOST_SEQNO" = :a36,"D_UPDATE_DATE" = :a37 WHERE "ACC" = :b0

Plan hash value: 319441092

-----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT | | | | 3 (100)| |
| 1 | UPDATE | CDM_LEDGER | | | | |
|* 2 | INDEX UNIQUE SCAN| I_CDM_LEDGER | 1 | 269 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("ACC"=:B0)

29 rows selected.

總結
1、與display函數不同,display_cursor顯示的為真實的執行計劃
2、對於format參數,使用與display函數的各個值,同樣適用於display_cursor函數
3、當statistics_level為all或使用gather_plan_statistics提示可以獲得執行時的統計信息
4、根據真實與預估的統計信息可以初步判斷SQL效率低下的原因,如統計信息的准確性、主要的開銷位於那些步驟等

⑶ Linux--常見問題:LOAD高但是CPU和IO都很低問題解決

正常情況下我們在發現Load 過高時都會去查詢幾個方向

按上面情況查詢基本上99%的都能查出問題所在,但是剩餘1%特殊情況確無法判斷出來
下面介紹下剩餘1%中的一種相對常見的情況。

查看一下進程的狀態:
# top -H
# shift+o =選擇w (按照狀態排序)
# R(排序)

結果發現一近十個find和其它進程的狀態是D(uninterruptible sleep)。
再看看進程,該機器掛了nfs,因此應該是大耗時操作掛載盤的結果
1,一般這種情況想立刻解決可以直接重新mount這些盤使這些IO操作失敗中斷。
2, 強制卸載目錄 umount -f 目錄
註:使用-f 參數進行強制卸載時一般建議等一會兒,一些情況下處理需要1-2分鍾的時間。
3,使用umount -f,問題依舊。使用fuser命令,先確認有那些進程在佔用該目錄
# fuser -cu 目錄 查詢關聯應用
# fuser -ck 目錄 強制卸載

⑷ 深入剖析Linux IO原理和幾種零拷貝機制的實現未完待續

1。物理內存和虛擬內存

物理內存只有內核才可以訪問。

因為操作系統的進程與進程之間是共享CPU和資源的,為了防止進程之間互相影響就有了一個對主存的抽象概念:虛擬內存。虛擬內存使得應用程序以為自己有一塊連續獨立的存儲空間,實際上是多個物理內存碎片。而虛擬內存和物理內存的對應關系存放在一個叫頁表的地方。每個進程都有自己獨立的頁表。下圖為上述三個概念的關系。

現在來總結下進程申請並訪問物理內存的過程:

2。內核空間和用戶空間

操作系統的核心是內核,獨立於普通的應用程序。可以訪問受保護的內存空間也可以訪問硬體設備。為了保護內核安全,所以將虛擬內存分為內核空間和用戶空間。 內核模塊運行於內核空間,對應的進程處於內核態。用戶模塊運行於用戶空間,對應的進程處於用戶態。

3。Linux IO 讀寫的方式

輪詢/IO中斷/DMA

3.1 IO中斷。 一個圖就可以懂🦈

具體過程如下(圖已經清晰了 _ 為了以後回憶文字也貼上來

3.2 DMA

其實我自己感覺只是節省的CPU一小部分的時間(將數據從磁碟緩沖區復制到內核緩沖區)

前面已經講了Linux 操作的兩種方式具體步驟,下面講一下 讀寫 整個過程的步驟。為了更好的理解零拷貝實現方式所以理解基礎的讀寫過程也很重要。

4 傳統的IO
在linux系統中通過read()方法讀取文件到緩沖區,調用write()方法將緩沖區的數據輸出到網路埠。

4次上下文切換:讀寫時(用戶態 <==> 內核態)
4次拷貝動作:DMA2次 + CPU2次
Ps:

4.1 傳統的寫操作
寫數據和讀數據差不多啦就不寫了

5 零拷貝實現方式的思路

這個文章也可以看一下 https://cloud.tencent.com/developer/article/1346483

摘抄於 https://zhuanlan.hu.com/p/83398714

閱讀全文

與linuxio中斷相關的資料

熱點內容
asp用戶注冊源碼 瀏覽:48
什麼是照片壓縮文件 瀏覽:392
java調用js代碼 瀏覽:979
崑山市民app怎麼修改身份信息 瀏覽:779
php登陸次數 瀏覽:744
python字元轉成數字 瀏覽:822
海川用的是什麼伺服器 瀏覽:376
口才是練出來的pdf 瀏覽:458
雲伺服器哪個公司性價比高 瀏覽:517
源碼論壇打包 瀏覽:558
php怎麼做成word 瀏覽:692
python批量生成密鑰 瀏覽:492
程序員要不要考社區人員 瀏覽:150
app的錢怎麼充q幣 瀏覽:813
android銀行卡識別 瀏覽:756
怎麼在app投放廣告 瀏覽:11
手機文件管理怎麼看app名稱 瀏覽:192
程序員學數學哪本書最全 瀏覽:789
macd實戰選股公式源碼 瀏覽:644
加密晶元的計算方法 瀏覽:192