linux 系統管理--進程管理
linux 系統管理--進程管理
1、進程基本概述
1.什麼是進程？
好比：windows上安裝的QQ，咱們會將其稱爲QQ程序，那麼當QQ運行以後，在任務管理器中，咱們能夠看到QQ程序在運行着，此時，咱們稱其爲:QQ進程。mysql
言簡意賅總結：當咱們運行一個程序，那麼咱們將該程序叫進程linux
注意：
1.當程序運行爲進程後，系統會爲該進程分配內存，以及運行的身份和權限。
2.在進程運行的過程當中，服務器上回有各類狀態來表示當前進程的指標信息。nginx
進程是已啓動的可執行程序的運行實例，進程有如下組成部分:redis
局部和全局變量 當前的調度上下文 分配給進程使用的系統資源，例如文件描述符、網絡端口等 給進程分配對應的pid,ppid
2.程序和進程的區別？
1.程序是開發寫出來的代碼，是永久存在的。數據和指令的集合，是一個靜態的概念，好比/bin/ls、/bin/cp等二進制文件。sql
2.進程是一個程序的運行過程，會隨着程序的終止兒銷燬，不會永遠在系統中存在。是一個動態概念，進程是存在生命週期概念的。shell
3.進程的生命週期
程序運行時進程的狀態關係:apache
1.當父進程接收到任務調度時，會經過fork派生子進程來處理，那麼子進程會集成父進程的衣鉢。
2.子進程在處理任務代碼時，父進程會進入等待的狀態...
3.若是子進程在處理任務過程當中，父進程退出了，子進程沒有退出，那麼這些子進程就沒有父進程來管理了，就變成了殭屍進程。
4.每一個進程都會有本身的PID號，（process id）子進程則PPIDvim
2、監控進程狀態
1.使用ps命令查看當前的進程狀態（靜態查看）
經常使用組合：ps aux 查看進程windows
[root@zls ~]# ps aux a:顯示全部與終端相關的進程，由終端發起的 u:顯示用戶導向的用戶列表 x：顯示全部與終端無關的進程
在多任務處理操做系統中，每一個CPU(或核心)在一個時間點上只能處理一個進程。
在進程運行時，它對 CPU 時間和資源分配的要求會不斷變化，從而爲進程分配一個狀態，它隨着環境要求而改變。
USER: //啓動程序的用戶
PID: //進程ID
%CPU: //佔用CPU的百分比
%MEM: //佔用內存的百分比
VSZ: //虛擬內存集（進程佔用虛擬內存的空間）
RSS: //物理內存集（進程佔用物理內存的空間）
TTY: //運行的終端
?: #內核運行的終端
tty1: #機器運行的終端
pts/0: #遠程鏈接的終端
STAT: //進程狀態
D: #沒法中斷的休眠狀態（通IO的進程）
R: #正在運行的狀態
S: #處於休眠的狀態
T: #暫停或被追蹤的狀態
W: #進入內存交換（從內核2.6開始無效）
X: #死掉的進程（少見）
Z: #殭屍進程
<: #優先級高的進程
N: #優先級較低的進程
L: #有些頁被鎖進內存
s: #父進程（在它之下有子進程開啓着）
l: #以線程的方式運行
|: #多進程的
+: #該進程運行在前臺
START: //進程被觸發開啓的時間
TIME: //該進程實際使用CPU的運行時間
COMMAND: //命令的名稱和參數
[]: #內核態的進程
沒[]: #用戶態的進程
案例一：PS命令查看前臺進程轉換到中止
#在終端上運行vim [root@zls ~]# vim zls.txt #查看vim運行的狀態，S：睡眠狀態 +：在前臺運行 [root@zls ~]# ps aux|grep [v]im root 1306 0.0 0.2 151664 5180 pts/0 S+ 13:00 0:00 vim zls.txt #執行ctrl + z，將進程放置後臺 [1]+ 已中止 vim zls.txt #進程狀態變成了T，暫停或被追蹤的狀態 [root@zls ~]# ps aux|grep [v]im root 1306 0.0 0.2 151664 5180 pts/0 T 13:00 0:00 vim zls.txt
案例二：PS命令查看不可中斷狀態
#在終端上運行tar命令 [root@zls ~]# tar zcf zls.tar.gz /etc/ /usr/ /var/ /usr/ #持續查看tar進程的狀態 [root@zls ~]# ps aux|grep [t]ar root 1348 13.3 0.0 124008 1700 pts/0 R+ 13:06 0:00 tar zcf zls.tar.gz /etc/ /usr/ /var/ /usr/ [root@zls ~]# ps aux|grep [t]ar root 1348 13.2 0.0 124008 1716 pts/0 R+ 13:06 0:00 tar zcf zls.tar.gz /etc/ /usr/ /var/ /usr/ [root@zls ~]# ps aux|grep [t]ar root 1348 15.7 0.0 124008 1716 pts/0 S+ 13:06 0:00 tar zcf zls.tar.gz /etc/ /usr/ /var/ /usr/ [root@zls ~]# ps aux|grep [t]ar root 1348 13.6 0.0 124008 1736 pts/0 S+ 13:06 0:00 tar zcf zls.tar.gz /etc/ /usr/ /var/ /usr/ [root@zls ~]# ps aux|grep [t]ar root 1348 15.1 0.0 124008 1736 pts/0 R+ 13:06 0:00 tar zcf zls.tar.gz /etc/ /usr/ /var/ /usr/ [root@zls ~]# ps aux|grep [t]ar root 1348 14.1 0.0 124008 1736 pts/0 D+ 13:06 0:00 tar zcf zls.tar.gz /etc/ /usr/ /var/ /usr/ [root@zls ~]# ps aux|grep [t]ar root 1348 13.2 0.0 124008 1756 pts/0 R+ 13:06 0:01 tar zcf zls.tar.gz /etc/ /usr/ /var/ /usr/ [root@zls ~]# ps aux|grep [t]ar root 1348 15.2 0.0 124140 1756 pts/0 R+ 13:06 0:01 tar zcf zls.tar.gz /etc/ /usr/ /var/ /usr/ [root@zls ~]# ps aux|grep [t]ar root 1348 14.7 0.0 124240 1952 pts/0 S+ 13:06 0:01 tar zcf zls.tar.gz /etc/ /usr/ /var/ /usr/
案例三：PS命令查看進程Ss+狀態
#過濾bash進程，再開啓終端 [root@zls ~]# ps aux|grep [b]ash root 1127 0.0 0.1 115436 2084 tty1 Ss 11:49 0:00 -bash root 1180 0.0 0.0 115436 1900 tty1 S+ 11:49 0:00 bash root 1198 0.0 0.1 115564 2152 pts/0 Ss 11:50 0:00 -bash root 1324 0.0 0.1 115440 2064 pts/1 Ss+ 13:01 0:00 -bash
瞭解進程以下選項:
PID,PPID 當前的進程狀態 內存的分配狀況 CPU 和已花費的時間 用戶UID決定進程的特權
ps命令使用方法
#對進程的CPU進行排序展現
[root@zls ~]# ps aux --sort %cpu |less
#對進程的佔用物理內存排序
[root@zls ~]# ps aux --sort rss |less
#排序，實在記不住，那就本身排序
[root@zls ~]# ps aux|sort -k3 -n
#自定義顯示字段，指定想看的列
[root@zls ~]# ps axo user,pid,ppid,%mem,command |grep sshd
root 869 1 0.2 /usr/sbin/sshd -D
root 1194 869 0.2 sshd: root@pts/0
root 1307 869 0.2 sshd: root@pts/1
root 1574 869 0.2 sshd: root@pts/2
#顯示進程的子進程
[root@zls ~]# yum install nginx -y
[root@zls ~]# systemctl start nginx
[root@zls ~]# ps auxf|grep [n]ginx
root 2033 0.0 0.1 125096 2112 ? Ss 13:29 0:00 nginx: master process /usr/sbin/nginx
nginx 2034 0.0 0.1 125484 3148 ? S 13:29 0:00 \_ nginx: worker process
#默認不加選項是查看指定進程PID
[root@zls ~]# ps aux|grep sshd
root 1157 0.0 0.1 105996 3604 ? Ss Feb27 0:00 /usr/sbin/sshd -D
[root@zls ~]# cat /run/sshd.pid
1157
#pgrep經常使用參數, -l -a
[root@zls ~]# pgrep sshd
869
1194
1307
1574
[root@zls ~]# pgrep -l sshd
869 sshd
1194 sshd
1307 sshd
1574 sshd
[root@zls ~]# pgrep -l -a sshd
869 /usr/sbin/sshd -D
1194 sshd: root@pts/0
1307 sshd: root@pts/1
1574 sshd: root@pts/2
#查看進程的pid
[root@zls ~]# pidof sshd
1574 1307 1194 869
#查看進程樹
[root@zls ~]# pstree
systemd─┬─NetworkManager───2*[{NetworkManager}]
├─VGAuthService
├─abrt-watch-log
├─abrtd
├─agetty
├─auditd───{auditd}
├─crond
├─dbus-daemon───{dbus-daemon}
├─irqbalance
├─master─┬─pickup
│ └─qmgr
├─nginx───4*[nginx]
├─polkitd───6*[{polkitd}]
├─rsyslogd───2*[{rsyslogd}]
├─sshd─┬─sshd───bash───pstree
│ └─sshd───bash───bash───bash
├─systemd-journal
├─systemd-logind
├─systemd-udevd
├─tuned───4*[{tuned}]
├─vmtoolsd───{vmtoolsd}
└─vsftpd
2. 動態監控進程--top 命令
[root@gong ~]# top top - 22:58:05 up 4:37, 3 users, load average: 0.00, 0.01, 0.05 Tasks: 98 total, 1 running, 97 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 2047488 total, 1566920 free, 116060 used, 364508 buff/cache KiB Swap: 0 total, 0 free, 0 used. 1763644 avail Mem #當前系統的時間 22:58:05 #開啓時間 up 4:37, #幾個用戶同時在線 3 users, #平均負載：1分鐘，5分鐘，15分鐘 load average: 0.00, 0.01, 0.05 #總共工做數量98個 Tasks:98 total, #1個正在處理 1 running, #97個S狀態 97 sleeping, #00箇中止狀態 2 stopped, #0個殭屍進程 0 zombie %Cpu(s): #用戶態：用戶佔用CPU的百分比 0.0 us, #內核態：系統程序佔用CPU的百分比（一般內核與硬件進行交互） 0.0 sy, dd </dev/zero >/dev/null bs=200M count=1000 #優先級：優先被調度的程序佔用CPU百分比 0.0 ni, #空閒：CPU空閒的百分比(windows也有) 99.7 id, #等待：CPU等待IO的完成時間 0.0 wa, #硬中斷：佔CPU的百分比 0.0 hi, 由與系統相連的外設(好比網卡、硬盤)自動產生的。主要是用來通知操做系統,系統外設狀態的變化。好比當網卡收到數據包的時候，就會發出一箇中斷。咱們一般所說的中斷指的是硬中斷(hardirq)。 #軟中斷：佔CPU的百分比 0.0 si, 爲了知足實時系統的要求，中斷處理應該是越快越好。linux爲了實現這個特色，當中斷髮生的時候，硬中斷處理那些短期就能夠完成的工做，而將那些處理事件比較長的工做，放到中斷以後來完成，也就是軟中斷(softirq)來完成。 #虛擬機佔用物理機的百分比 0.0 st
3.中斷
硬中斷是系統用來影響硬件設備請求的一種機制，它會打斷進程的正常調度和執行，而後調用內核中的中斷處理程序來影響設備的請求
舉個例子： 好比你定了一份外賣，可是不肯定外賣何時送到，也沒有別的方法瞭解外賣的進度，可是配送人員送外賣是不等人的，到了你這，沒人接取的話，直接走人了。因此你只能苦苦的等着，時不時的去門口看看外賣送到沒有，而不能作其餘的事情。 不過若是在訂外賣的時候，你就跟配送員約定好了，讓他送到給你打電話，那你就不用苦苦等着了，能夠去忙別的事情了，直到電話一響，接到電話，就能夠取外賣了。此時 ==打電話== 就是一箇中斷的操做。 沒接到電話以前，你能夠作其餘事情，當你接到電話以後（就發生了中斷），你纔要進行另外一個動做**取外賣** PS：中斷是一個異步的事件處理機制，能夠提升操做系統處理併發的能力。
因爲中斷處理程序會打斷其餘進程的運行，因此，爲了減小對正常進程運行調度的影響，中弄斷處理程序就須要儘量快的運行，若是中弄斷自己要作的事情很少，那麼處理起來也不會有太大的問題，可是若是中斷要處理的事情不少，中斷服務程序就有可能要運行很長時間。
特別是，中斷處理程序在影響中斷時，還會臨時關閉中斷，這就會致使上一次中斷處理完成以前，其餘中斷都能不能響應，也就是說中斷有可能會丟失。
仍是之外賣爲例：加入你定了2份外賣 一份主食和一份飲料，由2個不一樣的配送員來配送。此次你不用時時等待着，兩份外賣都約定了電話取外賣的方式。那麼問題又來了。 當第一份外賣送到時，配送員給你打了個很長的電話，商量發票處理的方式，與此同時，第二個配送員也到了，也想給你打電話，可是會佔線，由於電話佔線（也就關閉了中斷的響應），第二個配送給你打電話打不通，因此，那麼頗有可能在嘗試幾回還佔線，就走了（丟失了一次中斷）
剛纔說了丟失一次中斷，若是對於系統來講，每次都只能處理一次中斷，那就很刺激了，每天都在丟失中斷，用戶的請求發過來，沒響應，還作個P的運維，回家種地吧...


