• limit 命令詳解

  • 語法

  • **參數**：

  • 參數詳解

• 小結下 limit 配置過程中容易跳的坑

說來慚愧,我被ulimit摔了一跤...

自接觸 linux 后，大家所受的教育就是 ulimit是最便捷的內核優化途徑，事實也確實如此。

這次摔跤也是基礎知識遺忘，所以特地總結下。「反正每次寫文檔都忍不住吐槽國內博客技術文檔，大家相互抄，最后錯的都能變成對的...」。文末有高并發業務，32c64g硬件配置的ulimit 配置推薦

從下圖開始，如果如下幾個問題都能正確回答，就可以關閉文章了：

ulimit -a 設置的 open files 為什么是 65535, 這個數字從何而來，有何依據

為什么 open files 顯示的是 65535, 而 lsof -u www | wc -l 顯示的卻有 3145600,但仍然能 su - www成功，不應該超過 65535后，就應該提示 ?resource limit 錯誤嗎？

ulimit問題截圖.png

其實如上兩個問題都是很基礎的問題。

先說 65535 從何而來。從我能追溯到的文章來看，比較合理的解釋是，在真實 32 位操作系統還存在時， 2^16-1 是 65535, 即系統預留16位給自己使用，最多提供16位給用戶程序。在32位系統中，select()函數甚至做了硬上限規定。當然，這僅限于32位系統，現今64位系統不存在65535上限問題。即可大于該數值。

一些對句柄數有嚴重依賴的新秀開源軟件，也在官網文檔中明確聲明 max open files 數值，以 swoole為例，建議配置為20w +, 遠超 65535 。

至于，為什么現今互聯網所有文檔中依然沿用 65535 ，大概率是“抄襲” 遺留的問題。so...

第二個問題，為什么已經最大文件句柄數已經超限，但還能su - www。這里要復習下 ulimit 的知識了。

limit 命令詳解

語法

ulimit?[-aHS][-c?][-d?][-f?][-m?][-n?][-p?][-s?][-t?][-u?][-v?]

參數：

• -a 　顯示目前資源限制的設定。
• -c 　設定core文件的最大值，單位為區塊。
• -d 　程序數據節區的最大值，單位為KB。
• -f 　shell所能建立的最大文件，單位為區塊。
• -H 　設定資源的硬性限制，也就是管理員所設下的限制。
• -m 　指定可使用內存的上限，單位為KB。
• -n 　指定同一時間最多可開啟的文件數。
• -p 　指定管道緩沖區的大小，單位512字節。
• -s 　指定堆疊的上限，單位為KB。
• -S 　設定資源的彈性限制。
• -t 　指定CPU使用時間的上限，單位為秒。
• -u 　用戶最多可開啟的程序數目。
• -v 　指定可使用的虛擬內存上限，單位為KB。

參數詳解

core?file?size???????????(blocks,?-c)?0
data?seg?size????????????(kbytes,?-d)?unlimited??#?一個進程的數據段的最大值
scheduling?priority??????????????(-e)?0
file?size????????????????(blocks,?-f)?unlimited??#?Shell創建文件的最大體積,?1block?=?512bytes
pending?signals??????????????????(-i)?1031426????#?最多允許多少個待處理的信號
max?locked?memory????????(kbytes,?-l)?64?????????#?每個進程可以鎖住的物理內存的最大值
max?memory?size??????????(kbytes,?-m)?unlimited??#?每個進程可以使用的常駐內存的最大值
open?files???????????????????????(-n)?65535??????#?每個進程可以同時打開的最大文件數,?不能是unlimited
pipe?size?????????????(512?bytes,?-p)?8??????????#?管道的最大值,?1block?=?512bytes
POSIX?message?queues??????(bytes,?-q)?819200?????#?POSIX的消息隊列的最大值
real-time?priority???????????????(-r)?0
stack?size???????????????(kbytes,?-s)?10240??????#?單個進程能夠使用的最大棧大小
cpu?time????????????????(seconds,?-t)?unlimited??#?單個進程的最大CPU時間,?也就是可使用CPU的秒數,?到硬極限時,?這個進程就會立即自殺;?到軟極限時,?每秒發送一次限制超時信號SIGXCPU
max?user?processes???????????????(-u)?131072?????#?單個用戶可同時運行的最大進程數,?不能是unlimited
virtual?memory???????????(kbytes,?-v)?unlimited??#?每個進程可使用的最大虛擬內存
file?locks???????????????????????(-x)?unlimited??#?每個進程能鎖住的最大文件個數

