这次摔跤也是根本知识遗忘,以是特地总结下。「反正每次写文档都忍不住吐槽海内博客技能文档,大家相互抄,末了错的都能变成对的...」。文末有高并发业务,32c64g硬件配置的ulimit 配置推举
从下图开始,如果如下几个问题都能精确回答,就可以关闭文章了:
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<core文件上限>][-d<数据节区大小>][-f<文件大小>][-m<内存大小>][-n<文件数目>][-p<缓冲区大小>][-s<堆叠大小>][-t<CPU韶光>][-u<程序数目>][-v<虚拟内存大小>]
参数:-a 显示目前资源限定的设定。-c <core文件上限> 设定core文件的最大值,单位为区块。-d <数据节区大小> 程序数据节区的最大值,单位为KB。-f <文件大小> shell所能建立的最大文件,单位为区块。-H 设定资源的硬性限定,也便是管理员所设下的限定。-m <内存大小> 指定可利用内存的上限,单位为KB。-n <文件数目> 指定同一韶光最多可开启的文件数。-p <缓冲区大小> 指定管道缓冲区的大小,单位512字节。-s <堆叠大小> 指定堆叠的上限,单位为KB。-S 设定资源的弹性限定。-t <CPU韶光> 指定CPU利用韶光的上限,单位为秒。-u <程序数目> 用户最多可开启的程序数目。-v <虚拟内存大小> 指定可利用的虚拟内存上限,单位为KB。参数详解
corefilesize(blocks,-c)0datasegsize(kbytes,-d)unlimited#一个进程的数据段的最大值schedulingpriority(-e)0filesize(blocks,-f)unlimited#Shell创建文件的最大体积,1block=512bytespendingsignals(-i)1031426#最多许可多少个待处理的旗子暗记maxlockedmemory(kbytes,-l)64#每个进程可以锁住的物理内存的最大值maxmemorysize(kbytes,-m)unlimited#每个进程可以利用的常驻内存的最大值openfiles(-n)65535#每个进程可以同时打开的最大文件数,不能是unlimitedpipesize(512bytes,-p)8#管道的最大值,1block=512bytesPOSIXmessagequeues(bytes,-q)819200#POSIX的行列步队的最大值real-timepriority(-r)0stacksize(kbytes,-s)10240#单个进程能够利用的最大栈大小cputime(seconds,-t)unlimited#单个进程的最大CPU韶光,也便是可利用CPU的秒数,到硬极限时,这个进程就会立即自尽;到软极限时,每秒发送一次限定超时旗子暗记SIGXCPUmaxuserprocesses(-u)131072#单个用户可同时运行的最大进程数,不能是unlimitedvirtualmemory(kbytes,-v)unlimited#每个进程可利用的最大虚拟内存filelocks(-x)unlimited#每个进程能锁住的最大文件个数
open files 设置的65556` 是单进程可打开的最大文件句柄数,即用户可打开的最大文件句柄数是:
(maxuserprocesses)(maxopenfiles)
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-uwww|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的环境变量对其无效。
#manulimit...ulimit[-HSTabcdefilmnpqrstuvx[limit]]Providescontrolovertheresourcesavailabletotheshellandtoprocessesstartedbyit,onsystemsthatallowsuchcontrol.
查看系统和进程的ulimit 设置
#cat/proc/sys/fs/file-max#查看系统maxfiles设置#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.confsoftnproc65535rootsoftnproc65535