一、CPU和內(nèi)存類
1.1 top
第一行后面的三個(gè)值是系統(tǒng)在之前 1分鐘赔癌、5分鐘、15分鐘 的平均負(fù)載澜沟，也可以看出系統(tǒng)負(fù)載是上升灾票、平穩(wěn)、下降的趨勢(shì)茫虽，當(dāng)這個(gè)值超過 CPU 邏輯核心數(shù)洋机，則表示 CPU 的性能已經(jīng)飽和成為瓶頸了浑槽。
第二行統(tǒng)計(jì)了系統(tǒng)的任務(wù)狀態(tài)信息占调。
running 很自然不必多說蝌焚，包括正在 CPU 上運(yùn)行的和將要被調(diào)度運(yùn)行的；
sleeping 通常是等待事件(比如 IO 操作)完成的任務(wù)号杏，細(xì)分可以包括 interruptible 和 uninterruptible 的類型婴氮；stopped 是一些被暫停的任務(wù)，通常發(fā)送 SIGSTOP 或者對(duì)一個(gè)前臺(tái)任務(wù)操作 Ctrl-Z 可以將其暫停；
zombie 僵尸任務(wù)主经，雖然進(jìn)程終止資源會(huì)被自動(dòng)回收荣暮，但是含有退出任務(wù)的 task descriptor 需要父進(jìn)程訪問后才能釋放，這種進(jìn)程顯示為 defunct 狀態(tài)罩驻，無論是因?yàn)楦高M(jìn)程提前退出還是未 wait 調(diào)用穗酥，出現(xiàn)這種進(jìn)程都應(yīng)該格外注意程序是否設(shè)計(jì)有誤。
第三行 CPU 占用率根據(jù)類型有以下幾種情況：
(us) user：CPU 在低 nice 值(高優(yōu)先級(jí))用戶態(tài)所占用的時(shí)間(nice<=0)惠遏。正常情況下只要服務(wù)器不是很閑迷扇，那么大部分的 CPU 時(shí)間應(yīng)該都在此執(zhí)行這類程序
(sy) system：CPU 處于內(nèi)核態(tài)所占用的時(shí)間，操作系統(tǒng)通過系統(tǒng)調(diào)用(system call)從用戶態(tài)陷入內(nèi)核態(tài)爽哎，以執(zhí)行特定的服務(wù)；通常情況下該值會(huì)比較小器一，但是當(dāng)服務(wù)器執(zhí)行的 IO 比較密集的時(shí)候课锌，該值會(huì)比較大
(ni) nice：CPU 在高 nice 值(低優(yōu)先級(jí))用戶態(tài)以低優(yōu)先級(jí)運(yùn)行占用的時(shí)間(nice>0)。默認(rèn)新啟動(dòng)的進(jìn)程 nice=0祈秕，是不會(huì)計(jì)入這里的渺贤，除非手動(dòng)通過 renice 或者 setpriority() 的方式修改程序的nice值
(id) idle：CPU 在空閑狀態(tài)(執(zhí)行 kernel idle handler )所占用的時(shí)間
(wa) iowait：等待 IO 完成做占用的時(shí)間
(hi) irq：系統(tǒng)處理硬件中斷所消耗的時(shí)間
(si) softirq：系統(tǒng)處理軟中斷所消耗的時(shí)間，記住軟中斷分為 softirqs请毛、tasklets (其實(shí)是前者的特例)志鞍、work queues，不知道這里是統(tǒng)計(jì)的是哪些的時(shí)間方仿，畢竟 work queues 的執(zhí)行已經(jīng)不是中斷上下文了
(st) steal：在虛擬機(jī)情況下才有意義固棚，因?yàn)樘摂M機(jī)下 CPU 也是共享物理 CPU 的，所以這段時(shí)間表明虛擬機(jī)等待 hypervisor 調(diào)度 CPU 的時(shí)間仙蚜，也意味著這段時(shí)間 hypervisor 將 CPU 調(diào)度給別的 CPU 執(zhí)行此洲，這個(gè)時(shí)段的 CPU 資源被“stolen”了。這個(gè)值在我 KVM 的 VPS 機(jī)器上是不為 0 的委粉，但也只有 0.1 這個(gè)數(shù)量級(jí)呜师，是不是可以用來判斷 VPS 超售的情況？
CPU 占用率高很多情況下意味著一些東西贾节，這也給服務(wù)器 CPU 使用率過高情況下指明了相應(yīng)地排查思路：
當(dāng) user 占用率過高的時(shí)候汁汗，通常是某些個(gè)別的進(jìn)程占用了大量的 CPU，這時(shí)候很容易通過 top 找到該程序栗涂；此時(shí)如果懷疑程序異常知牌，可以通過 perf 等思路找出熱點(diǎn)調(diào)用函數(shù)來進(jìn)一步排查；
當(dāng) system 占用率過高的時(shí)候戴差，如果 IO 操作(包括終端 IO)比較多送爸，可能會(huì)造成這部分的 CPU 占用率高，比如在 file server、database server 等類型的服務(wù)器上袭厂，否則(比如>20%)很可能有些部分的內(nèi)核墨吓、驅(qū)動(dòng)模塊有問題；
當(dāng) nice 占用率過高的時(shí)候纹磺，通常是有意行為帖烘，當(dāng)進(jìn)程的發(fā)起者知道某些進(jìn)程占用較高的 CPU，會(huì)設(shè)置其 nice 值確保不會(huì)淹沒其他進(jìn)程對(duì) CPU 的使用請(qǐng)求橄杨；
當(dāng) iowait 占用率過高的時(shí)候秘症，通常意味著某些程序的 IO 操作效率很低，或者 IO 對(duì)應(yīng)設(shè)備的性能很低以至于讀寫操作需要很長(zhǎng)的時(shí)間來完成式矫；
當(dāng) irq/softirq 占用率過高的時(shí)候乡摹，很可能某些外設(shè)出現(xiàn)問題，導(dǎo)致產(chǎn)生大量的irq請(qǐng)求采转，這時(shí)候通過檢查 /proc/interrupts 文件來深究問題所在聪廉；
當(dāng) steal 占用率過高的時(shí)候，黑心廠商虛擬機(jī)超售了吧故慈！
第四行和第五行是物理內(nèi)存和虛擬內(nèi)存(交換分區(qū))的信息：
total = free + used + buff/cache板熊，現(xiàn)在buffers和cached Mem信息總和到一起了，但是buffers和cached
Mem 的關(guān)系很多地方都沒說清楚察绷。其實(shí)通過對(duì)比數(shù)據(jù)干签，這兩個(gè)值就是 /proc/meminfo 中的 Buffers 和 Cached 字段：Buffers 是針對(duì) raw disk 的塊緩存，主要是以 raw block 的方式緩存文件系統(tǒng)的元數(shù)據(jù)(比如超級(jí)塊信息等)拆撼，這個(gè)值一般比較小(20M左右)容劳；而 Cached 是針對(duì)于某些具體的文件進(jìn)行讀緩存，以增加文件的訪問效率而使用的情萤，可以說是用于文件系統(tǒng)中文件緩存使用鸭蛙。
而 avail Mem 是一個(gè)新的參數(shù)值，用于指示在不進(jìn)行交換的情況下筋岛，可以給新開啟的程序多少內(nèi)存空間娶视，大致和 free + buff/cached 相當(dāng)，而這也印證了上面的說法睁宰，free + buffers + cached Mem才是真正可用的物理內(nèi)存肪获。并且，使用交換分區(qū)不見得是壞事情柒傻，所以交換分區(qū)使用率不是什么嚴(yán)重的參數(shù)孝赫，但是頻繁的 swap in/out 就不是好事情了，這種情況需要注意红符，通常表示物理內(nèi)存緊缺的情況青柄。
最后是每個(gè)程序的資源占用列表伐债，其中 CPU 的使用率是所有 CPU core 占用率的總和。通常執(zhí)行 top 的時(shí)候致开，本身該程序會(huì)大量的讀取 /proc 操作峰锁，所以基本該 top 程序本身也會(huì)是名列前茅的。
top 雖然非常強(qiáng)大双戳，但是通常用于控制臺(tái)實(shí)時(shí)監(jiān)測(cè)系統(tǒng)信息虹蒋，不適合長(zhǎng)時(shí)間(幾天、幾個(gè)月)監(jiān)測(cè)系統(tǒng)的負(fù)載信息飒货，同時(shí)對(duì)于短命的進(jìn)程也會(huì)遺漏無法給出統(tǒng)計(jì)信息魄衅。
1.2 vmstat
vmstat 是除 top 之外另一個(gè)常用的系統(tǒng)檢測(cè)工具，下面截圖是我用-j4編譯boost的系統(tǒng)負(fù)載塘辅。
# vmstat --wide 1 --unit M
procs -----------------------memory---------------------- ---swap-- -----io---- -system-- --------cpu--------
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 304 604 6499 0 0 22 90 13 16 3 1 96 0 0
0 0 0 304 604 6499 0 0 0 48 15475 30540 3 1 96 0 0
0 0 0 304 604 6499 0 0 4 152 14975 29780 2 1 97 0 0
0 0 0 304 604 6499 0 0 108 4 15518 30565 2 1 97 0 0
7 0 0 304 604 6499 0 0 296 24 15401 30405 2 1 97 0 0
1 0 0 304 604 6499 0 0 0 0 15466 30260 3 1 96 0 0
2 0 0 307 604 6499 0 0 4 48 16324 31314 5 2 93 0 0
0 0 0 307 604 6499 0 0 0 592 15272 30274 2 1 97 0 0
2 0 0 307 604 6499 0 0 0 52 15315 30268 3 1 96 0 0
0 0 0 307 604 6499 0 0 0 32 16266 31783 3 1 96 0 0
0 0 0 307 604 6500 0 0 548 20 15627 30461 3 1 96 0 0
0 0 0 307 604 6500 0 0 4 436 16154 31041 3 2 95 0 0
0 0 0 307 604 6500 0 0 8 200 15438 30026 3 2 95 0 0
0 0 0 307 604 6500 0 0 0 4 15473 30542 2 1 97 0 0
r表示可運(yùn)行進(jìn)程數(shù)目晃虫，數(shù)據(jù)大致相符；
b表示的是 uninterruptible 睡眠的進(jìn)程數(shù)目扣墩；
swpd 表示使用到的虛擬內(nèi)存數(shù)量傲茄，跟 top-Swap-used 的數(shù)值是一個(gè)含義，而如手冊(cè)所說沮榜，通常情況下 buffers 數(shù)目要比 cached Mem 小的多，buffers 一般20M這么個(gè)數(shù)量級(jí)喻粹；
io 域的 bi蟆融、bo 表明每秒鐘向磁盤接收和發(fā)送的塊數(shù)目(blocks/s)；
system 域的 in 表明每秒鐘的系統(tǒng)中斷數(shù)(包括時(shí)鐘中斷)守呜，cs表明因?yàn)檫M(jìn)程切換導(dǎo)致上下文切換的數(shù)目型酥。
說到這里，想到以前很多人糾結(jié)編譯 linux kernel 的時(shí)候 -j 參數(shù)究竟是 CPU Core 還是 CPU Core+1查乒？通過上面修改 -j 參數(shù)值編譯 boost 和 linux kernel 的同時(shí)開啟 vmstat 監(jiān)控弥喉，發(fā)現(xiàn)兩種情況下 context switch 基本沒有變化，且也只有顯著增加 -j 值后 context switch 才會(huì)有顯著的增加玛迄，看來不必過于糾結(jié)這個(gè)參數(shù)了由境，雖然具體編譯時(shí)間長(zhǎng)度我還沒有測(cè)試。資料說如果不是在系統(tǒng)啟動(dòng)或者 benchmark 的狀態(tài)蓖议，參數(shù) context switch>100000 程序肯定有問題虏杰。
1.3 pidstat
# pidstat -s -t -p 2901
Linux 5.10.12-1.el7.elrepo.x86_64 (shida-test) 06/30/2022 _x86_64_ (4 CPU)
02:55:49 PM UID TGID TID StkSize StkRef Command
02:55:49 PM 0 2901 - 132 36 java
02:55:49 PM 0 - 2901 132 36 |__java
02:55:49 PM 0 - 2902 132 36 |__java
02:55:49 PM 0 - 2903 132 36 |__java
02:55:49 PM 0 - 2904 132 36 |__java
02:55:49 PM 0 - 2905 132 36 |__java
02:55:49 PM 0 - 2906 132 36 |__java
02:55:49 PM 0 - 2907 132 36 |__java
02:55:49 PM 0 - 2908 132 36 |__java
02:55:49 PM 0 - 2909 132 36 |__java
02:55:49 PM 0 - 2910 132 36 |__java
02:55:49 PM 0 - 2911 132 36 |__java
02:55:49 PM 0 - 2912 132 36 |__java
02:55:49 PM 0 - 2913 132 36 |__java
02:55:49 PM 0 - 2914 132 36 |__java
02:55:49 PM 0 - 2915 132 36 |__java
02:55:49 PM 0 - 2938 132 36 |__java
02:55:49 PM 0 - 2939 132 36 |__java
pidstat -s -t -p pid
如果想對(duì)某個(gè)進(jìn)程進(jìn)行全面具體的追蹤，沒有什么比 pidstat 更合適的了--椑障海空間纺阔、缺頁情況、主被動(dòng)切換等信息盡收眼底修然。這個(gè)命令最有用的參數(shù)是-t笛钝，可以將進(jìn)程中各個(gè)線程的詳細(xì)信息羅列出來质况。
-r：顯示缺頁錯(cuò)誤和內(nèi)存使用狀況，缺頁錯(cuò)誤是程序需要訪問映射在虛擬內(nèi)存空間中但是還尚未被加載到物理內(nèi)存中的一個(gè)分頁玻靡，缺頁錯(cuò)誤兩個(gè)主要類型是
minflt/s 指的 minor faults结榄，當(dāng)需要訪問的物理頁面因?yàn)槟承┰?比如共享頁面、緩存機(jī)制等)已經(jīng)存在于物理內(nèi)存中了啃奴，只是在當(dāng)前進(jìn)程的頁表中沒有引用潭陪，MMU 只需要設(shè)置對(duì)應(yīng)的 entry 就可以了，這個(gè)代價(jià)是相當(dāng)小的
majflt/s 指的 major faults最蕾，MMU 需要在當(dāng)前可用物理內(nèi)存中申請(qǐng)一塊空閑的物理頁面(如果沒有可用的空閑頁面依溯，則需要將別的物理頁面切換到交換空間去以釋放得到空閑物理頁面)，然后從外部加載數(shù)據(jù)到該物理頁面中瘟则，并設(shè)置好對(duì)應(yīng)的 entry黎炉，這個(gè)代價(jià)是相當(dāng)高的，和前者有幾個(gè)數(shù)據(jù)級(jí)的差異
-s：棧使用狀況醋拧，包括 StkSize 為線程保留的椏妒龋空間，以及 StkRef 實(shí)際使用的椀ず荆空間庆械。使用ulimit -s發(fā)現(xiàn)CentOS 6.x上面默認(rèn)棧空間是10240K菌赖，而 CentOS 7.x缭乘、Ubuntu系列默認(rèn)棧空間大小為8196K
-u：CPU使用率情況琉用，參數(shù)同前面類似
-w：線程上下文切換的數(shù)目堕绩，還細(xì)分為cswch/s因?yàn)榈却Y源等因素導(dǎo)致的主動(dòng)切換，以及nvcswch/s線程CPU時(shí)間導(dǎo)致的被動(dòng)切換的統(tǒng)計(jì)
如果每次都先ps得到程序的pid后再操作pidstat會(huì)顯得很麻煩邑时，所以這個(gè)殺手锏的-C可以指定某個(gè)字符串奴紧，然后Command中如果包含這個(gè)字符串，那么該程序的信息就會(huì)被打印統(tǒng)計(jì)出來晶丘，-l可以顯示完整的程序名和參數(shù)
pidstat -w -t -C “ailaw” -l
這么看來黍氮，如果查看單個(gè)尤其是多線程的任務(wù)時(shí)候，pidstat比常用的ps更好使浅浮！
1.4其他
當(dāng)需要單獨(dú)監(jiān)測(cè)單個(gè) CPU 情況的時(shí)候滤钱，除了 htop 還可以使用 mpstat，查看在 SMP 處理器上各個(gè) Core 的工作量是否負(fù)載均衡脑题，是否有某些熱點(diǎn)線程占用 Core件缸。
# mpstat -P ALL 1
Linux 5.10.12-1.el7.elrepo.x86_64 (shida-test) 06/30/2022 _x86_64_ (4 CPU)
03:05:12 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
03:05:13 PM all 2.86 0.00 1.04 0.00 0.00 0.00 0.00 0.00 0.00 96.10
03:05:13 PM 0 3.12 0.00 1.04 0.00 0.00 0.00 0.00 0.00 0.00 95.83
03:05:13 PM 1 2.08 0.00 1.04 0.00 0.00 0.00 0.00 0.00 0.00 96.88
03:05:13 PM 2 4.12 0.00 1.03 0.00 0.00 0.00 0.00 0.00 0.00 94.85
03:05:13 PM 3 3.09 0.00 1.03 0.00 0.00 0.00 0.00 0.00 0.00 95.88
如果想直接監(jiān)測(cè)某個(gè)進(jìn)程占用的資源，既可以使用top -u taozj的方式過濾掉其他用戶無關(guān)進(jìn)程叔遂，也可以采用下面的方式進(jìn)行選擇他炊，ps命令可以自定義需要打印的條目信息：
while :; do ps -eo user,pid,ni,pri,pcpu,psr,comm | grep 'ailawd'; sleep 1; done
如想理清繼承關(guān)系争剿，下面一個(gè)常用的參數(shù)可以用于顯示進(jìn)程樹結(jié)構(gòu)，顯示效果比pstree詳細(xì)美觀的多
ps axjf
二痊末、磁盤IO類
1蚕苇、iotop 可以直觀的顯示各個(gè)進(jìn)程、線程的磁盤讀取實(shí)時(shí)速率凿叠；
lsof 不僅可以顯示普通文件的打開信息(使用者)涩笤，還可以操作 /dev/sda1 這類設(shè)備文件的打開信息，那么比如當(dāng)分區(qū)無法 umount 的時(shí)候盒件，就可以通過 lsof 找出磁盤該分區(qū)的使用狀態(tài)了蹬碧，而且添加 +fg 參數(shù)還可以額外顯示文件打開 flag 標(biāo)記。
2.1iostat
# iostat -xz 1
Linux 5.10.12-1.el7.elrepo.x86_64 (shida-test) 06/30/2022 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
5.41 0.00 2.58 7.22 0.00 84.79
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 35.00 0.00 331.00 0.00 39916.00 241.18 14.39 43.47 0.00 43.47 0.90 29.70
vdb 0.00 1.00 0.00 3.00 0.00 16.00 10.67 0.00 0.33 0.00 0.33 1.00 0.30
vdc 0.00 0.00 25.00 13.00 1464.00 52.00 79.79 0.06 1.47 1.96 0.54 0.24 0.90
其實(shí)無論使用 iostat -xz 1 還是使用 sar -d 1炒刁，對(duì)于磁盤重要的參數(shù)是：
avgqu-s：發(fā)送給設(shè)備 I/O 請(qǐng)求的等待隊(duì)列平均長(zhǎng)度恩沽，對(duì)于單個(gè)磁盤如果值>1表明設(shè)備飽和，對(duì)于多個(gè)磁盤陣列的邏輯磁盤情況除外
await(r_await翔始、w_await)：平均每次設(shè)備 I/O 請(qǐng)求操作的等待時(shí)間(ms)罗心，包含請(qǐng)求排列在隊(duì)列中和被服務(wù)的時(shí)間之和；
svctm：發(fā)送給設(shè)備 I/O 請(qǐng)求的平均服務(wù)時(shí)間(ms)城瞎，如果 svctm 與 await 很接近渤闷，表示幾乎沒有 I/O 等待，磁盤性能很好脖镀，否則磁盤隊(duì)列等待時(shí)間較長(zhǎng)肤晓，磁盤響應(yīng)較差；
%util：設(shè)備的使用率认然，表明每秒中用于 I/O 工作時(shí)間的占比，單個(gè)磁盤當(dāng) %util>60% 的時(shí)候性能就會(huì)下降(體現(xiàn)在 await 也會(huì)增加)漫萄，當(dāng)接近100%時(shí)候就設(shè)備飽和了卷员，但對(duì)于有多個(gè)磁盤陣列的邏輯磁盤情況除外；
還有腾务，雖然監(jiān)測(cè)到的磁盤性能比較差毕骡，但是不一定會(huì)對(duì)應(yīng)用程序的響應(yīng)造成影響，內(nèi)核通常使用 I/O asynchronously 技術(shù)岩瘦，使用讀寫緩存技術(shù)來改善性能未巫，不過這又跟上面的物理內(nèi)存的限制相制約了。
上面的這些參數(shù)启昧，對(duì)網(wǎng)絡(luò)文件系統(tǒng)也是受用的叙凡。
三、網(wǎng)絡(luò)類
網(wǎng)絡(luò)性能對(duì)于服務(wù)器的重要性不言而喻密末，工具 iptraf 可以直觀的顯示網(wǎng)卡的收發(fā)速度信息握爷，比較的簡(jiǎn)潔方便通過 sar -n DEV 1 也可以得到類似的吞吐量信息跛璧，而網(wǎng)卡都標(biāo)配了最大速率信息，比如百兆網(wǎng)卡千兆網(wǎng)卡新啼，很容易查看設(shè)備的利用率追城。
通常，網(wǎng)卡的傳輸速率并不是網(wǎng)絡(luò)開發(fā)中最為關(guān)切的燥撞，而是針對(duì)特定的 UDP座柱、TCP 連接的丟包率、重傳率物舒，以及網(wǎng)絡(luò)延時(shí)等信息色洞。
3.1 netstat
netstat -s
顯示自從系統(tǒng)啟動(dòng)以來，各個(gè)協(xié)議的總體數(shù)據(jù)信息茶鉴。雖然參數(shù)信息比較豐富有用锋玲，但是累計(jì)值，除非兩次運(yùn)行做差才能得出當(dāng)前系統(tǒng)的網(wǎng)絡(luò)狀態(tài)信息涵叮，亦或者使用 watch 眼睛直觀其數(shù)值變化趨勢(shì)惭蹂。所以netstat通常用來檢測(cè)端口和連接信息的：
netstat –all(a) –numeric(n) –tcp(t) –udp(u) –timers(o) –listening(l) –program(p)
–timers可以取消域名反向查詢，加快顯示速度割粮；比較常用的有
netstat -antp #列出所有TCP的連接
netstat -nltp #列出本地所有TCP偵聽套接字盾碗，不要加-a參數(shù)
# netstat -nltp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:33001 0.0.0.0:* LISTEN 7284/java
tcp 0 0 172.26.189.214:27017 0.0.0.0:* LISTEN 2204/mongod
tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN 2204/mongod
tcp 0 0 0.0.0.0:33002 0.0.0.0:* LISTEN 28467/java
tcp 0 0 0.0.0.0:9066 0.0.0.0:* LISTEN 11021/java
tcp 0 0 0.0.0.0:11211 0.0.0.0:* LISTEN 2360/memcached
tcp 0 0 0.0.0.0:9901 0.0.0.0:* LISTEN 14181/java
tcp 0 0 0.0.0.0:3309 0.0.0.0:* LISTEN 1981/mysqld
tcp 0 0 0.0.0.0:30030 0.0.0.0:* LISTEN 28467/java
tcp 0 0 0.0.0.0:9902 0.0.0.0:* LISTEN 14079/java
tcp 0 0 0.0.0.0:9903 0.0.0.0:* LISTEN 31267/java
tcp 0 0 0.0.0.0:9999 0.0.0.0:* LISTEN 10935/java
tcp 0 0 0.0.0.0:8719 0.0.0.0:* LISTEN 5952/java
tcp 0 0 0.0.0.0:9103 0.0.0.0:* LISTEN 3395/java
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 608/rpcbind
tcp 0 0 0.0.0.0:9904 0.0.0.0:* LISTEN 13698/java
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 11728/nginx: master
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 13844/java
tcp 0 0 0.0.0.0:8720 0.0.0.0:* LISTEN 7113/java
tcp 0 0 0.0.0.0:30000 0.0.0.0:* LISTEN 6537/java
tcp 0 0 0.0.0.0:20880 0.0.0.0:* LISTEN 3395/java
tcp 0 0 0.0.0.0:8848 0.0.0.0:* LISTEN 2901/java
tcp 0 0 0.0.0.0:9905 0.0.0.0:* LISTEN 31749/java
tcp 0 0 0.0.0.0:9105 0.0.0.0:* LISTEN 3444/java
tcp 0 0 0.0.0.0:20881 0.0.0.0:* LISTEN 3444/java
tcp 0 0 0.0.0.0:4369 0.0.0.0:* LISTEN 2295/epmd
tcp 0 0 0.0.0.0:9906 0.0.0.0:* LISTEN 32398/java
tcp 0 0 0.0.0.0:9106 0.0.0.0:* LISTEN 3502/java
tcp 0 0 0.0.0.0:20882 0.0.0.0:* LISTEN 3502/java
tcp 0 0 0.0.0.0:56722 0.0.0.0:* LISTEN 947/beam.smp
tcp 0 0 0.0.0.0:30002 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:9907 0.0.0.0:* LISTEN 32547/java
tcp 0 0 0.0.0.0:20883 0.0.0.0:* LISTEN 31267/java
tcp 0 0 0.0.0.0:8083 0.0.0.0:* LISTEN 7901/java
tcp 0 0 0.0.0.0:30003 0.0.0.0:* LISTEN 1026/rpc.mountd
tcp 0 0 0.0.0.0:9908 0.0.0.0:* LISTEN 869/java
tcp 0 0 0.0.0.0:20884 0.0.0.0:* LISTEN 31749/java
tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN 1023/rpc.statd
tcp 0 0 0.0.0.0:9909 0.0.0.0:* LISTEN 1649/java
tcp 0 0 0.0.0.0:20885 0.0.0.0:* LISTEN 32398/java
tcp 0 0 0.0.0.0:20886 0.0.0.0:* LISTEN 32547/java
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2182/sshd
tcp 0 0 0.0.0.0:20887 0.0.0.0:* LISTEN 869/java
tcp 0 0 0.0.0.0:8087 0.0.0.0:* LISTEN 13255/java
tcp 0 0 0.0.0.0:20888 0.0.0.0:* LISTEN 13698/java
tcp 0 0 0.0.0.0:30040 0.0.0.0:* LISTEN 7113/java
tcp 0 0 0.0.0.0:20889 0.0.0.0:* LISTEN 14079/java
tcp 0 0 0.0.0.0:20890 0.0.0.0:* LISTEN 1649/java
tcp 0 0 0.0.0.0:30010 0.0.0.0:* LISTEN 6811/java
tcp 0 0 0.0.0.0:8090 0.0.0.0:* LISTEN 5952/java
tcp 0 0 0.0.0.0:19898 0.0.0.0:* LISTEN 2356/redis-server *
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 11728/nginx: master
3.2 sar
sar 這個(gè)工具太強(qiáng)大了，什么 CPU舀瓢、磁盤廷雅、頁面交換啥都管，這里使用 -n 主要用來分析網(wǎng)絡(luò)活動(dòng)京髓，雖然網(wǎng)絡(luò)中它還給細(xì)分了 NFS航缀、IP、ICMP堰怨、SOCK 等各種層次各種協(xié)議的數(shù)據(jù)信息芥玉，我們只關(guān)心 TCP 和 UDP。下面的命令除了顯示常規(guī)情況下段备图、數(shù)據(jù)報(bào)的收發(fā)情況灿巧，還包括TCP
sar -n TCP，ETCP 1
# sar -n TCP,ETCP 1
Linux 5.10.12-1.el7.elrepo.x86_64 (shida-test) 06/30/2022 _x86_64_ (4 CPU)
03:33:16 PM active/s passive/s iseg/s oseg/s
03:33:17 PM 5.00 8.00 753.00 659.00
03:33:16 PM atmptf/s estres/s retrans/s isegerr/s orsts/s
03:33:17 PM 0.00 6.00 0.00 0.00 3.00
03:33:17 PM active/s passive/s iseg/s oseg/s
03:33:18 PM 4.00 6.00 786.00 689.00
03:33:17 PM atmptf/s estres/s retrans/s isegerr/s orsts/s
03:33:18 PM 0.00 6.00 0.00 0.00 3.00
active/s：本地發(fā)起的 TCP 連接揽涮，比如通過 connect()抠藕，TCP 的狀態(tài)從CLOSED -> SYN-SENT
passive/s：由遠(yuǎn)程發(fā)起的 TCP 連接，比如通過 accept()蒋困，TCP 的狀態(tài)從LISTEN -> SYN-RCVD
retrans/s(tcpRetransSegs)：每秒鐘 TCP 重傳數(shù)目盾似，通常在網(wǎng)絡(luò)質(zhì)量差，或者服務(wù)器過載后丟包的情況下雪标，根據(jù) TCP 的確認(rèn)重傳機(jī)制會(huì)發(fā)生重傳操作
isegerr/s(tcpInErrs)：每秒鐘接收到出錯(cuò)的數(shù)據(jù)包(比如 checksum 失敗)
UDP
# sar -n UDP 1
Linux 5.10.12-1.el7.elrepo.x86_64 (shida-test) 06/30/2022 _x86_64_ (4 CPU)
03:36:22 PM idgm/s odgm/s noport/s idgmerr/s
03:36:23 PM 0.00 0.00 0.00 0.00
03:36:24 PM 0.00 0.00 0.00 0.00
03:36:25 PM 0.00 0.00 0.00 0.00
03:36:26 PM 2.00 2.00 0.00 0.00
03:36:27 PM 0.00 0.00 0.00 0.00
noport/s(udpNoPorts)：每秒鐘接收到的但是卻沒有應(yīng)用程序在指定目的端口的數(shù)據(jù)報(bào)個(gè)數(shù)
idgmerr/s(udpInErrors)：除了上面原因之外的本機(jī)接收到但卻無法派發(fā)的數(shù)據(jù)報(bào)個(gè)數(shù)
當(dāng)然颜说，這些數(shù)據(jù)一定程度上可以說明網(wǎng)絡(luò)可靠性购岗，但也只有同具體的業(yè)務(wù)需求場(chǎng)景結(jié)合起來才具有意義。
3.3 tcpdump
tcpdump 不得不說是個(gè)好東西门粪。大家都知道本地調(diào)試的時(shí)候喜歡使用 wireshark喊积，但是線上服務(wù)端出現(xiàn)問題怎么弄呢？
附錄的參考文獻(xiàn)給出了思路：復(fù)原環(huán)境玄妈，使用 tcpdump 進(jìn)行抓包乾吻，當(dāng)問題復(fù)現(xiàn)(比如日志顯示或者某個(gè)狀態(tài)顯現(xiàn))的時(shí)候，就可以結(jié)束抓包了拟蜻，而且 tcpdump 本身帶有 -C/-W 參數(shù)绎签，可以限制抓取包存儲(chǔ)文件的大小，當(dāng)達(dá)到這個(gè)這個(gè)限制的時(shí)候保存的包數(shù)據(jù)自動(dòng) rotate酝锅，所以抓包數(shù)量總體還是可控的诡必。此后將數(shù)據(jù)包拿下線來，用 wireshark 想怎么看就怎么看搔扁，豈不樂哉爸舒！tcpdump 雖然沒有 GUI 界面，但是抓包的功能絲毫不弱稿蹲，可以指定網(wǎng)卡扭勉、主機(jī)、端口苛聘、協(xié)議等各項(xiàng)過濾參數(shù)涂炎，抓下來的包完整又帶有時(shí)間戳，所以線上程序的數(shù)據(jù)包分析也可以這么簡(jiǎn)單设哗。
下面就是一個(gè)小的測(cè)試唱捣，可見 Chrome 啟動(dòng)時(shí)候自動(dòng)向 Webserver 發(fā)起建立了三條連接，由于這里限制了 dst port 參數(shù)网梢，所以服務(wù)端的應(yīng)答包被過濾掉了震缭，拿下來用 wireshark 打開，SYNC澎粟、ACK 建立連接的過程還是很明顯的！在使用 tcpdump 的時(shí)候欢瞪，需要盡可能的配置抓取的過濾條件活烙，一方面便于接下來的分析，二則 tcpdump 開啟后對(duì)網(wǎng)卡和系統(tǒng)的性能會(huì)有影響遣鼓，進(jìn)而會(huì)影響到在線業(yè)務(wù)的性能啸盏。
轉(zhuǎn)載自：https://mp.weixin.qq.com/s/hUZfilMmFlwKoWMtyYo_-w
