1. linux進程的調度
上回書說到 Linux進程的由來 和 Linux進程的創建 ，其實在同一時刻只能支持有限個進程或線程同時運行(這取決於CPU核數量，基本上一個進程對應一個CPU)，在一個運行的操作系統上可能運行著很多進程，如果運行的進程占據CPU的時間很長，就有可能導致其他進程餓死。為了解決這種問題，操作系統引入了 進程調度器 來進行進程的切換，輪流讓各個進程使用CPU資源。
1）rq： 進程的運行隊列( runqueue)， 每個CPU對應一個 ，包含自旋鎖(spinlock)、進程數量、用於公平調度的CFS信息結構、當前運行的進程描述符等。實際的進程隊列用紅黑樹來維護(通過CFS信息結構來訪問)。
2）cfs_rq： cfs調度的進程運行隊列信息 ，包含紅黑樹的根結點、正在運行的進程指針、用於負載均衡的葉子隊列等。
3）sched_entity： 把需要調度的東西抽象成調度實體 ，調度實體可以是進程、進程組、用戶等。這里包含負載權重值、對應紅黑樹結點、 虛擬運行時vruntime 等。
4）sched_class：把 調度策略(演算法)抽象成調度類 ，包含一組通用的調度操作介面。介面和實現是分離，可以根據調度介面去實現不同的調度演算法，使一個Linux調度程序可以有多個不同的調度策略。
1） 關閉內核搶占 ，初始化部分變數。獲取當前CPU的ID號，並賦值給局部變數CPU， 使rq指向CPU對應的運行隊列 。 標識當前CPU發生任務切換 ，通知RCU更新狀態，如果當前CPU處於rcu_read_lock狀態，當前進程將會放入rnp-> blkd_tasks阻塞隊列，並呈現在rnp-> gp_tasks鏈表中。 關閉本地中斷 ，獲取所要保護的運行隊列的自旋鎖， 為查找可運行進程做准備 。
2） 檢查prev的狀態，更新運行隊列 。如果不是可運行狀態，而且在內核態沒被搶占，應該從運行隊列中 刪除prev進程 。如果是非阻塞掛起信號，而且狀態為TASK_INTER-RUPTIBLE，就把該進程的狀態設置為TASK_RUNNING，並將它 插入到運行隊列 。
3）task_on_rq_queued(prev) 將pre進程插入到運行隊列的隊尾。
4）pick_next_task 選取將要執行的next進程。
5）context_switch(rq, prev, next)進行 進程上下文切換 。
1) 該進程分配的CPU時間片用完。
2) 該進程主動放棄CPU(例如IO操作)。
3) 某一進程搶佔CPU獲得執行機會。
Linux並沒有使用x86 CPU自帶的任務切換機制，需要通過手工的方式實現了切換。
進程創建後在內核的數據結構為task_struct ， 該結構中有掩碼屬性cpus_allowed，4個核的CPU可以有4位掩碼，如果CPU開啟超線程，有一個8位掩碼，進程可以運行在掩碼位設置為1的CPU上。
Linux內核API提供了兩個系統調用 ，讓用戶可以修改和查看當前的掩碼：
1) sched_setaffinity()：用來修改位掩碼。
2) sched_getaffinity()：用來查看當前的位掩碼。
在下次task被喚醒時，select_task_rq_fair根據cpu_allowed里的掩碼來確定將其置於哪個CPU的運行隊列，一個進程在某一時刻只能存在於一個CPU的運行隊列里。
在Nginx中，使用了CPU親和度來完成某些場景的工作：
worker_processes 4;
worker_cpu_affinity 0001001001001000;
上面這個配置說明了4個工作進程中的每一個和一個CPU核掛鉤。如果這個內容寫入Nginx的配置文件中，然後Nginx啟動或者重新載入配置的時候，若worker_process是4，就會啟用4個worker，然後把worker_cpu_affinity後面的4個值當作4個cpu affinity mask，分別調用ngx_setaffinity，然後就把4個worker進程分別綁定到CPU0～3上。
worker_processes 2;
worker_cpu_affinity 01011010;
上面這個配置則說明了兩個工作進程中的每一個和2個核掛鉤。
2. 在Linux下，怎麼切換目錄
linux下可以使用CD命令切換目錄。
pwd查看當前目錄
cd/進入根目錄
cd..返回上一級目錄
cd~切換到當前目錄的家目錄
cd~/chenwei切換到用戶chenwei的家目錄
cd-將當前目錄切換到上一個工作目錄
3. Linux 進程管理之進程調度與切換
我們知道，進程運行需要各種各樣的系統資源，如內存、文件、列印機和最
寶貴的 CPU 等，所以說，調度的實質就是資源的分配。系統通過不同的調度演算法（Scheling Algorithm）來實現這種資源的分配。通常來說，選擇什麼樣的調度演算法取決於資源分配的策略（Scheling Policy）。
有關調度相關的結構保存在 task_struct 中，如下：
active_mm 是為內核線程而引入的，因為內核線程沒有自己的地址空間，為了讓內核線程與普通進程具有統一的上下文切換方式，當內核線程進行上下文切換時，讓切換進來的線程的 active_mm 指向剛被調度出去的進程的 active_mm（如果進程的mm 域不為空，則其 active_mm 域與 mm 域相同）。
在 linux 2.6 中 sched_class 表示該進程所屬的調度器類有3種：
進程的調度策略有5種，用戶可以調用調度器里不同的調度策略：
在每個 CPU 中都有一個自身的運行隊列 rq，每個活動進程只出現在一個運行隊列中，在多個 CPU 上同時運行一個進程是不可能的。
運行隊列是使用如下結構實現的：
tast 作為調度實體加入到 CPU 中的調度隊列中。
系統中所有的運行隊列都在 runqueues 數組中，該數組的每個元素分別對應於系統中的一個 CPU。在單處理器系統中，由於只需要一個就緒隊列，因此數組只有一個元素。
內核也定義了一下便利的宏，其含義很明顯。
Linux、c/c++伺服器開發篇-------我們來聊聊進程的那些事
Linux內核 進程間通信組件的實現
學習地址：C/C++Linux伺服器開發/後台架構師【零聲教育】-學習視頻教程-騰訊課堂
需要C/C++ Linux伺服器架構師學習資料加qun812855908獲取（資料包括 C/C++，Linux，golang技術，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK，ffmpeg 等），免費分享
在分析調度流程之前，我們先來看在什麼情況下要執行調度程序，我們把這種情況叫做調度時機。
Linux 調度時機主要有。
時機1，進程要調用 sleep() 或 exit() 等函數進行狀態轉換，這些函數會主動調用調度程序進行進程調度。
時機2，由於進程的時間片是由時鍾中斷來更新的，因此，這種情況和時機4 是一樣的。
時機3，當設備驅動程序執行長而重復的任務時，直接調用調度程序。在每次反復循環中，驅動程序都檢查 need_resched 的值，如果必要，則調用調度程序 schele() 主動放棄 CPU。
時機4 ， 如前所述， 不管是從中斷、異常還是系統調用返回， 最終都調用 ret_from_sys_call()，由這個函數進行調度標志的檢測，如果必要，則調用調用調度程序。那麼，為什麼從系統調用返回時要調用調度程序呢？這當然是從效率考慮。從系統調用返回意味著要離開內核態而返回到用戶態，而狀態的轉換要花費一定的時間，因此，在返回到用戶態前，系統把在內核態該處理的事全部做完。
Linux 的調度程序是一個叫 Schele() 的函數，這個函數來決定是否要進行進程的切換，如果要切換的話，切換到哪個進程等。
從代碼分析來看，Schele 主要完成了2個功能：
進程上下文切換包括進程的地址空間的切換和執行環境的切換。
對於 switch_mm 處理，關鍵的一步就是它將新進程頁面目錄的起始物理地址裝入到寄存器 CR3 中。CR3 寄存器總是指向當前進程的頁面目錄。
switch_to 把寄存器中的值比如esp等存放到進程thread結構中，保存現場一邊後續恢復，同時調用 __switch_to 完成了堆棧的切換。
在進程的 task_struct 結構中有個重要的成分 thread，它本身是一個數據結構 thread_struct, 裡面記錄著進程在切換時的（系統空間）堆棧指針，取指令地址（也就是「返回地址」）等關鍵性的信息。
關於__switch_to 的工作就是處理 TSS （任務狀態段）。
TSS 全稱task state segment，是指在操作系統進程管理的過程中，任務（進程）切換時的任務現場信息。
linux 為每一個 CPU 提供一個 TSS 段，並且在 TR 寄存器中保存該段。
linux 中之所以為每一個 CPU 提供一個 TSS 段，而不是為每個進程提供一個TSS 段，主要原因是 TR 寄存器永遠指向它，在任務切換的適合不必切換 TR 寄存器，從而減小開銷。
在從用戶態切換到內核態時，可以通過獲取 TSS 段中的 esp0 來獲取當前進程的內核棧 棧頂指針，從而可以保存用戶態的 cs,esp,eip 等上下文。
TSS 在任務切換過程中起著重要作用，通過它實現任務的掛起和恢復。所謂任務切換是指，掛起當前正在執行的任務，恢復或啟動另一任務的執行。
在任務切換過程中，首先，處理器中各寄存器的當前值被自動保存到 TR（任務寄存器）所指定的任務的 TSS 中；然後，下一任務的 TSS 被裝入 TR；最後，從 TR 所指定的 TSS 中取出各寄存器的值送到處理器的各寄存器中。由此可見，通過在 TSS 中保存任務現場各寄存器狀態的完整映象，實現任務的切換。
因此，__switch_to 核心內容就是將 TSS 中的內核空間（0級）堆棧指針換成 next->esp0。這是因為 CPU 在穿越中斷門或者陷阱門時要根據新的運行級別從TSS中取得進程在系統空間的堆棧指針。
thread_struct.esp0 指向進程的系統空間堆棧的頂端。當一個進程被調度運行時，內核會將這個變數寫入 TSS 的 esp0 欄位，表示這個進程進入0級運行時其堆棧的位置。換句話說，進程的 thread_struct 結構中的 esp0 保存著其系統空間堆棧指針。當進程穿過中斷門、陷阱門或者調用門進入系統空間時，處理器會從這里恢復期系統空間棧。
由於棧中變數的訪問依賴的是段、頁、和 esp、ebp 等這些寄存器，所以當段、頁、寄存器切換完以後，棧中的變數就可以被訪問了。
因此 switch_to 完成了進程堆棧的切換，由於被切進的進程各個寄存器的信息已完成切換，因此 next 進程得以執行指令運行。
由於 A 進程在調用 switch_to 完成了與 B 進程堆棧的切換，也即是寄存器中的值都是 B 的，所以 A 進程在 switch_to 執行完後，A停止運行，B開始運行，當過一段時間又把 A 進程切進去後，A 開始從switch_to 後面的代碼開始執行。
schele 的調用流程如下：
4. Linux系統如何切換前台進程和後台進程
一、Shell支持作用控制，有以下命令：
1. command &讓進程在後台運行
2. jobs –l 查看後台運行的進程
3. fg %n 讓後台運行的進程n到前台來
4. bg %n 讓進程n到後台去;
PS：「n」為jobs查看到的進程編號。
二、執行命令&切換至後台
在Linux終端運行命令的時候，在命令末尾加上&符號，就可以讓程序在後台運行
root@Ubuntu$ 。/tcpserv01&
三、切換正在運行的程序到後台
如果程序正在前台運行，可以使用Ctrl+z 選項把程序暫停，然後用 bg %［number］命令把這個程序放到後台運行，這個步驟分為3步，如下：
1.暫停程序運行CTRL+Z
ctrl + z跟系統任務有關的，ctrl + z可以將一個正在前台執行的命令放到後台，並且暫停。
［Oracle@linuxidc ~］$ sh ins.sh
［1］+Stopped ins.sh
2.查看暫停的程序
察看jobs使用jobs或ps命令可以察看正在執行的jobs。
［oracle@linuxidc ~］$ jobs -l
［1］+ 4524Stopped ins.sh
jobs命令執行的結果，+表示是一個當前的作業，減號表是是當前作業之後的一個作業。
jobs -l選項可顯示所有任務的PID，jobs的狀態可以是running， stopped，Terminated
3.切換程序至後台
bg將一個在後台暫停的命令，變成繼續執行如果後台中有多個命令，可以用bg %jobnumber將選中的命令調出。
［oracle@linuxidc ~］$ bg %1
［oracle@linuxidc ~］$ jobs -l
［1］+ 4524Running ins.sh
4.切換程序至前台
也可以用 fg %［number］指令把一個程序掉到前台運行
［oracle@linuxidc ~］$ fg %1
。/tcpserv01
5.終止後台程序
也可以直接終止後台運行的程序，使用 kill 命令
［oracle@linuxidc ~］$ kill %1
但是如果任務被終止了（kill），shell 從當前的shell環境已知的列表中刪除任務的進程標識;也就是說，jobs命令顯示的是當前shell環境中所起的後台正在運行或者被掛起的任務信息。
5. linux 性能優化-- cpu 切換以及cpu過高
本文先介紹了cpu上下文切換的基礎知識，以及上下文切換的類型（進程，線程等切換）。然後介紹了如何查看cpu切換次數的工具和指標的解釋。同時對日常分析種cpu過高的情況下如何分析和定位的方法做了一定的介紹，使用一個簡單的案例進行分析，先用top，pidstat等工具找出佔用過高的進程id，然後通過分析到底是用戶態cpu過高，還是內核態cpu過高，並用perf 定位到具體的調用函數。（來自極客時間課程學習筆記）
1、多任務競爭CPU，cpu變換任務的時候進行CPU上下文切換(context switch)。CPU執行任務有4種方式：進程、線程、或者硬體通過觸發信號導致中斷的調用。
2、當切換任務的時候，需要記錄任務當前的狀態和獲取下一任務的信息和地址(指針)，這就是上下文的內容。因此，上下文是指某一時間點CPU寄存器(CPU register)和程序計數器(PC)的內容, 廣義上還包括內存中進程的虛擬地址映射信息.
3、上下文切換的過程：
4、根據任務的執行形式，相應的下上文切換，有進程上下文切換、線程上下文切換、以及中斷上下文切換三類。
5、進程和線程的區別：
進程是資源分配和執行的基本單位；線程是任務調度和運行的基本單位。線程沒有資源，進程給指針提供虛擬內存、棧、變數等共享資源，而線程可以共享進程的資源。
6、進程上下文切換：是指從一個進程切換到另一個進程。
(1)進程運行態為內核運行態和進程運行態。內核空間態資源包括內核的堆棧、寄存器等；用戶空間態資源包括虛擬內存、棧、變數、正文、數據等
(2)系統調用(軟中斷)在內核態完成的，需要進行2次CPU上下文切換(用戶空間-->內核空間-->用戶空間)，不涉及用戶態資源，也不會切換進程。
(3)進程是由內核來管理和調度的，進程的切換只能發生在內核態。所以，進程的上下文不僅包括了用戶空間的資源，也包括內核空間資源。
(4)進程的上下文切換過程：
(5)、下列將會觸發進程上下文切換的場景：
7、線程上下文切換：
8、中斷上下文切換
快速響應硬體的事件，中斷處理會打斷進程的正常調度和執行。同一CPU內，硬體中斷優先順序高於進程。切換過程類似於系統調用的時候，不涉及到用戶運行態資源。但大量的中斷上下文切換同樣可能引發性能問題。
重點關注信息：
系統的就緒隊列過長，也就是正在運行和等待 CPU 的進程數過多，導致了大量的上下文切換，而上下文切換又導致了系統 CPU 的佔用率升高。
這個結果中有兩列內容是我們的重點關注對象。一個是 cswch ，表示每秒自願上下文切換（voluntary context switches）的次數，另一個則是 nvcswch ，表示每秒非自願上下文切換（non voluntary context switches）的次數。
linux的中斷使用情況可以從 /proc/interrupts 這個只讀文件中讀取。/proc 實際上是 Linux 的一個虛擬文件系統，用於內核空間與用戶空間之間的通信。/proc/interrupts 就是這種通信機制的一部分，提供了一個只讀的中斷使用情況。
重調度中斷（RES），這個中斷類型表示，喚醒空閑狀態的 CPU 來調度新的任務運行。這是多處理器系統（SMP）中，調度器用來分散任務到不同 CPU 的機制，通常也被稱為處理器間中斷（Inter-Processor Interrupts，IPI）。
這個數值其實取決於系統本身的 CPU 性能。如果系統的上下文切換次數比較穩定，那麼從數百到一萬以內，都應該算是正常的。但當上下文切換次數超過一萬次，或者切換次數出現數量級的增長時，就很可能已經出現了性能問題。這時，需要根據上下文切換的類型，再做具體分析。
比方說：
首先通過uptime查看系統負載，然後使用mpstat結合pidstat來初步判斷到底是cpu計算量大還是進程爭搶過大或者是io過多，接著使用vmstat分析切換次數，以及切換類型，來進一步判斷到底是io過多導致問題還是進程爭搶激烈導致問題。
CPU 使用率相關的重要指標：
性能分析工具給出的都是間隔一段時間的平均 CPU 使用率，所以要注意間隔時間的設置，特別是用多個工具對比分析時，你一定要保證它們用的是相同的間隔時間。比如，對比一下 top 和 ps 這兩個工具報告的 CPU 使用率，默認的結果很可能不一樣，因為 top 默認使用 3 秒時間間隔，而 ps 使用的卻是進程的整個生命周期。
top 和 ps 是最常用的性能分析工具：
這個輸出結果中，第三行 %Cpu 就是系統的 CPU 使用率，top 默認顯示的是所有 CPU 的平均值，這個時候你只需要按下數字 1 ，就可以切換到每個 CPU 的使用率了。繼續往下看，空白行之後是進程的實時信息，每個進程都有一個 %CPU 列，表示進程的 CPU 使用率。它是用戶態和內核態 CPU 使用率的總和，包括進程用戶空間使用的 CPU、通過系統調用執行的內核空間 CPU 、以及在就緒隊列等待運行的 CPU。在虛擬化環境中，它還包括了運行虛擬機佔用的 CPU。
預先安裝 stress 和 sysstat 包，如 apt install stress sysstat。
stress 是一個 Linux 系統壓力測試工具，這里我們用作異常進程模擬平均負載升高的場景。而 sysstat 包含了常用的 Linux 性能工具，用來監控和分析系統的性能。我們的案例會用到這個包的兩個命令 mpstat 和 pidstat。
下面的 pidstat 命令，就間隔 1 秒展示了進程的 5 組 CPU 使用率，
包括：
perf 是 Linux 2.6.31 以後內置的性能分析工具。它以性能事件采樣為基礎，不僅可以分析系統的各種事件和內核性能，還可以用來分析指定應用程序的性能問題。
第一種常見用法是 perf top，類似於 top，它能夠實時顯示佔用 CPU 時鍾最多的函數或者指令，因此可以用來查找熱點函數，使用界面如下所示：
輸出結果中，第一行包含三個數據，分別是采樣數（Samples）如2K、事件類型（event）如cpu-clock:pppH和事件總數量（Event count）如：371909314。
第二種常見用法，也就是 perf record 和 perf report。 perf top 雖然實時展示了系統的性能信息，但它的缺點是並不保存數據，也就無法用於離線或者後續的分析。而 perf record 則提供了保存數據的功能，保存後的數據，需要你用 perf report 解析展示。
1.啟動docker 運行進程：
2.ab工具測試伺服器性能
ab（apache bench）是一個常用的 HTTP 服務性能測試工具，這里用來模擬 Ngnix 的客戶端。
3.分析過程
CPU 使用率是最直觀和最常用的系統性能指標，在排查性能問題時，通常會關注的第一個指標。所以更要熟悉它的含義，尤其要弄清楚:
這幾種不同 CPU 的使用率。比如說：
碰到 CPU 使用率升高的問題，你可以藉助 top、pidstat 等工具，確認引發 CPU 性能問題的來源；再使用 perf 等工具，排查出引起性能問題的具體函數.