答案是配置ulimit需区分临时与永久方式，临时用ulimit命令调整会话级限制，永久则修改limits.conf或Systemd服务文件。临时设置如ulimit -n 65535立即生效但重启失效；永久生效需在/etc/security/limits.conf中为用户或组设置soft/hard限制，并确保pam_limits.so加载；对于Systemd服务，应在.service文件中使用LimitNOFILE等参数定义，再执行systemctl daemon-reload和restart服务生效。常见问题包括未重新登录、PAM配置缺失、Systemd覆盖limits.conf及混淆soft与hard limit，其中hard limit为上限，soft limit可在此范围内调整。
在Linux系统里，配置
ulimit限制资源，说白了，就是给你的进程或者用户划定一个资源使用的上限。如果你只是想在当前会话里临时调整，那直接在shell里用
ulimit命令就行，它会立刻生效，但一关掉终端或者退出会话就失效了。要是想让这个限制长久地、系统性地生效，那你就得去改
limits.conf这个配置文件，甚至可能还要动到Systemd的服务单元文件，这需要重启会话或者服务才能看到效果。
解决方案
要搞定
ulimit，我们通常会从两个维度入手：临时的会话级调整和永久的系统级配置。
先说临时配置，这个最简单直接。你打开一个终端，想看看当前会话有什么限制，敲个
ulimit -a就全出来了。比如，你发现默认的打开文件数（
open files）是1024，这对于一些高并发的服务来说，简直就是个笑话。想临时提高？很简单，比如改成65535：
ulimit -n 65535
这里的
-n就是指文件描述符的数量（number of open files）。类似的，如果你想限制一个用户能启动的进程数（number of processes），可以用
-u：
ulimit -u 4096
这些命令执行后，立刻在当前shell会话及其子进程中生效。你再跑个
ulimit -a，就能看到变化了。但切记，这玩意儿是“一次性”的，终端一关，或者你新开一个终端，这些设置就都没了，又回到系统默认值或者
/etc/security/limits.conf里定义的那些。
然后是永久配置，这才是我们日常运维里更常用的。核心文件是
/etc/security/limits.conf。这个文件是PAM（Pluggable Authentication Modules）模块
pam_limits.so在用户登录时读取的。它的格式大致是这样的：
## * means all users except root * soft nofile 65535 * hard nofile 131070 # @developers group can open more files @developers soft nofile 100000 @developers hard nofile 200000 # specific user 'nginx' nginx soft nofile 65535 nginx hard nofile 65535
这里面的
domain可以是用户名、组名（前面加
@）、或者
*（代表所有非root用户）。
type有两种：
soft（软限制）和
hard（硬限制），我后面会详细解释。
item就是你要限制的项目，比如
nofile（文件描述符）、
nproc（进程数）、
core（core文件大小）等。
value就是具体的数值。
改完这个文件，你需要让用户登出再重新登录，或者重启相关服务，这些新的限制才能被PAM模块加载并应用。有时候，你可能还会发现
limits.conf里的设置没生效，这往往和PAM的配置有关，需要确保
/etc/pam.d/common-session或者
/etc/pam.d/login这些文件里有
session required pam_limits.so这一行。这就像是告诉系统，登录的时候记得去看看
limits.conf。
但如果你的应用是作为Systemd服务运行的，比如Nginx、Redis这类，它们通常不是直接通过用户登录会话启动的，这时候
limits.conf的优先级可能就不那么高了。对于Systemd服务，更直接、更可靠的方式是在它的
.service单元文件里直接设置。
为什么我的ulimit设置没有生效？
这绝对是初学者和老手都可能踩的坑，我个人就遇到过不少。当你满心欢喜地改了配置，却发现
ulimit -a显示的值还是老样子，那种感觉真是让人抓狂。
首先，最常见的原因是你没有重新登录会话。
limits.conf的设置是通过PAM模块在用户登录时读取并应用的。如果你只是改了文件，然后在一个已经打开的终端里跑命令，那自然看不到效果。你得完全登出当前用户，再重新登录。对于SSH会话，就是断开SSH连接再重新连上。
其次，PAM模块的配置可能不正确。就像我前面提到的，
pam_limits.so必须在PAM配置文件中被引用。你可能需要检查
/etc/pam.d/common-session、
/etc/pam.d/login、
/etc/pam.d/sshd等文件，确保其中包含类似
session required pam_limits.so的行。如果缺少了，系统就不知道要去加载
limits.conf里的限制。
再来，你可能在查看一个错误的上下文。比如，你为
nginx用户设置了
nofile限制，但你却在
root用户的会话里查看，或者在另一个没有关联的用户会话里查看，那肯定是不对的。确保你是在目标用户身份下，或者目标服务进程的上下文下去验证。
还有一种情况是，Systemd服务单元文件中的限制覆盖了limits.conf
。如果你的应用是以Systemd服务运行的，比如Nginx，即使你在
limits.conf里给
nginx用户设置了很高的文件描述符限制，但如果Nginx的Systemd服务文件（比如
/etc/systemd/system/nginx.service）里有
LimitNOFILE=1024这样的设置，那么服务启动时会优先采用Systemd的限制。这是Systemd自己的资源管理机制，优先级更高。
最后，要区分软限制（soft limit）和硬限制（hard limit）。你可能只看到了软限制，而没有注意到硬限制。一个进程的软限制不能超过其硬限制。如果你把软限制设置得很高，但硬限制却很低，那实际上能达到的上限还是硬限制。
ulimit中的hard limit和soft limit有什么区别？
这块儿挺有意思的，也是理解
ulimit机制的关键。简单来说，
soft limit是当前实际生效的限制，而
hard limit则是一个不可逾越的“天花板”。
软限制（Soft Limit）： 这个是你的进程当前实际能使用的资源上限。比如，
ulimit -n默认显示的就是软限制。一个进程可以自行调整自己的软限制，但它不能超过对应的硬限制。对于普通用户来说，他们可以降低自己的软限制，也可以在不超过硬限制的前提下提高它。比如，你当前软限制是1024，硬限制是65535，你可以用
ulimit -n 2048把软限制提高到2048，但不能直接提高到70000。
硬限制（Hard Limit）： 这个是系统管理员设定的一个绝对上限，是进程能够将软限制提升到的最大值。普通用户只能降低硬限制，不能提高它。只有
root用户或者拥有相应权限的进程才能提高硬限制。它就像一道物理屏障，确保即使进程失控，也不会无限制地消耗系统资源。
在
/etc/security/limits.conf文件中，我们通常会同时设置
soft和
hard两种限制。比如：
* soft nofile 65535 * hard nofile 131070
这意味着，所有非root用户默认的文件描述符软限制是65535，但他们最多可以把这个软限制提升到131070。这个设计很灵活，它允许用户在一定范围内根据需求调整资源，同时又保证了系统整体的稳定性。在我看来，硬限制是系统安全和资源保障的最后一道防线。
针对特定服务或Systemd单元如何设置ulimit？
对于那些作为后台服务运行的应用程序，特别是通过Systemd管理的服务，直接在Systemd单元文件里配置
ulimit是既清晰又可靠的做法。因为这些服务通常不是通过用户登录会话启动的，所以
/etc/security/limits.conf对它们的影响可能就没那么直接了。
Systemd提供了一系列
Limit*指令，可以直接在服务的
.service文件里指定。这使得每个服务都能拥有自己独立的资源限制，而不会相互影响。
比如，你有一个Nginx服务，它需要打开大量文件（连接、日志等），你可以在Nginx的Systemd单元文件（通常在
/etc/systemd/system/nginx.service或
/lib/systemd/system/nginx.service）的
[Service]节中添加如下行：
[Service] ExecStart=/usr/sbin/nginx -g "daemon on; master_process on;" # ... 其他配置 ... LimitNOFILE=65536 LimitNPROC=4096 LimitCORE=infinity
这里的：
LimitNOFILE=65536
：设置了Nginx服务可以打开的最大文件描述符数量为65536。LimitNPROC=4096
：限制了Nginx服务及其子进程可以创建的最大进程数为4096。LimitCORE=infinity
：表示核心文件（core dump）的大小没有限制。如果你想限制它，可以给一个具体数值，比如LimitCORE=1G
。
当你修改了Systemd单元文件后，别忘了执行以下命令来让Systemd重新加载配置并重启服务：
sudo systemctl daemon-reload sudo systemctl restart nginx
这样，Nginx服务启动时就会直接使用这些在单元文件里定义的
ulimit值，而不会去管
limits.conf里对
nginx用户设置的全局限制。在我看来，这种方式为服务提供了更精细、更隔离的资源控制，非常适合生产环境中的关键应用。它避免了因为用户全局限制过低而导致服务启动失败，或者因为全局限制过高而让某个失控的服务消耗过多资源。