open files 設置的65556` ?是單進程可打開的最大文件句柄數，即用戶可打開的最大文件句柄數是:

(max?user?processes)?*?(max?open?files)

so...

圖中雖然 www 用戶打開了 3145600 個文件句柄數, 但如果

沒有超過系統最大句柄數限制, 即 (max user processes) * (max open files)；

沒有超過 max user processes 限制；

沒有超過單進程最大句柄數設置，即65535；

則，應用均可正常運行。

那如何統計用戶已打開的文件句柄數及用戶已打開的進程數呢？

• 統計www用戶打開的進程數

  #?lsof?-u?www?|?awk?'{print?$2}'?|?uniq?-c?|?wc?-l
  

• 統計www用戶打開的占用的所有文件句柄數

#?lsof?-u?www?|?wc?-l

小結下 limit 配置過程中容易跳的坑

• 兩個生效方式：永久生效和臨時生效

永久生效：配置文件 /etc/sysctl.conf 或 /etc/security/*.conf , sysctl -p 永久生效

臨時生效：ulimit -SHn 65535

• 配置優先級

ulimit 命令 > /etc/security/*.conf > /etc/sysctl.conf

敲黑板

尤其是 /etc/security/*.conf 的優先級高于 /etc/sysctl.conf... 這里非常容易誤導

應用內置的ulimit 設置 > 運行用戶的系統 ulimit 設置

以如圖mongodb啟動腳本為例，如果在啟動腳本中專門設置了 ulimit ，則以ulimit 為準。

02-mongodb啟動腳本.png

類似的配置如 nginx 的 worker_rlimit_nofile 配置。

• 失效背景

Centos 6 和7 配置 ulimit 區別

Centos 7 systemd 接管系統后，削弱了對 /etc/sysctl.conf的權限。關注 ?/etc/security/limits.conf 和 /etc/security/limit.d/*.conf 的配置。基本不會出差。

Daemon 進程 ulimit 失效

敲黑板

ulimit 生效針對的是運行在當前執行 Ulimit 命令的bash shell。即，以 daemon 運行的進程啟動時，bash shell的環境變量對其無效。

#?man?ulimit
.
.
.
ulimit?[-HSTabcdefilmnpqrstuvx?[limit]]
??????????????Provides?control?over?the?resources?available?to?the?shell?and?to?processes?started??by??it,??on??systems??that??allow??such??control.

• 查看系統和進程的ulimit 設置

#?cat?/proc/sys/fs/file-max??#?查看系統?max?files?設置
#?cat?/proc/$fpid/limits???#?查看進程?limit?配置

最后提供一個高并發業務 的ulimit 的配置模板:

配置/etc/sysctl.conf

設置 fs.file-max = 6553560 ?即 650w， 從我們現有的業務來看，32c64g的服務器，配置了1200 php-fpm和 1000線程 swoole。系統總的句柄消耗達到了 320w+。

配置/etc/security/limits.conf

*?soft?nofile?65535
*?hard?nofile?65535
*?soft?noproc?65535
*?hard?noproc?65535
root?soft?nofile?65535
root?hard?nofile?65535
root?soft?noproc?65535
root?hard?noproc?65535

一定要配置/etc/security/limits.d/90-nproc.conf

*??????????soft????nproc?????65535
root???????soft????nproc?????65535

~ over

總結

以上是生活随笔為你收集整理的ulimit限制 新系统_说来惭愧,我被ulimit摔了一跤...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。