Ⅰ 請教linux下用戶態進程調度問題
在進行Linux系統操作的時候，有時候會遇到一次用戶態進程死循環，即系統反應遲鈍、進程掛死等問題，那麼遇到這些問題又該如何解決呢？下面小編就給大家介紹下一次用戶態進程死循環的問題該如何處理。
Linux下如何處理一次用戶態進程死循環問題
1、問題現象
業務進程（用戶態多線程程序）掛死，操作系統反應遲鈍，系統日誌沒有任何異常。從進程的內核態堆棧看，看似所有線程都卡在了內核態的如下堆棧流程中：
［root@vmc116 ~］# cat /proc/27007/task/11825/stack
［《ffffffff8100baf6》］ retint_careful+0x14/0x32
［《ffffffffffffffff》］ 0xffffffffffffffff
2、問題分析
1）內核堆棧分析
從內核堆棧看，所有進程都阻塞在 retint_careful上，這個是中斷返回過程中的流程，代碼（匯編）如下：
entry_64.S
代碼如下：
ret_from_intr：
DISABLE_INTERRUPTS（CLBR_NONE）
TRACE_IRQS_OFF
decl PER_CPU_VAR（irq_count）
/* Restore saved previous stack */
popq %rsi
CFI_DEF_CFA rsi，SS+8-RBP /* reg/off reset after def_cfa_expr */
leaq ARGOFFSET-RBP（%rsi）， %rsp
CFI_DEF_CFA_REGISTER rsp
CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET
。。。
retint_careful：
CFI_RESTORE_STATE
bt $TIF_NEED_RESCHED，%edx
jnc retint_signal
TRACE_IRQS_ON
ENABLE_INTERRUPTS（CLBR_NONE）
pushq_cfi %rdi
SCHEDULE_USER
popq_cfi %rdi
GET_THREAD_INFO（%rcx）
DISABLE_INTERRUPTS（CLBR_NONE）
TRACE_IRQS_OFF
jmp retint_check
這其實是用戶態進程在用戶態被中斷打斷後，從中斷返回的流程，結合retint_careful+0x14/0x32，進行反匯編，可以確認阻塞的點其實就在
SCHEDULE_USER
這其實就是調用schele（）進行調度，也就是說當進程走到中斷返回的流程中時，發現需要調度（設置了TIF_NEED_RESCHED），於是在這里發生了調度。
有一個疑問：為什麼在堆棧中看不到schele（）這一級的棧幀呢？
因為這里是匯編直接調用的，沒有進行相關棧幀壓棧和上下文保存操作。
2）進行狀態信息分析
從top命令結果看，相關線程實際一直處於R狀態，CPU幾乎完全耗盡，而且絕大部分都消耗在用戶態：
［root@vmc116 ~］# top
top - 09:42:23 up 16 days， 2:21， 23 users， load average： 84.08， 84.30， 83.62
Tasks： 1037 total， 85 running， 952 sleeping， 0 stopped， 0 zombie
Cpu（s）： 97.6%us， 2.2%sy， 0.2%ni， 0.0%id， 0.0%wa， 0.0%hi， 0.0%si， 0.0%st
Mem： 32878852k total， 32315464k used， 563388k free， 374152k buffers
Swap： 35110904k total， 38644k used， 35072260k free， 28852536k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27074 root 20 0 5316m 163m 14m R 10.2 0.5 321:06.17 z_itask_templat
27084 root 20 0 5316m 163m 14m R 10.2 0.5 296:23.37 z_itask_templat
27085 root 20 0 5316m 163m 14m R 10.2 0.5 337:57.26 z_itask_templat
27095 root 20 0 5316m 163m 14m R 10.2 0.5 327:31.93 z_itask_templat
27102 root 20 0 5316m 163m 14m R 10.2 0.5 306:49.44 z_itask_templat
27113 root 20 0 5316m 163m 14m R 10.2 0.5 310:47.41 z_itask_templat
25730 root 20 0 5316m 163m 14m R 10.2 0.5 283:03.37 z_itask_templat
30069 root 20 0 5316m 163m 14m R 10.2 0.5 283:49.67 z_itask_templat
13938 root 20 0 5316m 163m 14m R 10.2 0.5 261:24.46 z_itask_templat
16326 root 20 0 5316m 163m 14m R 10.2 0.5 150:24.53 z_itask_templat
6795 root 20 0 5316m 163m 14m R 10.2 0.5 100:26.77 z_itask_templat
27063 root 20 0 5316m 163m 14m R 9.9 0.5 337:18.77 z_itask_templat
27065 root 20 0 5316m 163m 14m R 9.9 0.5 314:24.17 z_itask_templat
27068 root 20 0 5316m 163m 14m R 9.9 0.5 336:32.78 z_itask_templat
27069 root 20 0 5316m 163m 14m R 9.9 0.5 338:55.08 z_itask_templat
27072 root 20 0 5316m 163m 14m R 9.9 0.5 306:46.08 z_itask_templat
27075 root 20 0 5316m 163m 14m R 9.9 0.5 316:49.51 z_itask_templat
。。。
3）進程調度信息
從相關線程的調度信息看：
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15681811525768 129628804592612 3557465
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15682016493013 129630684625241 3557509
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15682843570331 129638127548315 3557686
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15683323640217 129642447477861 3557793
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15683698477621 129645817640726 3557875
發現相關線程的調度統計一直在增加，說明相關線程一直是在被調度運行的，結合其狀態也一直是R，推測很可能在用戶態發生了死循環（或者非睡眠死鎖）。
這里又有問題：為什麼從top看每個線程的CPU佔用率只有10%左右，而不是通常看到的死循環進程導致的100%的佔用率？
因為線程數很多，而且優先順序都一樣，根據CFS調度演算法，會平均分配時間片，不會讓其中一個線程獨佔CPU。結果為多個線程間輪流調度，消耗掉了所有的cpu。。
另一個問題：為什麼這種情況下，內核沒有檢測到softlockup？
因為業務進程的優先順序不高，不會影響watchdog內核線程（最高優先順序的實時線程）的調度，所以不會產生softlockup的情況。
再一個問題：為什麼每次查看線程堆棧時，總是阻塞在retint_careful，而不是其它地方？
因為這里（中斷返回的時候）正是調度的時機點，在其它時間點不能發生調度（不考慮其它情況~），而我們查看線程堆棧的行為，也必須依賴於進程調度，所以我們每次查看堆棧時，正是查看堆棧的進程（cat命令）得到調度的時候，這時正是中斷返回的時候，所以正好看到的阻塞點為retint_careful。
4）用戶態分析
從上面的分析看，推測應該是用戶態發生了死鎖。
用戶態確認方法：
部署debug信息，然後gdb attach相關進程，確認堆棧，並結合代碼邏輯分析。
最終確認該問題確為用戶態進程中產生了死循環。
Ⅱ Linux下多線程和多進程程序的優缺點，各個適合什麼樣的業務場景
多進程比較安全，因為默認情況下不同進程之間的內存是獨立的（如果需要共享內存則需要進行進程間通信）。而多線程下，內存是共享的，這時就比較危險了，你要自己使用鎖、信號量等機制來解決內存塊的同時讀寫和同步等等。如果兩個功能沒有數據需要共享，或只有前後遞進關系，建議使用多進程。如果兩個功能需要同時對一塊數據進行處理（例如需要對資源進行創建和老化刪除），則需要使用多線程，這時可能需要使用鎖等機制來控制線程沖突。
Ⅲ linux如何實現多線程
#/bin/bashall_num=10a=$(date +%H%M%S)for num in `seq 1 ${all_num}`do
sleep 1
echo ${num}
done
b=$(date +%H%M%S)
echo -e "startTime:\t$a"echo -e "endTime:\t$b"
Ⅳ 淺談linux 多線程編程和 windows 多線程編程的異同
linux下線程的實現，linux的線程編程有兩個庫pthread和pth,對於pthread的實現是內核方式的實現，每個線程在kernel中都有task結構與之對應，也就是說用ps命令行是可以看見多個線程，線程的調度也是由內核中的schele進行的。
再來看看Windows的多線程，Windows NT和Windows95是一個搶先型多任務、多線程操作系統。因為它使用搶先型的多任務，所以它擁有與UNIX同樣平滑的處理和進程獨立。多線程就更進一步。一個獨立的程序默認是使用一個線程，不過它可以將自己分解為幾個獨立的線程來執行，例如，其中的一個線程可以發送一個文件到列印機，而另一個可以響應用戶的輸入。這個簡單的程序設計修改可以明顯減少用戶等待的時間，讓用戶無需擔心長時間的計算、重繪屏幕、文件讀寫等帶來的不便。
多線程還可以讓你從許多高端的多處理器NT機器中得到好處。例如，你購買了一個高級的RISC機器，可以使用多達10個CPU晶元，但在開始的時候你只購買了一個CPU。你寫了一個簡單的Mandelbrot set程序，你發現需要15秒的時間來重新繪制Mandelbrot set的畫面。
那麼，Windows平台的線程和類Unix平台（包括Linux）的進程的區別是什麼呢？
熟悉WIN32編程的人一定知道，WIN32的進程管理方式與UNIX上有著很大區別，在UNIX里，只有進程的概念，但在WIN32里卻還有一個「線程」的概念，那麼UNIX和WIN32在這里究竟有著什麼區別呢？
UNIX里的fork是七十年代UNIX早期的開發者經過長期在理論和實踐上的艱苦探索後取得的成果，一方面，它使操作系統在進程管理上付出了最小的代價，另一方面，又為程序員提供了一個簡潔明了的多進程方法。
WIN32里的進程/線程是繼承自OS/2的。在WIN32里，「進程」是指一個程序，而「線程」是一個「進程」里的一個執行「線索」。從核心上講，WIN32的多進程與UNIX並無多大的區別，在WIN32里的線程才相當於UNIX的進程，是一個實際正在執行的代碼。但是，WIN32里同一個進程里各個線程之間是共享數據段的。這才是與UNIX的進程最大的不同。
對於多任務系統，共享數據區是必要的，但也是一個容易引起混亂的問題，在WIN32下，一個程序員很容易忘記線程之間的數據是共享的這一情況，一個線程修改過一個變數後，另一個線程卻又修改了它，結果引起程序出問題。但在UNIX下，由於變數本來並不共享，而由程序員來顯式地指定要共享的數據，使程序變得更清晰與安全。
Ⅳ Linux下多線程和多進程程序的優缺點，各個適合什麼樣的業務場景
IBM有個傢伙做了個測試，發現切換線程context的時候，windows比linux快一倍多。進出最快的鎖（windows2k的 critical section和linux的pthread_mutex），windows比linux的要快五倍左右。當然這並不是說linux不好，而且在經過實際編程之後，綜合來看我覺得linux更適合做high performance server，不過在多線程這個具體的領域內，linux還是稍遜windows一點。這應該是情有可原的，畢竟unix家族都是從多進程過來的，而 windows從頭就是多線程的。
如果是UNIX/linux環境，採用多線程沒必要。
多線程比多進程性能高？誤導！
應該說，多線程比多進程成本低，但性能更低。
在UNIX環境，多進程調度開銷比多線程調度開銷，沒有顯著區別，就是說，UNIX進程調度效率是很高的。內存消耗方面，二者只差全局數據區，現在內存都很便宜，伺服器內存動輒若干G，根本不是問題。
多進程是立體交通系統，雖然造價高，上坡下坡多耗點油，但是不堵車。
多線程是平面交通系統，造價低，但紅綠燈太多，老堵車。
我們現在都開跑車，油（主頻）有的是，不怕上坡下坡，就怕堵車。
高性能交易伺服器中間件，如TUXEDO，都是主張多進程的。實際測試表明，TUXEDO性能和並發效率是非常高的。TUXEDO是貝爾實驗室的，與UNIX同宗，應該是對UNIX理解最為深刻的，他們的意見應該具有很大的參考意義。
多線程的優點：
無需跨進程邊界；
程序邏輯和控制方式簡單；
所有線程可以直接共享內存和變數等；
線程方式消耗的總資源比進程方式好；
多線程缺點：
每個線程與主程序共用地址空間，受限於2GB地址空間；
線程之間的同步和加鎖控制比較麻煩；
一個線程的崩潰可能影響到整個程序的穩定性；
到達一定的線程數程度後，即使再增加CPU也無法提高性能，例如Windows Server 2003，大約是1500個左右的線程數就快到極限了（線程堆棧設定為1M），如果設定線程堆棧為2M，還達不到1500個線程總數；
線程能夠提高的總性能有限，而且線程多了之後，線程本身的調度也是一個麻煩事兒，需要消耗較多的CPU
多進程優點：
每個進程互相獨立，不影響主程序的穩定性，子進程崩潰沒關系；
通過增加CPU，就可以容易擴充性能；
可以盡量減少線程加鎖/解鎖的影響，極大提高性能，就算是線程運行的模塊演算法效率低也沒關系；
每個子進程都有2GB地址空間和相關資源，總體能夠達到的性能上限非常大
多線程缺點：
邏輯控制復雜，需要和主程序交互；
需要跨進程邊界，如果有大數據量傳送，就不太好，適合小數據量傳送、密集運算
多進程調度開銷比較大；
最好是多進程和多線程結合，即根據實際的需要，每個CPU開啟一個子進程，這個子進程開啟多線程可以為若干同類型的數據進行處理。當然你也可以利用多線程+多CPU+輪詢方式來解決問題……
方法和手段是多樣的，關鍵是自己看起來實現方便有能夠滿足要求，代價也合適。
Ⅵ 現在的多核CPU，Linux操作系統是否能夠實現單個進程（多線程）的多核調度（跨CPU核心調度）
現在的技術，還是一個線程只能運行在一個 CPU 上。多核心，必須用多線程/進程來運行才能實現最大化。當然，你可以單個線程不停的在所有的 CPU 上來回跳。但是效率會很低很低。
因為 CPU 有寄存器和緩存的問題。如果你切換 CPU 運行，所有的數據都要進行一次傳遞。非常浪費時鍾（在 CPU 上，程序執行不是一個時鍾馬上就能任意執行一個指令，而是流水線作業，一個指令需要很多個時鍾才能處理完，數據存取也都要等）。
這也因為程序原本就都是順序執行的。你沒辦法讓一個程序的後面的結果可以跳過前面的結果而得出。
當然，現在 CPU 確實有這種技術，叫做亂序執行。也就是當前面的過程還沒有計算時，後面的指令先計算。但是這種事情是要靠猜測的，而且這也僅僅是分支預測，依然不能預測某個計算的結果。即便猜的再准確，也有錯的時候。奔騰4 最老的版本就有這個問題，流水線太長。計算後發現錯了。整條流水線需要清空重新計算。有嚴重性能問題的奔騰4 CPU ，流水線長度是 31 級。也就是一個程序至少 31 個時鍾周期才能從推到流水線後到真正執行。直接浪費了 31 個時鍾周期。
所以目前的技術來說，單線程多核新協同計算，技術上不可能實現。
提高性能，就是整理數據處理的演算法，把多次重復計算的過程，拆成多條線程分別計算。從而保證 CPU 多核新的效率最大化。每個線程可以共享同一塊數據，自己讀取自己的數據計算使可以的。不過，這時候就有另外一個問題，數據定址和傳遞的性能問題。
Ⅶ Linux系統進程調度
主要參考 ：Linux manual page - sched
自從linux內核2.6.23以來，默認的進程調度器就被設置為完全公平調度器（CFS，complete fair scheler），取代了之前的O(1)調度器。
每個線程都有一個靜態調度優先順序，即 sched_priority 欄位。
一個線程的調度策略決定了線程會被插入到同級靜態優先順序的線程隊列的位置，以及它在隊列中會怎樣移動。
所有的調度都是可插入的，如果一個更高靜態優先順序的線程准備好了，現在運行中的線程就會被插入。而調度策略則僅僅影響了同樣靜態優先順序的線程。
進程（線程）可以通過系統調用設置自身或者其他進程（線程）的調度策略。
其中 pid 為0時，設置自身的調度策略和參數。結構體 sched_attr 包含以下欄位： size 、 sched_policy （即調度策略，具體會在下一節介紹）、 sched_flags 、 sched_nice 、 sched_runtime 、 sched_deadline 、 sched_period （最後三個為 SCHED_DEADLINE 相關的參數）。當設置成功，系統調用返回0；否則返回-1，並會設置 errno 。
普通進程： SCHED_OTHER / SCHED_BATCH / SCHED_IDLE
實時進程： SCHED_FIFO / SCHED_RR
特殊實時進程： SCHED_DEADLINE
靜態優先順序：Static_priority：對於普通進程，靜態優先順序為0；對於實時進程，靜態優先順序為1-99，99為最高優先順序。
動態優先順序：Dynamic_priority：僅對普通進程有用，取決於nice和一個動態調整的量（比如進程ready卻沒被調度，則增加）。
Ⅷ 如何進行Linux下多線程的調試
方法一：PS
在ps命令中，「-T」選項可以開啟線程查看。下面的命令列出了由進程號為專<pid>的進程創建屬的所有線程。
1.$ ps -T -p <pid>
「SID」欄表示線程ID，而「CMD」欄則顯示了線程名稱。
方法二： Top
top命令可以實時顯示各個線程情況。要在top輸出中開啟線程查看，請調用top命令的「-H」選項，該選項會列出所有Linux線程。在top運行時，你也可以通過按「H」鍵將線程查看模式切換為開或關。
1.$ top -H
要讓top輸出某個特定進程<pid>並檢查該進程內運行的線程狀況：
$ top -H -p <pid>