在Linux系统中，”linux unlimited”（即ulimit -n设为unlimited）并非字面意义上的无限大，而是将进程资源限制交由内核态管理，其核心目的是突破文件描述符和进程数的默认瓶颈，保障高并发服务的稳定运行。
什么是linux unlimited：内核态与用户态的博弈
在日常运维中，当我们遇到“Too many open files”报错时，第一反应往往是调大文件描述符限制。ulimit命令用于限制当前shell进程及其子进程的资源使用，将ulimit -n设置为unlimited，意味着告诉内核：不要对这个进程能打开的文件描述符数量施加用户态层面的硬性封顶。
linux unlimited和nofile区别到底在哪
很多运维人员容易把unlimited和nofile混为一谈。nofile是配置文件 /etc/security/limits.conf 中的一个具体限制项，它定义了用户能打开的最大文件数，而unlimited是一个赋值状态。
业内专家指出，高并发架构中文件描述符耗尽是导致服务无响应的常见诱因，当我们设置unlimited时，系统会将该进程的文件描述符上限交由内核参数 fs.file-max 和 fs.nr_open 来兜底管理。
- nofile：用户态层面的具体数值约束（如65535）。
- unlimited：解除用户态约束,将控制权上移至内核态。
为什么默认限制如此保守
Linux系统默认的文件描述符限制通常是1024，这种保守的设计是为了防止单个恶意或失控的进程耗尽系统资源，导致整个操作系统崩溃，据统计，超过六成的Linux服务器性能故障源于不合理的资源配置，如果每个进程都无限制地打开文件,系统内存会被庞大的文件描述符表迅速占满。
centos和ubuntu修改linux unlimited区别及实操对比
不同的Linux发行版在处理PAM（可插拔认证模块）和系统服务管理上存在差异,修改资源限制的路径也不尽相同。
CentOS/RedHat系统下的修改路径
在CentOS 7及以上版本中，要实现linux unlimited配置,需要同时修改PAM配置文件和系统级配置文件。
- 修改
/etc/security/limits.conf：
在文件末尾添加：soft nofile unlimited hard nofile unlimited soft nproc unlimited hard nproc unlimited
- 确认PAM模块加载：
检查/etc/pam.d/system-auth文件，确保包含session required pam_limits.so。
Ubuntu/Debian系统下的修改路径
Ubuntu系统默认使用systemd管理初始化进程，传统的 /etc/security/limits.conf 仅对通过PAM登录的会话生效,对systemd拉起的服务进程无效。
- 修改系统级配置：
除了在/etc/security/limits.conf中添加上述配置外，还需编辑/etc/systemd/system.conf和/etc/systemd/user.conf：DefaultLimitNOFILE=infinity DefaultLimitNPROC=infinity
- 重启服务生效：
执行systemctl daemon-reload重新加载配置,并重启对应的服务进程。
高并发场景下的linux ulimit 设置多少合适
盲目将限制设为unlimited并非最佳实践，行业共识认为，针对核心业务进程，应当采用显式声明而非依赖系统默认值,不同的业务场景对文件描述符的需求量级完全不同。
Web服务器场景配置参考
对于Nginx、Apache等Web服务器,每一个TCP连接都会占用一个文件描述符。
- 日均十万级PV站点：建议设置
nofile 65535即可满足需求。 - 百万级并发长连接服务：建议将
nofile设置为 1048576（即2的20次方），同时必须确保内核参数fs.nr_open大于此值。
数据库场景配置参考
MySQL或PostgreSQL等数据库系统，除了处理客户端连接外,还需要打开大量表文件和临时文件。
- MySQL数据库配置：建议单进程限制设为 1048576，并在
my.cnf中配置open_files_limit参数,让数据库在启动时主动向系统申请。
突破限制的进阶操作：从PAM到Systemd
在实际操作中，很多运维人员发现修改了配置文件并重启服务器后，限制依然没有变成unlimited,这通常是因为忽略了systemd的接管机制。
修改limits.conf真的生效了吗
通过SSH登录后执行 ulimit -n，可能看到的是 unlimited，但如果在终端中执行 cat /proc/<进程PID>/limits,往往会发现实际运行的Nginx或Java进程的硬限制依然是1024。
这是由于systemd在拉起服务时，并不会去读取 /etc/security/limits.conf,systemd有自己独立的资源限制管理体系。
Systemd服务的资源限制配置
要让特定的服务进程获得linux unlimited权限,必须在systemd的service单元文件中进行显式配置。
- 编辑服务单元文件
：
执行systemctl edit nginx.service。 - 添加覆盖配置：
在打开的配置文件中写入：[Service] LimitNOFILE=infinity LimitNPROC=infinity
- 重载并重启：
执行systemctl daemon-reload和systemctl restart nginx.service。
完成上述操作后，再次使用 cat /proc/$(pidof nginx)/limits | grep "Max open files" 查看，会发现限制已成功变更为 unlimited。
合理配置系统资源限制是运维架构的基石，盲目追求unlimited不如根据实际业务场景精细化设定，这才是保障系统稳定性的关键。
关于linux unlimited的常见问题解答
为什么设置了ulimit unlimited重启后失效？
这种情况多见于使用systemd管理的Linux发行版，systemd不读取 /etc/security/limits.conf，需要通过 systemctl edit 服务名 在 [Service] 段添加 LimitNOFILE=infinity，然后执行 systemctl daemon-reload 重启服务才能生效。
linux ulimit 设置多少合适？
普通应用建议设置为65535，高并发Web服务建议设置为1048576，如果业务确实存在海量长连接需求，可以在确保内核参数 fs.nr_open 足够大的前提下，通过systemd将特定服务的 LimitNOFILE 设为infinity。
linux unlimited设置过高会导致服务器崩溃吗？
会导致，文件描述符底层对应内核的struct file结构体，每个结构体会占用约1KB的不可交换内存，如果进程无限制地打开文件，会迅速耗尽物理内存，触发OOM Killer机制导致进程被强制杀死或系统直接宕机。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/496040.html
