摘要
繼續補充假期落下的內容.
其實有很多知識需要學習, 自己掌握的還是偏少一些.
bcc的全貌
# 注意 bcc 需要較高的內核. 3.10 系列的內核基本不可用.
argdist drsnoop mdflush pythonstat tclstat
bashreadline execsnoop memleak readahead tcpaccept
bindsnoop exitsnoop mountsnoop reset-trace tcpcong
biolatency ext4dist mysqld_qslower rubycalls tcpconnect
biolatpcts ext4slower netqtop rubyflow tcpconnlat
biopattern filelife netqtop.c rubygc tcpdrop
biosnoop fileslower nfsdist rubyobjnew tcplife
biotop filetop nfsslower rubystat tcpretrans
bitesize funccount nodegc runqlat tcprtt
bpflist funcinterval nodestat runqlen tcpstates
cachestat funclatency offcputime runqslower tcpsubnet
cachetop funcslower offwaketime shmsnoop tcpsynbl
capable gethostlatency oomkill slabratetop tcptop
cobjnew hardirqs opensnoop sofdsnoop tcptracer
compactsnoop javacalls perlcalls softirqs threadsnoop
cpudist javaflow perlflow solisten tplist
cpuunclaimed javagc perlstat sslsniff trace
dbslower javaobjnew phpcalls stackcount ttysnoop
dbstat javastat phpflow statsnoop vfscount
dcsnoop javathreads phpstat swapin vfsstat
dcstat killsnoop pidpersec syncsnoop virtiostat
deadlock klockstat profile syscount wakeuptime
deadlock.c kvmexit pythoncalls tclcalls xfsdist
dirtop pythonflow tclflow xfsslower tclobjnew
llcstat pythongc
本次總結來源
計劃基於51cto的文檔進行學習和總結工作
博客地址爲:
https://blog.51cto.com/hongchen99/5840053
https://blog.51cto.com/hongchen99/5845370
https://blog.51cto.com/hongchen99/5868472
原作者寫的非常經典. 我這裏想着邊學習變總結一下.
希望能夠窺探一二.
第一部分: CPU
CPU是馮諾依曼計算機體系結果的核心.
CPU性能的好壞決定了系統的併發承載能力和響應時間.
很多問題都是通過CPU的佔用情況進行暴露的.
所以感覺性能調優的第一部分應該是從CPU佔用量着手
根據CPU的使用情況慢慢的向內存和IO深入分析.
CPU性能問題的來源
除去非常孱弱的部分國產CPU
大部分情況下物理機器的CPU都很難單獨成爲性能瓶頸.
如果是無法用到全部核心的單線程模式:
Redis的核心進程, 數據庫/操作系統/中間件因爲序列號導致只能夠使用單一核心
如上情況下可能會出現CPU的瓶頸.
CPU的核心參數主要有:
主頻, IPC , CPI , 內存帶寬, 緩存大小, 指令集, 流水線等.
CPU性能監測工具-傳統
命令 |
內容 |
uptime |
展示系統平均負載和系統運行時間 |
top |
按進程展示系統資源使用情況- 之前總結過 |
mpstat |
按每個 CPU 展示 CPU 使用情況 |
vmstat |
系統整體資源使用情況 |
pidstat |
按進程展示 CPU 使用情況 |
perf |
定時採樣調用棧信息、事件統計、PMC 跟蹤、跟蹤點、USDT probes、kprobes 以及 uprobes 等 |
ftrace |
彙報內核函數調用統計、kprobes 和 uprobes 事件跟蹤 |
bcc相關CPU監控工具
命令 |
內容 |
execsnoop |
列出新進程的運行信息 |
exitsnoop |
列出進程運行時長和退出原因 |
runqlat |
統計 CPU 運行隊列的延遲信息 |
runqlen |
統計 CPU 運行隊列的長度 |
runqslower |
當運行隊列中等待時長超過閾值時打印 |
cpudist |
統計在 CPU 上運行的時間 |
profile |
採樣 CPU 運行的調用棧信息 |
命令 |
內容 |
offcputime |
統計線程脫離 CPU 時的跟蹤信息和等待時常 |
syscount |
按類型和進程統計系統調用次數 |
argdist |
可以用來進行系統調用分析 |
trace |
可以用來進行系統調用分析 |
funccount |
統計函數調用次數 |
softirqs |
統計軟中斷時間 |
hardirqs |
統計硬中斷時間 |
llcstat |
按進程統計 LLC 命中率 |
簡單總結
CPU的運行時間其實分爲 多種
內核態 用戶態 等待io 等.
如果idle的時間較少, 一般就會存在比較嚴重的性能問題.
CPU優化的核心目標是減少 中斷和切換, 將最多的時間用於處理業務代碼
CPU的上下文切換有多種
上下文切換的核心本質是. 核心態執行代碼用來替換正在運行的用戶態的程序.
進程的上下文切換 需要刷新TLB, 保存所有的寄存器狀態,然後刷入要載入進程的寄存器等信息.
根據CPU的不同 進程切換的時間不一樣. 一般的理解需要 1500-3000個cycle纔可以.
所以理論上切換進程的時間有 1.5微秒甚至更高.
對應的還有線程上下文切換, 不需要切換TLB等頁表信息. 切換效率較高.
但是爲了高併發下的性能, 優化方向是協程的機制.
不需要上下文切換. 需要用戶態管理協程的上下文. 效率最高. 也是java最新版的一個特性.
中斷的機制
中斷是系統實現交互的核心設計方式
主要有軟中斷和硬中斷.
鍵盤和硬盤以及網卡都可以實現中斷.
中斷用於保證系統暫時放棄正在處理的工作. 加急處理輸入輸出相關的信息.
對應的RT內核和非RT內核也是對中斷的搶佔模式的區別
實時內核需要核心任務進程必須在嚴格規定的時間範圍內進行處理和響應
但是非實時內核可能就需要等待時間片輪轉和任務隊列的處理.
在比如剎車的場景下非實時內核是無法實現快速的任務切換的.
CPU核心的優化策略
1. 中斷負載, 主要是網卡的隊列和中斷進行負載. 提高IO性能.
2. CPU綁定 現在都是多核CPU 甚至是有區分NUMA的, 建議將網卡和應用程序綁定到相同numa節點下的CPU核心上.
可以最大化性能響應時間和吞吐量.
3. 調整進程優先級. 可以使用nice 等命令修改優先級, 保證產品可以儘快的得到響應.
4. 儘量使用多線程, 不使用多進程模式, redis對比memcache 以及 nginx 對比 apache 都是多線程的處理機制
比多進程的處理機制要優秀的多的代表. 可以適當使用類似於go語言的協程, 性能會更加優秀.
5. 耗時的IO儘量使用異步, 不適用同步, 同步的阻塞模式會導致性能極具下降, 可以使用異步或者是消息隊列模式
進行優化 性能會有極大的提升.
第二部分 內存
Linux 採用虛擬內存的管理機制
使用段頁式內存管理
分頁內存主要是解決內存頁面的尋址處理
分段內存主要是解決內存的權限讀寫等問題.
段頁式內存協同處理, 是虛擬內存的核心機制.
Linux的內核也分爲內核態和用戶態.
32位和64位的內存管理也是差異比較巨大.
32爲內存一般分爲高地址內存和低地址內存.
部分存儲內核態的核心內存, 另一一部分是用戶態的內存.
需要特別注意. 每一個進程其實都有自己獨立的用戶態內存地址.
虛擬地址的都是完整的一套.
是通過TLB等將虛擬地址轉換到具體的物理地址來實現管理.
虛擬內存也是操作系統安全性的最大保證手段之一
一方面內核態的內存不允許隨意訪問
另一方面內核態映射的具體物理地址也通過加密方式進行隱藏, 避免出現安全隱患.
很多CPU內核級別的安全漏洞都是利用CPU的預取還有亂序執行的特點.在內存裏面抓取臨近內存的信息進行分析
視圖獲取相同CPU管理內存下的其他用戶的核心數據.
內存監控工具-傳統工具
命令 |
內容 |
dmesg |
OM Killer 事件的詳細信息 |
swapon/swapoff |
換頁設備管理 |
free |
顯示系統內存用量信息 |
ps |
按進程展示系統資源使用情況 |
pmap |
按進程統計信息,包括內存用量 |
vmstat |
系統整體資源使用情況 |
top |
按進程展示系統資源使用情況 |
sar |
可以顯示換頁錯誤和也掃描頻率 |
perf |
內存相關的 PMC 統計信息和事件採樣信息 |
內存監控工具-bcc相關工具
命令 |
內容 |
cachestat |
展示文件系統緩存信息 |
cachetop |
以類似於 top 的方式展示文件系統緩存信息 |
oomkill |
展示 OOM Killer 事件的詳細信息 |
memleak |
展示可能有內存泄露的代碼路徑 |
shmsnoop |
跟蹤共享內存相關的調用信息 |
swapin |
按進程展示頁換入信息 |
內存優化的策略
保證系統有足夠的可用內存.
不要過分的使用全部內存
linux有一套 buffer和cache的機制 會最大限度的使用內存作爲緩衝.
作爲硬件層需要的優化:
1. 儘量通道裝滿.
2. 儘量使用滿載內存的近端CPU進行綁定.
3. 儘量使用高工作頻率的內存.
4. 儘量保證系統穩定和溫度範圍, 降低系統刷新頻率, 一般改爲64ms刷新一次.
5. 儘量保證內存品牌,型號一致, 避免因爲有高有低導致被降頻處理.
6. 硬件有異常立即更換,避免引起故障.
內存優化策略
軟件層面的優化主要有:
1. 建議管理swap, 實現fastfailure,避免系統卡頓, 帶病運行.
2. 建議操作系統的內存使用, 避免大量cache和buffer的使用.
3. 優化數據庫的內存使用,儘量專用軟件, 避免內存和CPU的爭搶.
4. JVM等內存配置. 合理設置堆區還有GC方法.
5. 儘量保留一定的內存用於突發burst的使用情況.
6. 核心參數優化, 以及tcp部分內存用量的優化等.
第三部分 文件系統與io
Linux系統使用VFS的虛擬文件層進行處理.
一般分爲 索引節點 indexnode 還有目錄想 directory entry 的方式進行管理
主要是記錄文件的 meta info 以及具體的 目錄結果.
/proc/sys/vm/drop_caches 1 2 3 就有部分對應的是清理 索引節點和目錄節點的內存緩存.
最大的緩存內容是具體文件內容的緩存 一般是按照 操作系統的page進行處理.
linux 其實有多種文件系統,應對不同的應用場景.
像是ext3 ext4 xfs aufs 等等.
文件系統與io監控工具-傳統
命令 |
內容 |
df |
顯示文件系統用量信息 |
mount |
掛載文件系統到系統上 |
strace |
跟蹤系統中的系統調用(這個命令可能會導致應用程序的性能下降 90%) |
perf |
文件系統相關的跟蹤點 |
du |
文件系統使用情況分目錄 |
iostat |
按磁盤分別輸出 I/O 統計信息,可提供 IOPS、吞吐量、I/O 請求時長 |
iotop |
top 的 I/O 版本 |
lsof |
列出當前系統中打開的文件 |
文件系統與io監控工具-bcc
命令 |
內容 |
fileslower |
展示較慢的文件讀/寫操作 |
filetop |
按 IOPS 和字節書排序展示文件 |
writeback |
展示寫回事件和對應的延遲信息 |
dcstat |
目錄緩存命中率統計信息 |
dcsnoop |
跟蹤目錄緩存的查找操作 |
mountsnoop |
跟蹤系統中的掛載和卸載操作 |
xfsslower |
統計過慢的 XFS 操作 |
xfsdist |
以直方圖統計常見的 XFS 操作延遲 |
命令 |
內容 |
ext4slower |
統計過慢的 EXT4 操作 |
ext4dist |
以直方圖統計常見的 EXT4 操作延遲 |
nfsslower |
統計過慢的 NFS 操作 |
nfsdist |
以直方圖統計常見的 NFS 操作延遲 |
biolatency |
以直方圖形式統計塊 I/O 延遲 |
biosnoop |
按 PID 和延遲閾值跟蹤塊 I/O |
biotop |
top 工具的磁盤版:按進程統計塊 I/O |
bitesize |
按進程統計磁盤 I/O 請求尺寸直方圖 |
biostacks |
跟蹤磁盤 I/O 相關的初始化軟件棧信息 |
文件系統與IO的優化策略
硬件方面:
1. 更快更好的硬件,比如SSD,比如快速Raid卡.或者是高速15k的硬盤.絕對不能使用SMR硬盤.
2. 更換更好的協議, 比如使用NVMe 換掉SCSI協議.
3. 拒絕使用RAID6,不推薦RAID5,建議RAID10.
4. 對IO要求高的比如數據庫 建議使用物理機 或者是直接使用raw設備.
5. 建議raid增加hot spare 避免故障引起性能下降, 增加處理時間的窗口.
6. 淘汰陳舊的設備, 保證設備更新換代.
7. 緩存以及硬件保護要做好,避免數據丟失. 性能與數據安全需要協調好.
軟件方面:
1. 選擇合適的文件系統.適當使用條帶化提高性能.
2. 多選設備實現多路徑訪問, 多路徑拆分高IO來提高性能.
3. 修改內核參數, 換用更好的更合適的電梯調度算法. 以及IO的depth等參數.
4. 選用好的 IO模型, 建議使用epoll以及zero copy等算法保證性能.