点击上方“程序员大白”，选择“星标”公众号
重磅干货，第一时间送达
原文地址：https://adlternative.github.io/resource-limit/
在我们写程序的时候往往都没有注意到一些系统资源的临界值，然而这些临界值在有的时候会把我们害的很惨，比如一个忘掉关闭的文件描述符，比如malloc竟然会返回错误，又或者是爆栈，我们该如何解决或者说预防这些问题呢？
ulimit 命令可以查看用户层面的系统资源限制。这是在 /etc/security/limits.conf 的描述:-----------------------------------------------------
该文件为通过PAM登录的用户设置资源限制。
它不会影响系统服务的资源限制。
还要注意 /etc/security/limits.d 目录中的配置文件，以字母顺序阅读的内容，请覆盖此设置域相同或更具体的情况下使用文件。例如，这意味着在此处设置通配符域的限制可以使用配置文件中的通配符设置覆盖子目录，但此处的用户特定设置只能被覆盖在子目录中具有特定于用户的设置。-----------------------------------------------------
所以 ulimit 的确是观察用户层面的资源限制。
我们可以通过 ulimit -a 查看我们所有的资源上限：
只说其中我们比较关注的那些：
-s 栈大小:8MB
-u 进程上限:30000多
-n 文件描述符上限:1024
同时你可以用ulimit -Ha或ulimit -Sa查看硬限制和软限制，硬限制是指对资源节点和数据块的绝对限制，由 root 用户设置硬限制。虽然其他用户可以降低硬限制，但只有 root 用户可以增加硬限制。至于软限制，网上资料也没有说什么，大概就是非root用户不能超过软限制，但是非root用户可以做的是将其软限制增加到其硬限制。我们的服务器程序可能有打开超过1024个文件描述符，有没有办法修改这些资源的上限呢？E.g. ulimit -n 1024可以修改系统对文件描述符的限制，不过是临时当前的shell生效的,如果你使用which ulimit你会发现ulimit是一个shell built-in command的脚本。我们应该修改 /etc/security/limits.conf 去让我们的修改永久生效。(需要重新启动,可能有直接加载配置的方法，暂时不知道)在/etc/security/limits.conf中添加以下片段：
说明修改成功。那么现在我们测试下我们的程序能否打开这么多个文件描述符？做个小测试，下面就是打开10240个临时文件，这里我们期待错误 EFILE：在修改之前是ulimit的默认值是1024,然后测试出的最大打开文件描述符的数量是1001,现在是修改为10240后可以打开10217个文件描述符，实验成功。然后我们能打开的总数为什么不是刚好10240呢？这个问题是因为程序自身打开了一些文件或是加载了一些动态库,stdin/stdout/stderr,以及 /etc/ld.so.cache，/usr/lib/libm.so.6，/usr/lib/libstdc++.so.6...同样还是在/etc/security/limits.conf添加这样两句：
但这里也只能保守的说：调整以后的一个进程的栈空间大概在 8192000B 这附近。单个进程打开文件句柄数上限 最大文件描述符数 10亿。
file-max是在内核级别强制执行的最大文件描述符（FD），上限600万。
已分配的文件文件描述符数，已分配但未使用的文件描述符数以及最大文件描述符数(不可调)。
你觉得资源限制和你没有关系？在你打开 redis-server 的时候，难道就没有注意到这样的一段：Increased maximum number of open files to 10032 (it was originally set to 1024).
其含义就是将文件描述符从默认的上限调整到10032，为了适应更多的网络连接。其源码中也不过是调用了api:
setrlimit(RLIMIT_NOFILE,&limit)
去进行了资源上限的临时调整，此处不细讲。
最后介绍另外一个类似ulimit的命令prlimit：
linux的资源限制不能说很奇妙吧，但确实值得做linux服务端编程的程序员们需要注意，同时我们可以通过在 /etc/security/limits.conf 去修改资源的上限。忽然想到上次问学长：为什么linux下需要对这些资源进行限制？都调整为ulimited不是很好么？
可以说我们的linux机器之所以限制这些资源的上限，是希望我们能够充分利用它，把它的性能发挥到极致，而不是让CPU或者文件等资源在那里闲置着，浪费计算机的生命。
