• limit 命令詳解

  • 語法

  • **參數(shù)**：

  • 參數(shù)詳解

• 小結(jié)下 limit 配置過程中容易跳的坑

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

自接觸 linux 后，大家所受的教育就是 ulimit是最便捷的內(nèi)核優(yōu)化途徑，事實(shí)也確實(shí)如此。

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

從下圖開始，如果如下幾個(gè)問題都能正確回答，就可以關(guān)閉文章了：

ulimit -a 設(shè)置的 open files 為什么是 65535, 這個(gè)數(shù)字從何而來，有何依據(jù)

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

ulimit問題截圖.png

其實(shí)如上兩個(gè)問題都是很基礎(chǔ)的問題。

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

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

至于，為什么現(xiàn)今互聯(lián)網(wǎng)所有文檔中依然沿用 65535 ，大概率是“抄襲” 遺留的問題。so...

第二個(gè)問題，為什么已經(jīng)最大文件句柄數(shù)已經(jīng)超限，但還能su - www。這里要復(fù)習(xí)下 ulimit 的知識了。

limit 命令詳解

語法

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

參數(shù)：

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

參數(shù)詳解

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

open files 設(shè)置的65556` ?是單進(jìn)程可打開的最大文件句柄數(shù)，即用戶可打開的最大文件句柄數(shù)是:

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

so...

圖中雖然 www 用戶打開了 3145600 個(gè)文件句柄數(shù), 但如果

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

沒有超過 max user processes 限制；

沒有超過單進(jìn)程最大句柄數(shù)設(shè)置，即65535；

則，應(yīng)用均可正常運(yùn)行。

那如何統(tǒng)計(jì)用戶已打開的文件句柄數(shù)及用戶已打開的進(jìn)程數(shù)呢？

• 統(tǒng)計(jì)www用戶打開的進(jìn)程數(shù)

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

• 統(tǒng)計(jì)www用戶打開的占用的所有文件句柄數(shù)

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

小結(jié)下 limit 配置過程中容易跳的坑

• 兩個(gè)生效方式：永久生效和臨時(shí)生效

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

臨時(shí)生效：ulimit -SHn 65535

• 配置優(yōu)先級

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

敲黑板

尤其是 /etc/security/*.conf 的優(yōu)先級高于 /etc/sysctl.conf... 這里非常容易誤導(dǎo)

應(yīng)用內(nèi)置的ulimit 設(shè)置 > 運(yùn)行用戶的系統(tǒng) ulimit 設(shè)置

以如圖mongodb啟動(dòng)腳本為例，如果在啟動(dòng)腳本中專門設(shè)置了 ulimit ，則以ulimit 為準(zhǔn)。

02-mongodb啟動(dòng)腳本.png

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

• 失效背景

Centos 6 和7 配置 ulimit 區(qū)別

Centos 7 systemd 接管系統(tǒng)后，削弱了對 /etc/sysctl.conf的權(quán)限。關(guān)注 ?/etc/security/limits.conf 和 /etc/security/limit.d/*.conf 的配置。基本不會(huì)出差。

Daemon 進(jìn)程 ulimit 失效

敲黑板

ulimit 生效針對的是運(yùn)行在當(dāng)前執(zhí)行 Ulimit 命令的bash shell。即，以 daemon 運(yùn)行的進(jìn)程啟動(dòng)時(shí)，bash shell的環(huán)境變量對其無效。

#?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.

• 查看系統(tǒng)和進(jìn)程的ulimit 設(shè)置

#?cat?/proc/sys/fs/file-max??#?查看系統(tǒng)?max?files?設(shè)置
#?cat?/proc/$fpid/limits???#?查看進(jìn)程?limit?配置

最后提供一個(gè)高并發(fā)業(yè)務(wù) 的ulimit 的配置模板:

配置/etc/sysctl.conf

設(shè)置 fs.file-max = 6553560 ?即 650w， 從我們現(xiàn)有的業(yè)務(wù)來看，32c64g的服務(wù)器，配置了1200 php-fpm和 1000線程 swoole。系統(tǒng)總的句柄消耗達(dá)到了 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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。