sysdig's chisels 是內置的腳本，供使用者來追蹤系統調用或者查看系統的性能瓶頸，它是用強大而且高效的腳本語言Lua寫的。
今天來分享一下fdbytes_by的用法，該案例可以探測到系統的那個文件的I/O佔用最高（不光是file，還可以是network I/O），而且可以查到哪個進程在讀寫該文件，並且可以查看到內核級的I/O活動明細。應用場景可以觀察一下你的文件系統是否是在高效運轉，或者調查一個磁盤I/O延遲的故障。配合dstat --top-io可以更容易定位到進程名字，但是今天介紹的主要是sysdig的fdbytes_by chisel用法，可以想象成沒有dstat工具可用的場景下。
首先我們先來看一下今天的主角fdbytes_by的用法明細：
# sysdig -i fdbytes_by Category: I/O ------------- fdbytes_by I/O bytes, aggregated by an arbitrary filter field Groups FD activity based on the given filter field, and returns the key that ge nerated the most input+output bytes. For example, this script can be used to li st the processes or TCP ports that generated most traffic. Args: [string] key - The filter field used for grouping
答題意思是以文件描述符的各種活動所產生的IO大小來進行排序。
首先我們來抓取30M的sysdig包來用分析使用。
sysdig -w fdbytes_by.scap -C 30
然後我們來分析這次抓包沒個文件描述符對文件系統的I/O活動：
# sysdig -r fdbytes_by.scap0 -c fdbytes_by fd.type Bytes fd.type -------------------------------------------------------------------------------- 45.16M file 9.30M ipv4 87.55KB unix 316B <NA> 60B pipe
可以看到file佔用的45.16M，是最大的FD，然後我們來看一下按目錄的I/O活動來排序：
# sysdig -r fdbytes_by.scap0 -c fdbytes_by fd.directory Bytes fd.directory -------------------------------------------------------------------------------- 38.42M /etc 7.59M / 5.04M /var/www/html 1.38M /var/log/nginx 304.73KB /root/.zsh_history/root 7.31KB /lib/x86_64-linux-gnu 2.82KB /dev 2.76KB /dev/pts 1.62KB /usr/lib/x86_64-linux-gnu
發現訪問最多的是/etc目錄，那我們看一下，具體訪問的是哪個文件呢？
# sysdig -r fdbytes_by.scap0 -c fdbytes_by fd.name fd.directory=/etc Bytes fd.name -------------------------------------------------------------------------------- 38.42M /etc/services
Bingo！找到了，原來是/etc/services被訪問的最多，因爲services是系統文件，所以可以判斷肯定是read的操作達到了38.42M，那我們來看一下哪個進程訪問的此文件呢?
# sysdig -r fdbytes_by.scap0 -c fdbytes_by proc.name "fd.filename=services and fd.directory=/etc" Bytes proc.name -------------------------------------------------------------------------------- 38.42M nscd
找到元兇了，原來是nscd緩存程序，那他爲什麼會讀取這麼多次的services文件呢?在繼續看：
# sysdig -r fdbytes_by.scap0 -A -s 4096 -c echo_fds proc.name=nscd ------ Read 12B from ffff880009dc6900->ffff880009dc6180 /var/run/nscd/socket (nscd) ------ Read 6B from ffff880009dc6900->ffff880009dc6180 /var/run/nscd/socket (nscd) hosts ------ Write 14B to ffff880009dc6900->ffff880009dc6180 /var/run/nscd/socket (nscd) hostsO ------ Read 12B from ffff880009dc6900->ffff880009dc6180 /var/run/nscd/socket (nscd) ------ Read 7B from ffff880009dc6900->ffff880009dc6180 /var/run/nscd/socket (nscd) 28060/ ------ Read 4.00KB from /etc/services (nscd) # Network services, Internet style # # Note that it is presently the policy of I ------ Read 4.00KB from /etc/services (nscd) # IPX ipx213/udp imap3220/tcp# Interactive Mail Access imap3220/udp ------ Read 4.00KB from /etc/services (nscd) nessus1241/tcp# Nessus vulnerability nessus1241/udp# assessment scann ------ Read 4.00KB from /etc/services (nscd) qmaster6444/tcpsge_qmaster# Grid Engine Qmaster Service sge-qmaster6444/udp ------ Read 3.10KB from /etc/services (nscd)
原來是nscd在讀取services中定義的端口跟服務名稱之間的關係，我在抓包的過程中是運行了ab做nginx的靜態頁面壓力測試，本來希望看到的是nginx的讀寫會很高，沒想到中途出現了這個nscd來搗亂：
ab -k -c 2000 -n 300000 http://shanker.heyoa.com/index.html
# sysdig -r fdbytes_by.scap0 -c topprocs_file Bytes Process PID -------------------------------------------------------------------------------- 38.42M nscd 1343 6.43M nginx 4804 304.89KB zsh 32402 9.20KB ab 20774 2.79KB screen 18338 2.37KB sshd 12812
後來我分別測試了一下開啓nscd的情況下ab的測試時間，和不開nscd做緩存的情況下，確實開啓nscd做本地services的緩存會提高10.189%。
ab -k -c 2000 -n 300000 http://shanker.heyoa.com/index.html 0.94s user 2.77s system 9% cpu 38.561 total ab -k -c 2000 -n 300000 http://shanker.heyoa.com/index.html 0.93s user 2.79s system 10% cpu 34.632 total
nscd緩存加速可以參考之前的這篇文章
http://shanker.blog.51cto.com/1189689/1735058
至此，整個分析就結束了，本文只是一個例子，跟大家分享如何使用chisel的fdbytes_by，sysdig還提供了很多chisel共大家分析系統。
歡迎補充！