系統技術非業餘研究 » Linux下誰在切換我們的程序
我們在做Linux伺服器的時候經常會需要知道誰在做程序切換,什麼原因需要做程序切換。 因為程序切換的代價很高,我給出一個LMbench測試出來的數字:
Context switching – times in microseconds – smaller is better
————————————————————————-
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
——— ————- —— —— —— —— —— ——- ——-
my174.cm4 Linux 2.6.18- 6.1100 7.0200 6.1100 8.7400 7.7200 8.96000 9.62000
在我的很高階的伺服器上,程序切換的開銷在8us左右, 這個相對於高效能的伺服器是不可接受的, 所以我們要在一個時間片內儘可能的多做事情,而不是把時間浪費在無謂的切換上。
好奇害死貓,我們來調查下誰在切換我們的程序:
[[email protected] admin]# dstat 1 ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 0 0 100 0 0 0| 0 0 | 796B 1488B| 0 0 |1004 128 0 0 100 0 0 0| 0 0 | 280B 728B| 0 0 |1005 114 0 0 100 0 0 0| 0 0 | 280B 728B| 0 0 |1005 128 0 0 100 0 0 0| 0 0 | 280B 728B| 0 0 |1005 114 0 0 100 0 0 0| 0 320k| 280B 728B| 0 0 |1008 143 ...
我們可以看到 csw的數目是 120/S, 但是dstat或者vmstat類似的工具並沒有告訴我們誰在幹壞事。好吧!我們自己動手行吧。
祭出我們可愛的systemtap!
[[email protected] admin]# cat >cswmon.stp #! /usr/bin/env stap # # global csw_count global idle_count probe scheduler.cpu_off { csw_count[task_prev, task_next]++ idle_count+=idle } function fmt_task(task_prev, task_next) { return sprintf("%s(%d)->%s(%d)", task_execname(task_prev), task_pid(task_prev), task_execname(task_next), task_pid(task_next)) } function print_cswtop () { printf ("%45s %10s\n", "Context switch", "COUNT") foreach ([task_prev, task_next] in csw_count- limit 20) { printf("%45s %10d\n", fmt_task(task_prev, task_next), csw_count[task_prev, task_next]) } printf("%45s %10d\n", "idle", idle_count) delete csw_count delete idle_count } probe timer.s($1) { print_cswtop () printf("--------------------------------------------------------------\n") } CTRL+D
這個指令碼會每隔設定的時間打印出TOP 20切換最多的程序和他的pid, 我們來看下結果把:
[[email protected] admin]# stap cswmon.stp 5 Context switch COUNT swapper(0)->systemtap/11(908) 500 systemtap/11(908)->swapper(0) 498 swapper(0)->fct1-worker(2492) 50 fct1-worker(2492)->swapper(0) 50 swapper(0)->fct0-worker(2191) 50 fct0-worker(2191)->swapper(0) 50 swapper(0)->bond0(3432) 50 bond0(3432)->swapper(0) 50 stapio(879)->swapper(0) 26 swapper(0)->stapio(879) 25 stapio(879)->swapper(0) 19 swapper(0)->stapio(879) 17 swapper(0)->watchdog/9(31) 5 watchdog/9(31)->swapper(0) 5 swapper(0)->mysqld(18346) 5 mysqld(18346)->swapper(0) 5 swapper(0)->watchdog/13(43) 5 watchdog/13(43)->swapper(0) 5 swapper(0)->watchdog/14(46) 5 watchdog/14(46)->swapper(0) 5 idle 859 -------------------------------------------------------------- ...
我們可以看到程序從哪裡切換到哪裡,並且發生了多少次, 最後一行,我打印出來idle的次數,也就是說這時候系統沒啥事情做,就切換到idle(0)這個程序去休息去了。
通過上面的調查,我們會很清楚的瞭解到我們系統的開銷發生在那裡,方便我們定位問題。
玩的開心!
Post Footer automatically generated by wp-posturl plugin for wordpress.
No related posts.
相關推薦
系統技術非業餘研究 » Linux下誰在消耗我們的cache
Linux下對檔案的訪問和裝置的訪問通常會被cache起來加快訪問速度,這個是系統的預設行為。 而cache需要耗費我們的記憶體,雖然這個記憶體最後可以通過echo 3>/proc/sys/vm/drop_caches這樣的命令來主動釋放。但是有時候我們還是需要理解誰消耗了我們的記憶體。 我
系統技術非業餘研究 » Linux下誰在切換我們的程序
我們在做Linux伺服器的時候經常會需要知道誰在做程序切換,什麼原因需要做程序切換。 因為程序切換的代價很高,我給出一個LMbench測試出來的數字: Context switching – times in microseconds – smaller is better ———————————
系統技術非業餘研究 » Linux下新系統呼叫sync_file_range
我們在做資料庫程式或者IO密集型的程式的時候,通常在更新的時候,比如說資料庫程式,希望更新有一定的安全性,我們會在更新操作結束的時候呼叫fsync或者fdatasync來flush資料到持久裝置去。而且通常是以頁面為單位,16K一次或者4K一次。 安全性保證了,但是效能就有很大的損害。而且我們更新
系統技術非業餘研究 » Linux下方便的socket讀寫檢視器(socktop)
晚上 雕樑 說要找個工具來調查下unix域套接字的傳送和接受情況,比如說A程式是否送出,B程式是否接收到,他找了tcpdump ,wireshark什麼的,貌似都不支援。 這時候還是偉大的systemtap來救助了。 因為所有的socket通訊都是通過socket介面來的,任何family的通訊
系統技術非業餘研究 » Linux下pstack的實現
Linux下有時候我們需要知道一個程序在做什麼,比如說程式不正常的時候,他到底在幹嗎?最直接的方法就是打印出他所有執行緒的呼叫棧,這樣我們從棧再配合程式程式碼就知道程式在幹嗎了。 Linux下這個工具叫做pstack. 使用方法是 # pstack Usage: pstack <proce
系統技術非業餘研究 » Linux下試驗大頁面對映(MAP_HUGETLB)
Linux對大頁面記憶體的引入對減少TLB的失效效果不錯,特別是記憶體大而密集型的程式,比如說在資料庫中的使用。innodb引擎就支援大頁面記憶體,具體使用可參見 這裡。 大頁面更詳細的資料可以參考: Documentation/vm/hugetlbpage.txt 過去使用大頁面記憶體主要透過h
系統技術非業餘研究 » Linux下非同步IO(libaio)的使用以及效能
Linux下非同步IO是比較新的核心裡面才有的,非同步io的好處可以參考這裡. 但是文章中aio_*系列的呼叫是glibc提供的,是glibc用執行緒+阻塞呼叫來模擬的,效能很差,千萬千萬不要用。 我們今天要說的是真正的原生的非同步IO介面. 由於這幾個系統呼叫glibc沒有提供相應的封裝,所以l
系統技術非業餘研究 » Linux下Fio和Blktrace模擬塊裝置的訪問模式
我們在做塊裝置調優的時候, 我們關心的是塊裝置是如何被訪問的,也就是訪問模式(比如說每次從什麼地方讀,每次讀多少塊,熱點在哪裡等),至於每次讀寫的什麼資料我們並不關心. 這些模式當然可以自己去構造,但是如果能把真實應用的訪問模式記錄下來,並且在調優的時候能重放,我們就可以一遍又一遍的除錯直到達到最
系統技術非業餘研究 » Linux下方便的塊裝置檢視工具lsblk
之前在Linux下看有什麼塊裝置,通常都用fdisk什麼的或者直接ls /dev/ 人肉去看看, 很土,不方便。 前二天在江楓的網站上看到了介紹的lsblk,這玩意不錯,推薦給大家。 這個工具屬於util-linux-ng包,在RHEL 6.1上是安裝好的啦,直接用就好。 ubuntu高版本下也有
系統技術非業餘研究 » Linux下pipe使用注意事項
Linux下的pipe使用非常廣泛, shell本身就大量用pipe來粘合生產者和消費者的. 我們的伺服器程式通常會用pipe來做執行緒間的ipc通訊. 由於unix下的任何東西都是檔案,只要是檔案,在讀取的時候,,就會設定last access time, 所以pipe也不例外., 但是這個時間
系統技術非業餘研究 » Linux下如何知道檔案被那個程序寫
晚上朔海同學問: 一個檔案正在被程序寫 我想檢視這個程序 檔案一直在增大 找不到誰在寫 使用lsof也沒找到 這個問題挺有普遍性的,解決方法應該很多,這裡我給大家提個比較直觀的方法。 linux下每個檔案都會在某個塊裝置上存放,當然也都有相應的inode, 那麼透過vfs.write我們就可以知道
系統技術非業餘研究 » Linux檔案預讀分析以及評估對系統的影響
Linux系統很重要的一個性能提升點就是它的Pagecache, 因為記憶體比IO快太多了,所以大家都想進辦法來利用這個cache。 檔案系統也不例外,為了達到高效能,檔案讀取通常採用預讀來預測使用者的行為,把使用者可能需要的資料預先讀取到cache去,達到高效能的目的。 Linux各個發行版re
系統技術非業餘研究 » Linux快取記憶體使用率調查
Linux的快取記憶體pagecache對效能的影響至關重要,但是實際系統中我們的利用率如何呢,特別是具體到每個裝置的利用情況。 從下圖我們可以很清楚的看到: 我們知道IO請求由vfs發起,經過pagecache快取,擋不住的就落實到io裝置去,那麼統計這個利用率就很簡單。 我們只要知道擋不住的
系統技術非業餘研究 » Linux系統記憶體相關資訊獲取
大型的伺服器,特別是資料庫伺服器的主要瓶頸主要在記憶體,CPU,以及IO上。CPU是可再生資源,不夠用等等就有了;記憶體和土地一樣是不可再生資源,被佔用了,後續的使用必須等到該資源釋放.而IO也非常依賴於記憶體的使用情況,故記憶體的倒騰效率會大大影響伺服器的效率,那麼瞭解伺服器記憶體的使用情況就非
系統技術非業餘研究 » Linux 2.6.38 User
Linux核心裡面自帶非常多的加密模組,這是模組經過調優效能非常高, 而且現在又很多硬體本身支援加密功能,比如intel的CPU支援AES加密指令,那些核心的那幫人知道更好如何利用這些硬體更快的完成加密功能的, 他們寫的這些硬體的驅動在drivers/crypto目錄裡. 所以如果我們能在使用者
系統技術非業餘研究 » Linux IO協議棧框圖
這張圖很清晰的把linux IO協議棧的層次給勾出來了,而且內容很與時俱進,特別是SCSI裝置的層次對大家理解sg3這樣的包非常有幫助,強烈推薦大家好好研習! 祝玩得開心! Post Footer automatically generated by wp-posturl plugin fo
系統技術非業餘研究 » Linux TASK_IO_ACCOUNTING功能以及如何使用
在過去我們瞭解系統IO的情況大多數是通過iostat來獲取的,這個粒度只能精確到每個裝置。通常我們會想了解每個程序,執行緒層面發起了多少IO,在Linux 2.6.20之前除了用systemtap這樣的工具來實現是沒有其他方法的,因為系統沒有暴露這方面的統計。 disktop per裝置per應用
系統技術非業餘研究 » Linux Used記憶體到底哪裡去了?
前幾天 純上 同學問了一個問題: 我ps aux看到的RSS記憶體只有不到30M,但是free看到記憶體卻已經使用了7,8G了,已經開始swap了,請問ps aux的實際實體記憶體統計是不是漏了哪些記憶體沒算?我有什麼辦法確定free中used的記憶體都去哪兒了呢? 這個問題不止一個同學遇到過了
系統技術非業餘研究 » Linux常用效能調優工具索引
霸爺您好,麻煩請教個問題,我們最近一個專案上有個奇怪的問題,基於實時linux系統,兩個實時執行緒通過mq_send傳送訊息,A發訊息給B,是非阻塞的訊息佇列,A傳送訊息B進行處理,A傳送訊息後發現mq_send的開銷與B對該訊息的處理時延相關,也就是說B處理的快,那麼A呼叫的mq_send返回
系統技術非業餘研究 » 網路棧記憶體不足引發程序掛起問題
我們知道TCP socket有傳送緩衝區和接收緩衝區,這二個緩衝區都可以透過setsockopt設定SO_SNDBUF,SO_RCVBUF來修改,但是這些值設多大呢?這些值和協議棧的記憶體控制相關的值什麼關係呢? 我們來解釋下: $ sysctl net|grep mem net.core.wme