ulimit限制 新系统_说来惭愧,我被ulimit摔了一跤...
limit 命令詳解
語法
**參數**:
參數詳解
小結下 limit 配置過程中容易跳的坑
說來慚愧,我被ulimit摔了一跤...
自接觸 linux 后,大家所受的教育就是 ulimit是最便捷的內核優化途徑,事實也確實如此。
這次摔跤也是基礎知識遺忘,所以特地總結下。「反正每次寫文檔都忍不住吐槽國內博客技術文檔,大家相互抄,最后錯的都能變成對的...」。文末有高并發業務,32c64g硬件配置的ulimit 配置推薦
從下圖開始,如果如下幾個問題都能正確回答,就可以關閉文章了:
其實如上兩個問題都是很基礎的問題。
先說 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)?0data?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 個文件句柄數, 但如果
則,應用均可正常運行。
那如何統計用戶已打開的文件句柄數及用戶已打開的進程數呢?
統計www用戶打開的進程數
#?lsof?-u?www?|?awk?'{print?$2}'?|?uniq?-c?|?wc?-l統計www用戶打開的占用的所有文件句柄數
小結下 limit 配置過程中容易跳的坑
- 兩個生效方式:永久生效和臨時生效
永久生效:配置文件 /etc/sysctl.conf 或 /etc/security/*.conf , sysctl -p 永久生效
臨時生效:ulimit -SHn 65535
- 配置優先級
敲黑板
尤其是 /etc/security/*.conf 的優先級高于 /etc/sysctl.conf... 這里非常容易誤導
以如圖mongodb啟動腳本為例,如果在啟動腳本中專門設置了 ulimit ,則以ulimit 為準。
02-mongodb啟動腳本.png類似的配置如 nginx 的 worker_rlimit_nofile 配置。
- 失效背景
Centos 7 systemd 接管系統后,削弱了對 /etc/sysctl.conf的權限。關注 ?/etc/security/limits.conf 和 /etc/security/limit.d/*.conf 的配置。基本不會出差。
敲黑板
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/$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
root???????soft????nproc?????65535
~ over
總結
以上是生活随笔為你收集整理的ulimit限制 新系统_说来惭愧,我被ulimit摔了一跤...的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 可乐为什么要加咖啡因?
- 下一篇: 计算机三级网络接口,计算机三级网络技术操