目錄
toc \o "1-3" \h \z \u linux執行緒（程序）數限制
....
pageref _toc447043843 \h 1
目錄....
pageref _toc447043844 \h 2
1.問題**
....
pageref _toc447043845 \h 2
2.初步原因分析和解決
....
pageref _toc447043846 \h 2
3.linux執行緒數的限制
....
pageref _toc447043847 \h 3
3.1應用層測試**
...
pageref _toc447043848 \h 3
3.2逆向分析
...
pageref _toc447043849 \h 4
3.3正向分析
...
pageref _toc447043850 \h 6
3.3.1
記憶體限制
...
pageref _toc447043851 \h 6
3.3.2threads-max引數限制
...
pageref _toc447043852 \h 6
3.3.3pid_max引數限制
...
pageref _toc447043853 \h 7
3.3.4
單程序記憶體限制
...
pageref _toc447043854 \h 7
4.總結
....
pageref _toc447043855 \h 7
公司線上環境出現mq不能接受訊息的異常，運維和開發人員臨時切換另一台伺服器的mq後恢復。同時運維人員反饋在出現問題的伺服器上很多基本的命令都不能執行，出現如下錯誤：
讓運維的兄弟在服務上檢視記憶體、cpu、網路、io等基本資訊都正常。於是自己到運維的伺服器上看了一下，下面是slabtop –s c的執行結果，問題初步原因貌似出現了：
如果看到這個截圖你看不出什麼異常的話，下面的內容你可能不感興趣，哈哈。。。
task_struct是核心對程序的管理單位，通過slub(slab的公升級版，如果你對slub不了解也不影響下面的內容，只要了解slab就行了)進行節點的管理，正常負載的服務不應該出現task_struct的slub結構體占用記憶體最大的情況，這說明這台伺服器上開啟了大量的程序（linux核心態對程序和執行緒都是乙個單位，不要糾結這個，後面可能會程序、執行緒混用）。
通過這個資訊，兄弟們發現這台伺服器上有近3萬個執行緒，同時也定位到出問題的網元（乙個新同學的**沒有review直接上線，裡面有乙個bug觸發了異常建立大量執行緒）。
問題貌似到這裡就結束了，但是作為乙個有情懷的程式設計師，這只是乙個開始（哥的情懷白天都被繁瑣的工作磨沒了，只能在這深夜獨享了。。。）
#include
#include
#include
#include
#include
#define memsize (1024 * 1024 * 256)
void thread(void)
sleep(100);
return;
int main()
pthread_t id;
intret;
intnum = 0;
while(1) /memory.kmem#
單個docker
核心記憶體的限制，可以影響
task_struct
等slab
節點的申請，間接影響可建立的執行緒數
linux程序數限制
rhel6裡面的程序數限制 為了防止fork bomb的出現，rhel6對普通使用者的程序數進行了限制，限制檔案為 etc security limits.d 90 nproc.conf 該檔案的內容為 default limit for number of user s processes to ...
Linux系統和使用者執行緒數程序數限制查詢
查系統支援的最大執行緒數，一般會很大，相當於理論值 donald draper server cat proc sys kernel pid max 32768 程序允許的最大記憶體 donald draper server cat proc sys vm max map count 2000000...
Linux最大執行緒數限制
開始以為是記憶體不足導致無法建立執行緒，把jvm的 xms，xmx的2個引數都加大一倍 xms2048m xmx2048m。把 xss引數調小，還是啟動失敗。應該是系統方面的限制了，這台機器上搞了100個過tomcat程序，還有不少其他軟體，東西比較多且雜。確認過機器的記憶體還是足夠的，先排查系統引...