軟中斷：
事實上，爲了解決中斷處理程序執行過長的和丟失中斷的問題，Linux將中斷處理過程分紅了兩個階段：
第一階段：用來快速處理中斷，它在中斷禁止模式下運行，主要處理跟硬件緊密相關工做
第二階段：用來延遲處理第一階段未完成的工做，一般之內核線程的方式運行。
仍是外賣的那個例子： 第一階段：當你接到第一個配送員電話時，你能夠跟他說，你已經知道了，其餘事見面再細說，而後就能夠掛斷電話了。 第二階段：纔是取外賣，而後見面聊發票的處理動做。 如此一來，第一個配送員不會在電話裏佔用你很長時間，第二個配送員來的時候，照樣能夠打通電話。
當網卡在接收數據包的時候，會經過硬中斷的方式通知內核，有新數據到了。這時，內核就應該調用中斷處理程序來影響它。對第一階段來講，既然是快速處理，其實就是把網卡接收到的數據包，先放置內存當中，而後更新一下硬件寄存器的狀態（表示數據已經讀好了），而第二階段，被軟中斷信號喚醒後，須要從內存中找到網絡數據，再按照網絡協議棧，對數據進行逐層解析和處理，直到把它發送給應用程序。
總結：
第一階段：直接處理硬件請求，也就是咱們常說的硬中斷，特色是快速執行。
第二階段：由內核觸發該請求，也就是咱們常說的軟中斷，特色是延遲執行。
4.Linux軟中斷與硬中斷小結：
1.Linux中中斷處理程序分爲上半部和下半部：
上半部對應硬中斷，用來快速處理
下半部對應軟中斷，用來異步處理上半部未完成的工做
2.Linux中的軟中斷包括：網絡收發，定時，調度等各類類型，能夠經過/proc/softirqs來觀察中斷的運行狀況
在企業中，會常常據說一個問題，就是大量的網絡小包會致使性能問題，爲啥呢？
由於大量的網絡小包會致使頻繁的硬中斷和軟中斷，因此大量的網絡小包傳輸速度很慢，但若是將全部的網絡小包"打包","壓縮"一次性傳輸，是否是會快不少。 就比如，你在某東自營買了100個快遞，都是次日到，若是分100個快遞員，給你配送，你一天要接100個電話，~~~~~~~~ 可是若是，某東只讓一個快遞員，把你買的100個快遞，打包成一個大包裹，派送給你，會不會快不少？
top命令使用：
[root@zls ~]# top #指定N秒變化時間 [root@zls ~]# top -d 1 #查看指定進程的動態信息 [root@zls ~]# top -d 1 -p 10126 [root@zls ~]# top -d 1 -p 10126,1 #查看指定用戶的進程 [root@zls ~]# top -d 1 -u apache #將 2 次 top 信息寫入到文件 [root@zls ~]# top -d 1 -b -n 2 > top.txt top 常見指令 h 查看幫出 z 高亮顯示 1 顯示全部CPU的負載 s 設置刷新時間 b 高亮現實處於R狀態的進程 M 按內存使用百分比排序輸出 P 按CPU使用百分比排序輸出 R 對排序進行反轉 f 自定義顯示字段 k kill掉指定PID進程 W 保存top環境設置 ~/.toprc q 退出 #進程ID PID #用戶 USER #優先級，正常爲20 PR #nice值，正常爲0，負值表示高優先級，正值表示低優先級 NI #虛擬內存佔用 VIRT #真實內存佔用 RES #共享內存佔用 SHR #模式狀態 S #CPU佔用百分比 %CPU #內存佔用百分比 %MEM #運行時間 TIME+ #運行命令 COMMAND
5.kill信號管理：
當程序運行爲進程後，若是但願強行中止就可使用kill命令對進程發送關閉信號，除了kill還有pkill、killall
定義守護進程的角色
結束用戶會話和進程
kill,killall,pgrep,pkill
[root@zls ~]# kill -l //列出全部支持的信號 //常見信號列表: 數字信號 信號別名 做用 1 HUP 掛起信號，每每可讓進程從新配置 2 INT 中斷信號，起到結束進程的做用，和ctrl + c 的做用同樣 3 QUIT 讓進程退出，結果是進程退出 9 KILL 直接結束進程，不能被進程捕獲 15 TERM 進程終止，這是默認信號 18 CONT 被暫停的進程將繼續恢復運行 19 STOP 暫停進程 20 TSTP 用戶中止請求，做用相似於ctrl + z 把進程放到後臺並暫停
6.kill命令發送信號
// 給 vsftpd 進程發送信號 1,15 [root@zls ~]# yum -y install vsftpd [root@zls ~]# systemctl start vsftpd //發送重啓信號，例如 vsftpd 的配置文件發生改變，但願從新加載 [root@zls ~]# kill -1 9160 //發送中止信號，vsftpd 服務有中止的腳本 systemctl stop vsftpd [root@zls ~]# kill 9160 // 給vim進程發送信號 9,15 [root@zls ~]# touch file1 file2 //使用遠程終端1打開file1 [root@zls ~]# tty /dev/pts/1 [root@zls ~]# vim file1 //使用遠程終端2打開file2 [root@zls ~]# tty /dev/pts/2 [root@zls ~]# vim file2 //查看當前進程pid [root@zls ~]# ps aux |grep vim root 4362 0.0 0.2 11104 2888 pts/1 S+ 23:02 0:00 vim file1 root 4363 0.1 0.2 11068 2948 pts/2 S+ 23:02 0:00 vim file2 //發送15信號 [root@zls ~]# kill 4362 //發送9信號 [root@zls ~]# kill -9 4363 //還能夠同時給全部vim進程發送信號, 模糊匹配，同時給多個進程發送信號 [root@zls ~]# killall vim //使用pkill踢出從遠程登陸到本機的用戶, pkill 相似killall [root@zls ~]# w 20:50:17 up 95 days, 9:30, 1 user, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT xuliangw pts/0 115.175.115.39 20:22 0.00s 0.01s 0.00s sshd: zls [priv] //終止 pts/0上全部進程, 除了bash自己 [root@zls ~]# pkill -t pts/0 -t：指定終端 //終止pts/0上全部進程, 而且bash也結束（用戶被強制退出） [root@zls ~]# pkill -9 -t pts/0 //列出zls用戶的全部進程，-l輸出pid [root@linux-zls ~]# pgrep -l -u zls 32206 sshd 32207 bash
3、進程的優先級[進階]
優先級指的是優先享受資源，生活中的例子，好比...算了，太多了。
在啓動進程時，爲不一樣的進程使用不一樣的調度策略。
nice值越高：表示優先級越低，例如19，該進程容易將CPU使用量讓給其餘進程。
nice值越低：表示優先級越高，例如-20，該進程更不傾向於讓出CPU。
1.使用top或ps命令查看進程的優先級
#使用top看優先級
[root@zls ~]# top
top - 19:36:33 up 7:47, 4 users, load average: 0.00, 0.01, 0.05
Tasks: 99 total, 1 running, 97 sleeping, 1 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 2030148 total, 155208 free, 159544 used, 1715396 buff/cache
KiB Swap: 1048572 total, 1048572 free, 0 used. 1633728 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
533 root 20 0 298716 6108 4780 S 0.3 0.3 0:23.45 vmtoolsd
2337 root 20 0 161980 2240 1556 R 0.3 0.1 0:00.01 top
1 root 20 0 127908 6492 4092 S 0.0 0.3 0:01.85 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
#使用ps查看優先級
[root@zls ~]# ps axo command,nice |grep 摺疊shd
/usr/sbin/sshd -D 0
sshd: root@pts/0 0
sshd: root@pts/1 0
sshd: root@pts/2 0
2.使用nice命令指定進程優先級
#打開一個終端 [root@zls ~]# nice -n -5 vim zls #打開另外一個終端，查看進程的優先級 [root@zls ~]# ps aux|grep [v]im root 2342 0.1 0.2 151720 5212 pts/1 S<+ 19:49 0:00 vim zls [root@zls ~]# ps axo command,nice|grep [v]im vim zls -5
3.使用renice調整已運行程序的優先級
#先查看sshd的優先級 [root@zls ~]# ps axo pid,command,nice|grep 摺疊shd 869 /usr/sbin/sshd -D 0 1194 sshd: root@pts/0 0 1307 sshd: root@pts/1 0 1574 sshd: root@pts/2 0 #設置sshd的優先級爲-20 [root@zls ~]# renice -n -20 869 869 (進程 ID) 舊優先級爲 0，新優先級爲 -20 #再次查看sshd的優先級 [root@zls ~]# ps axo pid,command,nice|grep 摺疊shd 869 /usr/sbin/sshd -D -20 1194 sshd: root@pts/0 0 1307 sshd: root@pts/1 0 1574 sshd: root@pts/2 0 #必定要退出終端從新鏈接 [root@zls ~]# exit 登出 #再檢查，就能夠看到當前終端的優先級變化了 [root@zls ~]# ps axo pid,command,nice|grep sshd 869 /usr/sbin/sshd -D -20 1194 sshd: root@pts/0 0 1574 sshd: root@pts/2 0 2361 sshd: root@pts/1 -20
4、企業案例，Linux假死是怎麼回事
所謂假死，就是能ping通，可是ssh不上去；任何其餘操做也都沒反應，包括上面部署的nginx也打不開頁面。
做爲一個多任務操做系統，要把系統忙死，忙到ssh都連不上去，也不是那麼容易的。尤爲是如今還有fd保護、進程數保護、最大內存保護之類的機制。
你能夠fork不少進程，系統會變得很慢，可是ssh仍是能連上去；你能夠分配不少內存，可是內存多到必定程度oom killer就會把你的進程殺掉，因而ssh又能工做了。
有一個肯定能夠把系統搞成假死的辦法是：主進程分配固定內存，而後不停的fork，而且在子進程裏面sleep(100)。
也就是說，當主進程不停fork的時候，很快會把系統的物理內存用完，當物理內存不足時候，系統會開始使用swap；那麼當swap不足時會觸發oom killer進程；
當oom killer殺掉了子進程，主進程會馬上fork新的子進程，並再次致使內存用完，再次觸發oom killer進程，因而進入死循環。並且oom killer是系統底層優先級很高的內核線程，也在參與死循環。
此時機器能夠ping通，可是沒法ssh上去。這是因爲ping是在系統底層處理的，沒有參與進程調度；sshd要參與進程調度，可是優先級沒oom killer高，總得不到調度。
爲何要費那麼大的力氣把機器搞死？咱們知道假死是怎麼產生的便可，這樣能夠針對假死的緣由進行預防。 (其實假死的狀況不多發生，只有當代碼寫的bug不少的狀況下會出現。)
其實建議使用nice將sshd的進程優先級調高。這樣當系統內存吃緊，還能勉強登錄sshd，進入調試。而後分析故障。
5、後臺進程管理
一般進程都會在終端前臺運行，可是一旦關閉終端，進程也會隨着結束，那麼此時咱們就但願進程能在後臺運行，就是將在前臺運行的進程放到後臺運行，這樣即便咱們關閉了終端也不影響進程的正常運行。
企業中不少時候會有一些需求：
1.傳輸大文件，因爲網絡問題須要傳輸好久
2.咱們以前的國外業務，國內到國外，網速很慢，咱們須要選擇節點作跳板機，那麼就必須知道，哪一個節點到其餘地區網速最快，丟包率最低。
3.有些服務沒有啓動腳本，那麼咱們就須要手動運行，並把他們放到後臺
早期的時候，你們都選擇使用&，將進程放到後臺運行，而後再使用jobs、bg、fg等方式查看進程狀態，太麻煩了，也不僅管，因此咱們推薦使用screen和nohup
做業控制是一個命令行功能，容許一個 shell 實例來運行和管理多個命令。
若是沒有做業控制，父進程 fork()一個子進程後，將 sleeping，直到子進程退出。
使用做業控制，能夠選擇性暫停，恢復，以及異步運行命令，讓 shell 能夠在子進程運行期間返回接受其 他命令。
前臺進程,後臺進程jobs,bg,fg
ctrl + Z , ctrl +c , ctrl + B
[root@zls ~]# sleep 3000 & //運行程序(時)，讓其在後臺執行 [root@zls ~]# sleep 4000 //^Z,將前臺的程序掛起(暫停)到後臺 [2]+ Stopped sleep 4000 [root@zls ~]# ps aux |grep sleep [root@zls ~]# jobs //查看後臺做業 [1]- Running sleep 3000 & [2]+ Stopped sleep 4000 [root@zls ~]# bg %2 //讓做業 2 在後臺運行 [root@zls ~]# fg %1 //將做業 1 調回到前臺 [root@zls ~]# kill %1 //kill 1，終止 PID 爲 1 的進程 [root@zls ~]# (while :; do date; sleep 2; done) & //進程在後臺運行，但輸出依然在當前終端 [root@zls ~]# (while :; do date; sleep 2; done) &>/dev/null &
#安裝screen命令
[root@zls ~]# yum install -y screen
#安裝redis
[root@zls ~]# yum install -y redis
#啓動redis
[root@zls ~]# redis-server
#放到後臺ctrl + z
[1]+ 已中止 redis-server
#關閉終端，redis進程就沒有了
#下載mysql安裝包
[root@zls ~]# wget https://downloads.mysql.com/archives/get/file/mysql-5.7.24-linux-glibc2.12-x86_64.tar.gz
#使用screen
[root@zls ~]# screen -S download_mysqld
#ctrl + a + d放置後臺
[detached from 3567.download_mysqld]
#查看screen列表
[root@zls ~]# screen -list
There is a screen on:
3567.download_mysqld (Detached)
1 Socket in /var/run/screen/S-root.
#打開screen終端
[root@zls ~]# screen -r 3567
6、系統平均負載[進階]
每次發現系統變慢時，咱們一般作的第一件事，就是執行top或者uptime命令，來了解系統的負載狀況。
[root@zls ~]# uptime 20:45:42 up 8:56, 3 users, load average: 0.01, 0.03, 0.05 #咱們已經比較熟悉前面幾個例子，他們分別是當前時間，系統運行時間，以及正在登錄用戶數 #後面三個數依次是：過去1分鐘,5分鐘,15分鐘的平均負載(Load Average)
平均負載不就是單位時間內，CPU的使用率嘛？上面的,0.01不就是CPU的使用率是1%
平均負載是指，單位時間內，系統處於可運行狀態和不可中斷狀態的平均進程數，也就是平均活躍進程數
PS:平均負載與CPU使用率並無直接關係。
1.可運行狀態進程，是指正在使用CPU或者正在等待CPU的進程，也就是咱們用PS命令看的處於R狀態的進程
2.不可中斷進程，（你在作什麼事情的時候是不能被打斷的呢？...不可描述）系統中最多見的是等待硬件設備的IO相應，也就是咱們PS命令中看到的D狀態（也成爲Disk Sleep）的進程。
例如：當一個進程向磁盤讀寫數據時，爲了保證數據的一致性，在獲得磁盤迴復前，他是不能被其餘進程或者中斷程序打斷的，這個是後續的進程就處於不可中斷的狀態，若是此時進程強制被打斷，kill -9 ... perfect準備好護照吧，有多遠，走多遠，千萬別回來了。不可中斷狀態其實是系統對進程和硬件設備的一種保護機制
所以，能夠簡單理解爲，平均負載其實就是單位時間內的活躍進程數。
最理想的狀態是每一個CPU上都剛還運行着一個進程，這樣每一個CPU都獲得了充分利用。因此在評判負載時，首先你要知道系統有幾個CPU，這能夠經過top命令獲取，或grep 'model name' /proc/cpuinfo
例1：
架設如今在4，2，1核的CPU上，若是平均負載爲2時，意味着什麼呢？
1.在4個CPU的系統上，意味着CPU有50%空閒。
2.在2個CPU的系統上，覺得這全部的CPU都恰好徹底被佔用。
3.在1個CPU的系統上，則意味着有一半的進程競爭不到CPU。
那麼...平均負載有三個數值，咱們應該關注哪一個呢？
實際上，咱們都須要關注，就比如北京5月份的天氣，若是隻看晚上天氣，感受在過冬天，可是你結合了早上，中午，晚上三個時間點的溫度來看，基本就能夠全方位的瞭解這一天的天氣狀況了。
1.若是1分鐘，5分鐘，15分鐘的三個值基本相同，或者相差不大，那就說明系統負載很平穩。
2.若是1分鐘的值遠小於15分鐘的值，就說明系統像最近1分鐘的負載在減小，而過去15分鐘內卻有很大的負載。
3.反過來，若是1分鐘的大於15分鐘，就說明最近1分鐘的負載在增長，這種增長有可能只是臨時的，也有可能還會持續上升...說的跟股票似的。因此要持續觀察。（emmmm...一旦K線降低，就拋，割肉）
4.一旦1分鐘的平均負載接近或超過了CPU的個數，就意味着，系統正在發生過載的問題，這時候就得分析問題了，而且要想辦法優化。
架設咱們在有2個CPU系統上看到平均負載爲2.73，6.90，12.98那麼說明在過去1分鐘內，系統有136%的超載（2.73/2100%=136%）
5分鐘：（6.90/2100%=345%）
15分鐘：(12.98/2*100%=649%)
但總體趨勢來看，系統負載是在逐步下降。
當平均負載高於CPU數量70%的時候，你就應該分析排查負載高的問題了，一旦負載太高，就可能致使進程相應變慢，進而影響服務的正常功能。
但70%這個數字並非絕對的，最推薦的方法，仍是把系統的平均負載監控起來，而後根據更多的歷史數據，判斷負載的變化趨勢，當發現負載有明顯升高的趨勢時，好比說負載翻倍了，你再去作分析和調查。
在實際工做中，咱們常常容易把平均負載和CPU使用率混淆，因此在這裏，我也作一個區分，可能你會感受到疑惑，既然平均負載表明的是活躍進程數，那平均負載搞了，不就意味着CPU使用率高嘛？
咱們仍是要回到平均負載的含義上來，平均負載指的是每單位時間內，處於可運行狀態和不可中斷狀態的進程數，因此，它不只包括了正在使用CPU的進程數，還包括等待CPU和等待IO的進程數。
而CPU的使用率是單位時間內，CPU繁忙狀況的統計，跟平均浮如今並不必定徹底對應。
好比：
CPU密集型進程，使用大量的CPU會致使平均負載升高，此時這二者是一致的。
IO密集型進程，等待IO也會致使平均負載升高，但CPU使用率不必定很高。
大量等待CPU的進程調度也會致使平均負載升高，此時的CPU使用率也會比較高。
可是CPU的種類也分兩種：
CPU密集型
IO密集型
例如MySQL服務器，就須要儘可能選擇使用IO密集型CPU
----
下面咱們以三個示例分別來看這三中狀況，並用：stress、mpstat、pidstat等工具找出平均負載升高的根源
stress是Linux系統壓力測試工具，這裏咱們用做異常進程模擬平均負載升高的場景。
mpstat是多核CPU性能分析工具，用來實時檢查每一個CPU的性能指標，以及全部CPU的平均指標。
pidstat是一個經常使用的進程性能分析工具，用來實時查看進程的CPU，內存，IO，以及上下文切換等性能指標。
#安裝stress命令 [root@zls ~]# yum install -y stress
案例一：CPU密集型
咱們在第一個中斷運行stress命令，模擬一個CPU使用率100%的場景：
#第一個終端執行 [root@zls ~]# stress --cpu 1 --timeout 600 #第二個終端查看 [root@zls ~]# uptime 22:04:12 up 10:15, 4 users, load average: 1.98, 0.57, 0.22 #高亮顯示變化區域 [root@zls ~]# watch -d uptime Every 2.0s: uptime Sun Jul 14 22:05:16 2019 22:05:16 up 10:16, 4 users, load average: 2.84, 1.05, 0.41
使用mpstat查看CPU使用率的變化狀況
[root@zls ~]# mpstat -P ALL 5 Linux 3.10.0-862.el7.x86_64 (zls) 2019年07月14日 _x86_64_ (1 CPU) 22時08分51秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 22時08分56秒 all 99.20 0.00 0.80 0.00 0.00 0.00 0.00 0.00 0.00 0.00 22時08分56秒 0 99.20 0.00 0.80 0.00 0.00 0.00 0.00 0.00 0.00 0.00 22時08分56秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 22時09分01秒 all 99.60 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 22時09分01秒 0 99.60 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00
從終端2能夠看到，1分鐘平均負載會慢慢增長到2.00，而從終端三中還能夠看到，正好有一個CPU的使用率爲100%，但他的IOwait只有0，這說明平均負載的升高正式因爲CPU使用率爲100%，那麼到底哪一個進程致使CPU使用率爲100%呢？可使用pidstat來查詢
#間隔5秒輸出一組數據 [root@zls ~]# pidstat -u 5 1 Linux 3.10.0-862.el7.x86_64 (zls) 2019年07月14日 _x86_64_ (1 CPU) 22時14分00秒 UID PID %usr %system %guest %CPU CPU Command 22時14分05秒 0 8349 0.00 0.20 0.00 0.20 0 kworker/0:3 22時14分05秒 0 9903 99.60 0.00 0.00 99.60 0 stress 平均時間: UID PID %usr %system %guest %CPU CPU Command 平均時間: 0 8349 0.00 0.20 0.00 0.20 - kworker/0:3 平均時間: 0 9903 99.60 0.00 0.00 99.60 - stress
案例二：I/O密集型
仍是使用stress命令，可是此次模擬IO的壓力
[root@zls ~]# stress --io 1 --timeout 600s
在第二個終端運行uptime查看平均負載的變化狀況
[root@zls ~]# watch -d uptime Every 2.0s: uptime Sun Jul 14 22:17:38 2019 22:17:38 up 10:28, 4 users, load average: 2.47, 2.25, 1.61
在第三個終端運行mpstat查看CPU使用率的變化狀況
[root@zls ~]# mpstat -P ALL 5 Linux 3.10.0-862.el7.x86_64 (zls) 2019年07月14日 _x86_64_ (1 CPU) 22時19分32秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 22時19分37秒 all 2.78 0.00 97.22 0.00 0.00 0.00 0.00 0.00 0.00 0.00 22時19分37秒 0 2.78 0.00 97.22 0.00 0.00 0.00 0.00 0.00 0.00 0.00 22時19分37秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 22時19分42秒 all 3.01 0.00 96.99 0.00 0.00 0.00 0.00 0.00 0.00 0.00 22時19分42秒 0 3.01 0.00 96.99 0.00 0.00 0.00 0.00 0.00 0.00 0.00 #發現CPU與內核打交道的sys佔用很是高
那麼到底哪一個進程致使iowait這麼高呢？
[root@zls ~]# pidstat -u 5 1 Linux 3.10.0-862.el7.x86_64 (zls) 2019年07月14日 _x86_64_ (1 CPU) 22時20分59秒 UID PID %usr %system %guest %CPU CPU Command 22時21分04秒 0 6900 0.00 0.20 0.00 0.20 0 kworker/0:0 22時21分04秒 0 10104 2.76 83.07 0.00 85.83 0 stress 22時21分04秒 0 10105 0.00 10.63 0.00 10.63 0 kworker/u256:2 平均時間: UID PID %usr %system %guest %CPU CPU Command 平均時間: 0 6900 0.00 0.20 0.00 0.20 - kworker/0:0 平均時間: 0 10104 2.76 83.07 0.00 85.83 - stress 平均時間: 0 10105 0.00 10.63 0.00 10.63 - kworker/u256:2
這時候發現看到的數據比較少，須要更新一下命令：
#下載新版本的包 [root@zls ~]# wget http://pagesperso-orange.fr/sebastien.godard/sysstat-11.7.3-1.x86_64.rpm #升級到新版本 [root@zls ~]# rpm -Uvh sysstat-11.7.3-1.x86_64.rpm 準備中... ################################# [100%] 正在升級/安裝... 1:sysstat-11.7.3-1 ################################# [ 50%] 正在清理/刪除... 2:sysstat-10.1.5-17.el7 ################################# [100%]
而後再次查看結果,明顯顯示的數據多了
[root@zls ~]# pidstat -u 5 1 Linux 3.10.0-862.el7.x86_64 (zls) 2019年07月14日 _x86_64_ (1 CPU) 22時24分40秒 UID PID %usr %system %guest %wait %CPU CPU Command 22時24分45秒 0 281 0.00 0.20 0.00 0.40 0.20 0 xfsaild/sda3 22時24分45秒 0 10104 2.99 82.67 0.00 0.00 85.66 0 stress 22時24分45秒 0 10105 0.00 8.76 0.00 92.43 8.76 0 kworker/u256:2 22時24分45秒 0 10118 0.20 0.40 0.00 0.00 0.60 0 watch 22時24分45秒 0 10439 0.00 3.98 0.00 94.82 3.98 0 kworker/u256:3 22時24分45秒 0 11007 0.00 0.20 0.00 0.00 0.20 0 pidstat 平均時間: UID PID %usr %system %guest %wait %CPU CPU Command 平均時間: 0 281 0.00 0.20 0.00 0.40 0.20 - xfsaild/sda3 平均時間: 0 10104 2.99 82.67 0.00 0.00 85.66 - stress 平均時間: 0 10105 0.00 8.76 0.00 92.43 8.76 - kworker/u256:2 平均時間: 0 10118 0.20 0.40 0.00 0.00 0.60 - watch 平均時間: 0 10439 0.00 3.98 0.00 94.82 3.98 - kworker/u256:3 平均時間: 0 11007 0.00 0.20 0.00 0.00 0.20 - pidstat
案例三：大量進程的場景
當系統運行進程超出CPU運行能力時，就會出現等待CPU的進程。
1.首先，咱們仍是使用stress命令，模擬的是多個進程
[root@zls ~]# stress -c 4 --timeout 600
2.因爲系統只有一個CPU，明顯比4個進程要少的多。所以，系統的CPU處於嚴重過載狀態
[root@zls ~]# Every 2.0s: uptime Sun Jul 14 22:28:50 2019 22:28:50 up 10:39, 4 users, load average: 3.96, 3.89, 3.00
3.在運行pidstat命令來查看一下進程的狀況
[root@zls ~]# pidstat -u 5 1 Linux 3.10.0-862.el7.x86_64 (zls) 2019年07月14日 _x86_64_ (1 CPU) 22時31分12秒 UID PID %usr %system %guest %wait %CPU CPU Command 22時31分17秒 0 11317 24.75 0.00 0.00 75.05 24.75 0 stress 22時31分17秒 0 11318 24.95 0.00 0.00 75.45 24.95 0 stress 22時31分17秒 0 11319 24.75 0.00 0.00 75.25 24.75 0 stress 22時31分17秒 0 11320 24.75 0.00 0.00 75.45 24.75 0 stress 22時31分17秒 0 11381 0.20 0.40 0.00 0.00 0.60 0 watch 22時31分17秒 0 11665 0.00 0.20 0.00 0.00 0.20 0 pidstat 平均時間: UID PID %usr %system %guest %wait %CPU CPU Command 平均時間: 0 11317 24.75 0.00 0.00 75.05 24.75 - stress 平均時間: 0 11318 24.95 0.00 0.00 75.45 24.95 - stress 平均時間: 0 11319 24.75 0.00 0.00 75.25 24.75 - stress 平均時間: 0 11320 24.75 0.00 0.00 75.45 24.75 - stress 平均時間: 0 11381 0.20 0.40 0.00 0.00 0.60 - watch 平均時間: 0 11665 0.00 0.20 0.00 0.00 0.20 - pidstat
總結：
1.平均負載高有多是CPU密集型進程致使的 2.平均負載高並不必定表明CPU的使用率就必定高，還有多是I/O繁忙 3.當發現負載高時，可使用mpstat、pidstat等工具，快速定位到，負載高的緣由，從而作出處理
- 1. linux系統管理-進程管理
- 2. linux系統管理——進程管理
- 3. Linux 系統管理-進程管理
- 4. linux系統管理之進程管理
- 5. Linux系統管理—進程管理
- 6. Linux 系統進程管理
- 7. Linux系統進程管理
- 8. Linux - 系統 - 進程管理
- 9. Linux------系統進程管理
- 10. Linux系統學習(8.2):Linux系統管理-進程管理-終止進程
- 更多相關文章...
- • Swarm 集羣管理 - Docker教程
- • Maven 依賴管理 - Maven教程
- • Docker 清理命令
- • Docker容器實戰(七) - 容器眼光下的文件系統
-
每一个你不满意的现在，都有一个你没有努力的曾经。