最近在維護公司線上的服務器，排查了一些問題，所以做一個總結。有一段時間，線上環境變得很卡，客戶端請求很多都報超時，因為線上沒有良好的apm監控，所以只能通過流量高峰期和日志去排查問題。通過排查，發現數據庫的慢查詢日志在比之間的暴漲了十倍，然后發現，memcache服務器（8核）負載很高，cpu一直在50%的左右，原因就是memcache服務器內存用完，導致內存的淘汰十分頻繁，這樣就導致很多請求落到數據庫。下面說下主要的排查思路和用到的工具
服務的性能主要看的就是四大件：cpu、內存、磁盤、網絡。排查過程的重要程度也是有重到輕。
一、CPU和內存問題
我一般使用的就是最常見的top命令和htop命令，因為內存和cpu這個命令都有展示了所以就一起說了，而且內存也比較直觀。htop比top更簡單方便，現在也在慢慢開始用htop，因為在啟動一些應用的時候很多時候命令行非常長，如果實在top命令中因為字符限制，這個命令就不全，不能找到啟動這個應用的命令行，就無法定位到這個進程是什么應用，htop可以左右移動，可以完整的看到，我當初也是因為這個功能才用的它。因為兩個命令差不多，所以只說下top。
top命令
常用參數： -H 打印具體的線程， -p 打印某個進程 進入后 按數字1 可以切換cpu的圖形看有幾個核
下面是我的測試環境shell:
top - 14:28:49 up 7 min, 3 users, load average: 0.08, 0.26, 0.19
Tasks: 221 total, 2 running, 219 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.1 us, 3.4 sy, 0.0 ni, 91.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 985856 total, 81736 free, 646360 used, 257760 buff/cache
KiB Swap: 2094076 total, 1915196 free, 178880 used. 141592 avail Mem
我一般重點關注的指標有：
%Cpu(s): 5.1 us, 3.4 sy, 0.0 wa
這里可以非常直觀的看到當前cpu的負載情況，us用戶cpu占用時間，sy是系統調用cpu占用時間，wa是cpu等待io的時間，前面兩個比較直觀，但是第三個其實也很重要，如果wa很高，那么你就該重點關注下磁盤的負載了，尤其是像mysql這種服務器。
load average: 0.08, 0.26, 0.19
cpu任務隊列的負載，這個隊列包括正在運行的任務和等待運行的任務，三個數字分別是1分鍾、5分鍾和15分鍾的平均值。這個和cpu占用率一般是正相關的，反應的是用戶代碼，如果超過了內核數，表示系統已經過載。也就是說如果你是8核，那么這個數字小於等於8的負載都是沒問題的，我看網上的建議一般這個值不要超過ncpu*2-2為好。
KiB Mem : 985856 total, 81736 free, 646360 used, 257760 buff/cache
內存占用情況，total總內存，free空余內存， used已經分配內存，buff/cache塊設備和緩沖區占用的內存，因為Linux的內存分配，如果有剩余內存，他就會將內存用於cache，這樣可以較少磁盤的讀寫提高效率，如果有應用申請內存，buff/cache這部分內存也是可用的，所以正真的剩余內存應該是free+buff/cache
swap
線上服務器一般都是禁用狀態，所以不用看這項。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
這一欄主要是看進程的詳情，重點是%CPU %MEM，之前看的是整個服務器的負載，這里是每個進程的負載。
vmstat命令
這個命令和top有很多重疊，其實很多命令之間都有重疊，這個命令我主要會看下system這一欄，in線程中斷，cs線程上下文切換是否有異常，還有io這一欄。對top是一個非常好的補充。
root@ubuntu:~# vmstat 2 10
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 452352 195164 25648 365140 23 199 717 292 166 626 4 3 93 1 0
0 0 452352 195156 25648 365140 0 0 0 0 97 201 0 0 100 0 0
1 0 452352 195156 25648 365140 0 0 0 0 96 197 1 1 99 0 0
free命令
查看內存使用狀態，因為top命令中已經有了，所以很少使用。
典型問題
java應用出問題一般都是內存和cpu的問題，像cpu飆高，內存不夠等是通過這些來發現。一般cpu問題，通過top定位到進程號，然后輸入H切換到線程，記住具體的進程號，使用jstack打印java進程的線程棧，jstack輸出為十六進制，需要將top的轉換成十六進制的然后入找線程經常卡在哪個方法。如果是內存問題，則通過gc日志和jmap輸出dump文件。
二、磁盤問題
磁盤問題在mysql服務器中非常常見，很多時候mysql服務器的CPU不高但是卻出現慢查詢日志飆升，就是因為磁盤出現了瓶頸。還有mysql的備份策略，如果沒有監控磁盤空間，可能出現磁盤滿了服務不可用的現象。
iostat命令
常用參數： -k 用kb為單位 -d 監控磁盤 -x顯示詳情 num count 每個幾秒刷新 顯示次數
這個是我查看磁盤負載的主要工具，也可以顯示cpu的負載，不過我一般用iostat -kdx 2 10,下面是我測試環境執行情況：
root@ubuntu:~# iostat -kdx 2 10
Linux 4.13.0-38-generic (ubuntu) 11/18/2018 _x86_64_ (1 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 24.75 196.05 121.66 9.75 2481.33 961.29 52.40 0.44 3.33 1.12 30.95 0.51 6.71
scd0 0.00 0.00 0.02 0.00 0.08 0.00 7.00 0.00 0.25 0.25 0.00 0.25 0.00
我一般重點關注的指標有：
rkB/s和wkB/s
分別對應讀寫速度
avgqu-sz
讀寫隊列的平均請求長度，可以類比top命令的load average
await r_await w_await
io請求的平均時間（毫秒），分別是讀寫，讀和寫三個平均值。這個時間都包括在隊列中等待的時間和實際處理讀寫請求的時間，還有svctm這個參數，他說的是實際處理讀寫請求的時間，照理來講w_await肯定是大於svctm的，但是我在線上看到有w_await小於svctm的情況，不知道是什么原因。我看iostat的man手動中說svctm已經廢棄，所以一般我看的是這三個。
%util
這個參數直觀的看磁盤的負載情況，我首先看的就是這個參數。和top的wa命令有關聯。
iotop命令
這個命令非常簡單，主要用於直觀的看那些進程占用io較高，是否有異常的進程。
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init auto noprompt
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
4 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
6 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [mm_percpu_wq]
7 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
8 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_sched]
9 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_bh]
du和df命令
主要是通過這兩個命令看系統的磁盤占用率和文件夾的大小，有時候日志文件不清理會導致磁盤用滿等情況。
du
用法： df -h 查看磁盤占用情況
df
用法： du -sh 查看當前目錄 容量
典型問題
磁盤問題我在mysql服務器上處理過幾次，mysql負載大時，很多時候磁盤先到了瓶頸，大量個請求超時，cpu負載卻不高，如果mysql服務器異常，建議重點看下磁盤。
三、網絡問題
在線上服務器，大部分服務器都是只能內網訪問，放在公網的服務器也就那幾台nginx和ftp的，另外公網的那些服務器都有流量監控，所以網絡問題一般並不大，不再詳細說明，推薦一些工具，如果有需要可以對着查下。
nload命令
用於監控整體的帶寬
nethogs
用於監控進程的帶寬使用情況
tcpdump
這個工具挺有意思的，可以用來做抓包，如果對網絡協議有興趣的話也可以玩玩，它可以完整的監控到三次握手的幀，有利於更好的理解tcp協議，這個命令當時玩過一段時間，功能十分強大，主要用於排查疑難雜症，需要對網絡協議較深的理解。
這里有一篇不錯的文章：聊聊 tcpdump 與 Wireshark 抓包分析