通过limits.conf与PAM协同实现用户资源限制，cgroups和systemd用于更精细的动态控制。
Linux系统通过多种机制来管理和限制不同用户的资源使用，最常见且直接的方式是利用
limits.conf
文件配合PAM（Pluggable Authentication Modules）模块，对用户的进程数、文件打开数、内存使用等进行设定。对于更精细或动态的资源控制，特别是针对系统服务或特定用户会话组，则会结合
cgroups
（控制组）以及
systemd
的单元文件进行配置。核心目的在于避免单一用户或其启动的进程耗尽系统资源，影响其他用户或系统的稳定性。
解决方案 要设置Linux不同用户的资源限制，主要通过编辑
/etc/security/limits.conf
文件来实现。这个文件定义了用户会话的硬限制（hard limit）和软限制（soft limit）。软限制是系统建议的，用户可以自行提升到硬限制，而硬限制则是管理员设定的上限，普通用户无法超越。
/etc/security/limits.conf
的每一行通常遵循以下格式：
<domain> <type> <item> <value>
-
: 可以是用户名、用户组（前面加
<domain>
@
）、
*
（所有用户）、或
%
（所有组）。
-
:
<type>
soft
（软限制）或
hard
（硬限制）。
-
: 要限制的资源类型，例如：
<item>
-
nofile
: 最大文件打开数
-
nproc
: 最大进程/线程数
-
as
: 地址空间（虚拟内存），单位KB
-
rss
: 常驻内存大小，单位KB
-
data
: 数据段最大大小，单位KB
-
stack
: 栈最大大小，单位KB
-
cpu
: CPU时间，单位分钟
-
memlock
: 锁定内存大小，单位KB
-
-
: 限制的具体数值，
<value>
unlimited
表示无限制。
示例配置：
# 限制用户 'devuser' 最大文件打开数为软限制1024，硬限制4096 devuser soft nofile 1024 devuser hard nofile 4096 # 限制用户组 '@developers' 最大进程数为软限制200，硬限制500 @developers soft nproc 200 @developers hard nproc 500 # 限制所有用户最大虚拟内存为2GB (2097152 KB) * hard as 2097152 # 允许devuser锁定最多64MB内存，这在某些高性能计算场景下有用 devuser soft memlock 65536 devuser hard memlock 65536
配置完成后，通常需要用户重新登录才能使新设置生效。确保PAM模块
pam_limits.so
在
/etc/pam.d/
目录下相关的认证服务（如
login
、
sshd
、
su
等）中被正确引用，例如在
/etc/pam.d/login
或
/etc/pam.d/sshd
中通常会有类似下面这行：
session required pam_limits.so
这行配置就是告诉系统在用户登录时应用
/etc/security/limits.conf
中定义的限制。
limits.conf
文件和PAM是如何协同工作来强制执行用户资源限制的？
我记得有一次，我就是因为改了
/etc/security/limits.conf
半天不生效，最后才发现是PAM配置漏了，或者说没有理解它背后的运作机制。简单来说，
/etc/security/limits.conf
本身只是一个配置文件，它需要一个“执行者”来读取并应用这些规则。这个执行者就是PAM（Pluggable Authentication Modules）框架中的
pam_limits.so
模块。当用户尝试登录系统（无论是通过SSH、控制台还是其他方式）时，认证过程会经过一系列的PAM模块。如果相应的PAM服务配置文件（比如
/etc/pam.d/login
或
/etc/pam.d/sshd
）中包含了
session required pam_limits.so
这一行，那么在用户会话建立之前，
pam_limits.so
模块就会被调用。
pam_limits.so
模块的工作职责，就是去解析
/etc/security/limits.conf
文件，根据登录用户的身份（用户名或所属组）找到对应的资源限制规则，然后将这些规则应用到当前用户的会话中。这意味着，这些限制是在用户会话启动的早期阶段就设定好的。一旦会话建立，用户或其启动的进程就会受到这些软硬限制的约束。如果用户试图突破硬限制，系统会直接拒绝。软限制则提供了一定的弹性，用户可以通过
ulimit -Sn <value>
来提升自己的软限制，但不能超过硬限制。所以，PAM在这里扮演了一个至关重要的“守门员”角色，确保每一个新会话都符合预设的资源分配策略。没有它，
limits.conf
里的规则就只是躺在那里的文本，没有任何实际效力。
超越
limits.conf
：何时需要
cgroups
或
systemd
进行更高级的资源管理？
对我来说，
/etc/security/limits.conf
是粗粒度的门卫，它在用户登录时划定了一个大致的边界。但很多时候，这种静态的、基于登录会话的限制并不足够。尤其在多租户环境、容器编排或者需要对后台服务进行精细化控制时，
cgroups
（控制组）和
systemd
的重要性就凸显出来了。
cgroups
是Linux内核提供的一个强大功能，它允许我们将一组进程组织起来，然后对这个组的资源使用进行限制、审计和优先级管理。与
limits.conf
不同，
cgroups
可以实时地对运行中的进程组进行资源隔离和分配，比如CPU时间、内存、磁盘I/O等。
limits.conf
主要限制的是用户会话的“上限”，而
cgroups
则是对进程组的“实际分配”和“隔离”。
systemd
作为现代Linux发行版中的初始化系统，与
cgroups
深度集成。它将系统中的所有进程都组织成
cgroups
，并提供了非常方便的方式来配置这些组的资源限制。例如，你可以为特定的服务单元（
.service
）、用户会话（
user@.service
）甚至更高级的切片（
.slice
）设置详细的资源限制。
何时需要它们？
- 后台服务资源隔离： 如果你有一个Nginx服务，想限制它的CPU使用率不超过某个百分比，或者内存不超过某个阈值，那么
systemd
结合
cgroups
就是理想选择。你可以在Nginx的
.service
文件中添加
CPUAccounting=yes
、
MemoryMax=512M
等指令。
- 多用户计算环境： 假设你有一个共享的科学计算服务器，多个用户会提交长时间运行的任务。仅仅依靠
limits.conf
限制每个用户能启动的进程数可能不够，你可能需要限制每个用户所有进程总共能使用的CPU时间或内存总量。
systemd
的用户切片（
user@.slice
）就可以派上用场，通过修改
/etc/systemd/system.conf
或创建自定义的
user-.slice
文件来配置。
- 容器和虚拟化： Docker、Kubernetes等容器技术底层就是大量依赖
cgroups
来实现容器之间的资源隔离。
- 动态调整：
cgroups
的API允许在运行时动态调整资源限制，这在一些需要根据负载弹性伸缩的场景中非常有用。
举个例子，如果你想限制特定用户
devuser
所有进程的CPU使用率不超过系统总CPU的20%，并且内存不超过1GB，仅仅通过
limits.conf
是很难做到的。但你可以创建一个
systemd
用户切片或直接在
user@.service
中配置：
# /etc/systemd/system/user-.slice.d/devuser.conf [Slice] CPUAccounting=yes CPUQuota=20% MemoryAccounting=yes MemoryMax=1G
然后
systemctl daemon-reload
，这个配置就会作用于
devuser
的所有
systemd
管理的用户进程。对我来说，
limits.conf
是粗粒度的门卫，而
cgroups
和
systemd
则是深入到车间里的精细化管理，尤其在多租户环境或容器编排里，后者的重要性不言而喻。
常见的资源限制类型有哪些？如何根据实际需求设置合理的资源阈值？
在Linux中，我们可以限制的资源类型非常多，但日常工作中，有几个是特别常用且关键的：
-
nofile
(最大文件打开数):
这个限制决定了一个进程或用户可以同时打开的文件句柄数量。对于Web服务器（如Nginx、Apache）、数据库（如MySQL、PostgreSQL）以及高并发应用来说，nofile
的设置至关重要。如果太低，服务可能会因为无法打开更多连接或文件而崩溃。
-
nproc
(最大进程/线程数):
这个限制控制了一个用户可以创建的进程或线程的总数。过低的nproc
可能导致用户无法启动新的程序，甚至登录失败。对于多用户系统，它可以防止某个用户通过创建大量僵尸进程或fork炸弹耗尽系统进程表。
-
as
(地址空间，虚拟内存):
限制进程可用的虚拟内存总量。这有助于防止内存泄漏的程序耗尽系统可用的虚拟地址空间。 -
rss
(常驻内存大小):
限制进程可以占用的物理内存量。这个通常与as
配合使用，更直接地控制物理内存消耗。
-
data
(数据段大小) 和
stack
(栈大小):
这些限制针对进程的特定内存区域，对于一些内存密集型或递归深度较大的程序可能需要调整。 -
memlock
(锁定内存大小):
限制进程可以锁定在物理内存中的页面数量。这对于实时应用程序或某些数据库（如Redis）可能很重要，以避免页面交换（swapping）带来的延迟。
如何设置合理的资源阈值？
设置合理的阈值并非一蹴而就，它需要结合实际的应用场景、系统负载以及对未来增长的预期进行。
- 监控与分析： 我通常会先跑一段时间服务，或者在典型负载下观察。使用
ulimit -a
可以查看当前用户的资源限制，
ulimit -n
查看文件句柄数。
top
、
htop
、
free -h
、
vmstat
等工具能帮助你了解系统当前的CPU、内存、进程和文件I/O使用情况。特别关注峰值时段的资源消耗。
- 应用需求： 了解你的应用程序的特性。例如，一个数据库服务器通常需要非常高的
nofile
限制；一个编译服务器可能需要较高的
nproc
。查阅应用的最佳实践或官方文档，它们往往会给出推荐的资源限制。
- 软硬限制的策略：
- 硬限制（hard limit） 应该设置为一个系统能承受的绝对上限，并且要略高于你预期的峰值，留出一定的冗余。这可以防止失控的进程彻底拖垮系统。
- 软限制（soft limit） 可以设置得相对保守一些，作为一种“预警”机制。当用户或进程达到软限制时，系统可能会发出警告，或者应用可能会开始出现性能下降，这给了管理员介入调整的机会，而不是等到硬限制触发导致服务直接中断。
- 从小开始，逐步调整： 如果不确定，可以先从一个相对保守但不会立即导致问题的数值开始，然后根据监控数据和应用反馈逐步提高或降低。避免一开始就设置一个过高或过低的极端值。
- 安全性与稳定性： 资源限制的另一个重要方面是安全性。合理限制资源可以防止恶意用户或有缺陷的程序耗尽系统资源，从而提高系统的整体稳定性和抗攻击能力。
我通常会先跑一段时间服务，观察其峰值资源消耗，然后在此基础上留出20-30%的冗余来设置硬限制，防止突发流量或错误导致系统崩溃，同时软限制可以设得更低一些，作为一种预警。这样既保证了系统的弹性，又提供了安全保障。
mysql linux redis docker apache nginx app 工具 session 虚拟内存 ai mysql nginx Session 递归 栈 线程 切片 并发 docker redis postgresql 数据库 kubernetes apache linux ssh 虚拟化