CentOS资源限制如何配置_CentOS资源限制设置方法

蓮花仙者

发布时间：2025-09-17 11:14:01

288人浏览过

来源于php中文网

原创

CentOS资源限制配置需结合ulimit、limits.conf、systemd及cgroups实现；ulimit用于临时会话级调整，limits.conf提供持久化用户/系统级限制，systemd服务单元支持服务专属资源配置，cgroups则实现进程组的精细化资源隔离与控制。

centos资源限制如何配置_centos资源限制设置方法

CentOS上的资源限制配置，核心在于通过

ulimit

命令进行会话级别的临时调整，以及利用

/etc/security/limits.conf

文件实现系统范围或用户/组的持久化设置。对于更复杂的场景，

systemd

和

cgroups

提供了更细粒度的控制，允许我们为特定的服务或进程定义严格的资源边界。

解决方案

在CentOS中，配置资源限制主要涉及以下几个层面：

ulimit

命令：即时且临时的会话限制

ulimit

是一个shell内建命令，它允许你查看或设置当前用户会话的资源限制。这些限制只对当前shell及其子进程有效，并且在会话结束后就会失效。

查看当前限制：
```
ulimit -a
```
这会列出所有可用的资源限制，例如打开文件数（
```
open files
```
）、最大进程数（
```
max user processes
```
）、CPU时间（
```
cpu time
```
）等。
设置限制： 你可以使用
```
-n
```
设置打开文件数，
```
-u
```
设置最大用户进程数等。例如，将当前会话的硬性（hard）和软性（soft）打开文件数限制都设置为 4096：
```
ulimit -n 4096
```
通常，软限制是实际生效的限制，而硬限制是软限制可以达到的最大值。普通用户只能降低硬限制或在硬限制范围内提高软限制。root用户可以修改所有限制。

/etc/security/limits.conf

文件：持久化的系统级或用户级限制

这个文件是PAM（Pluggable Authentication Modules）的一部分，它允许你为特定的用户、组或所有用户设置持久的资源限制。这些限制在用户登录时生效，并且会覆盖通过

ulimit

设置的默认值。

文件结构： 每一行通常遵循以下格式：
```
            
```
- ：可以是用户名（例如
```
myuser
```
  ）、组名（例如
```
@mygroup
```
  ）、
```
*
```
  （所有用户）或
```
%
```
  （所有组）。
- ：
  - ```
  soft
```
  ：软限制，可以由用户自行提高到硬限制以下。
- ```
hard
```
    ：硬限制，普通用户无法超越，root用户可以修改。
  - ```
  -
```
  ：同时设置软硬限制。
- ：要限制的资源类型，例如
```
nofile
```
  （最大打开文件数）、
```
nproc
```
  （最大进程数）、
```
cpu
```
  （CPU时间）、
```
memlock
```
  （内存锁定）等。
- ：限制的具体数值。

示例： 为用户

nginx

设置最大打开文件数为 65535：

nginx        soft    nofile    65535
nginx        hard    nofile    65535

为所有用户设置最大进程数为 4096：

*            soft    nproc     4096
*            hard    nproc     4096

生效机制： 修改
```
limits.conf
```
后，需要用户重新登录才能使新设置生效。对于已经运行的服务，可能需要重启服务。确保
```
/etc/pam.d/system-auth
```
和
```
/etc/pam.d/sshd
```
（如果通过SSH登录）文件中包含
```
session    required     pam_limits.so
```
这一行，通常CentOS默认是有的。

3. Systemd Unit 文件：服务特定的资源限制

对于由

systemd

管理的服务，你可以在其

.service

单元文件中直接定义资源限制。这提供了一种更内聚、服务专属的配置方式。

配置方式： 在

[Service]

段落中，可以使用

LimitNOFILE

、

LimitNPROC

、

LimitCPU

等指令。例如，为Nginx服务设置打开文件数限制：

# /etc/systemd/system/nginx.service.d/limits.conf (创建或编辑)
[Service]
LimitNOFILE=65535
LimitNPROC=4096

或者直接在主

.service

文件中修改。

生效： 修改后，需要重新加载

systemd

配置并重启服务：

sudo systemctl daemon-reload
sudo systemctl restart nginx

4. Cgroups (Control Groups)：更精细的资源隔离

Cgroups是Linux内核提供的一种机制，用于限制、记录和隔离进程组的资源使用（CPU、内存、磁盘I/O、网络等）。它比

limits.conf

提供更细粒度的控制，并且是容器技术（如Docker）的基础。在CentOS中，通常通过

systemd

的

slice

、

scope

和

service

单元来间接管理cgroups。

Systemd 与 Cgroups：

systemd

会为每个服务、用户会话等创建相应的cgroup。你可以通过修改

systemd

单元文件来调整cgroup参数。例如，限制一个服务的CPU使用率：

# /etc/systemd/system/mywebapp.service.d/cpu.conf
[Service]
CPUShares=512  # 默认是1024，降低表示分配更少的CPU时间
CPUQuota=50%   # 限制服务最多使用50%的CPU

手动操作 (较少直接使用)： 虽然可以直接通过
```
/sys/fs/cgroup
```
路径下的文件来操作cgroup，但这通常比较复杂且容易出错，推荐通过
```
systemd
```
或专门的cgroup管理工具进行。

ulimit

和

limits.conf

：哪种方式更适合我的场景？

这确实是很多人刚接触资源限制时会遇到的困惑。简单来说，它们解决的问题层面不同，但又相互关联。

ulimit

更像是你在当前工作台前，临时调整工具的使用规则。它只对你当前登录的shell会话及其衍生的子进程生效。比如，你正在调试一个程序，它可能会打开大量文件，为了避免报错，你可以在当前终端临时提高

nofile

限制。一旦你关闭这个终端会话，或者在新开的终端中，这个限制就不再存在了。它的优点是即时、灵活，不需要root权限（在软限制范围内），非常适合临时性的、个人化的调试或测试。但缺点也很明显，就是不持久，无法跨会话生效，也不适用于后台服务。

而

/etc/security/limits.conf

则更像是在制定公司的规章制度。一旦设置，它会对所有符合规则的用户或组（或所有用户）生效，并且是持久化的。当你通过SSH登录、或者启动一个由特定用户运行的服务时，这些限制就会被PAM模块加载并应用。它的优势在于系统级或用户级的持久性管理，非常适合为生产环境中的关键服务（如Nginx、MySQL、Elasticsearch等）设置稳定的资源边界，防止它们耗尽系统资源。缺点是修改后需要重新登录或重启服务才能生效，并且如果设置不当，可能会影响到整个系统或特定用户的正常使用。

选择建议：

盛世企业网站管理系统1.1.2

免费盛世企业网站管理系统(SnSee)系统完全免费使用，无任何功能模块使用限制，在使用过程中如遇到相关问题可以去官方论坛参与讨论。开源系统Web代码完全开源，在您使用过程中可以根据自已实际情况加以调整或修改，完全可以满足您的需求。强大且灵活独创的多语言功能，可以直接在后台自由设定语言版本，其语言版本不限数量，可根据自已需要进行任意设置；系统各模块可在后台自由设置及开启；强大且适用的后台管理支

下载

临时调试/测试： 使用
```
ulimit
```
。
生产环境服务： 优先使用
```
/etc/security/limits.conf
```
为服务运行用户设置限制。如果服务由
```
systemd
```
管理，直接在
```
.service
```
文件中使用
```
Limit*
```
指令会更清晰、更服务化，因为这些设置最终也会被
```
systemd
```
转换为cgroup或
```
ulimit
```
形式应用。
全局默认限制： 对于所有用户或系统范围的默认行为，使用
```
/etc/security/limits.conf
```
。
精细化隔离/容器环境： 考虑
```
systemd
```
的cgroup指令或直接操作cgroups（虽然通常不推荐直接操作）。

记住，

limits.conf

的设置通常会在用户登录时，通过

pam_limits.so

模块转换为该会话的

ulimit

值。所以，它们不是完全独立的，而是协同工作的。

深入理解 Cgroups：实现更精细化的资源隔离

Cgroups，即控制组（Control Groups），是Linux内核提供的一项强大功能，它允许你将一组进程组织起来，并对这些进程的资源使用进行限制、审计和优先级管理。这和我们前面提到的

ulimit

或

limits.conf

有着本质的区别：

ulimit

更多是针对单个进程或用户会话的“软性”资源限制，而cgroups则是对进程组进行“硬性”的资源隔离和分配。

想象一下，你有一个服务器，上面跑着Web服务、数据库、数据分析任务等多个应用。如果某个应用突然失控，耗尽了CPU或内存，整个系统都会受到影响。Cgroups的目的就是解决这个问题。它将系统资源（如CPU时间、内存、磁盘I/O、网络带宽）划分为不同的“子系统”（subsystems），每个子系统都可以独立地对进程组进行管理。

Cgroups 的核心概念：

子系统 (Subsystem/Controller)： 每种资源类型都有一个对应的子系统。常见的有：
- ```
cpu
```
  ：控制CPU的访问。
- ```
cpuacct
```
  ：报告CPU使用情况。
- ```
memory
```
  ：限制内存使用。
- ```
blkio
```
  ：限制块设备I/O。
- ```
net_cls
```
  ：标记网络数据包，用于流量控制。
- ```
pids
```
  ：限制进程数。
层级 (Hierarchy)： Cgroups可以形成树状结构。一个父cgroup的资源限制可以被子cgroup进一步细分。这使得你可以实现非常灵活的资源分配策略。
任务 (Task)： 任何一个进程都可以被加入到一个或多个cgroup中。

Cgroups 如何工作？

当一个进程被加入到一个cgroup时，它就会受到该cgroup所设置的资源限制。例如，如果你将一个Web服务的所有进程都放到一个内存限制为2GB的cgroup中，那么即使这个Web服务尝试分配更多内存，也会被内核阻止。

在CentOS 7/8中，

systemd

已经深度集成了cgroups。当你启动一个

systemd

服务时，

systemd

会自动为这个服务创建一个cgroup，并将其进程放入其中。这意味着，你通过

systemd

单元文件设置的

Limit*

指令（如

LimitNOFILE

、

LimitNPROC

）以及

CPUQuota

、

MemoryLimit

等指令，实际上都是在配置对应的cgroup参数。

Systemd 与 Cgroups 的实践：

CPU 限制：
- ```
CPUShares=value
```
  ：这是相对权重。默认所有服务都是1024。如果你将某个服务的
```
CPUShares
```
  设为512，它在CPU竞争激烈时，获得的CPU时间会是默认服务的一半。
- ```
CPUQuota=percentage
```
  ：这是绝对配额。例如
```
CPUQuota=50%
```
  表示该服务最多只能使用一个CPU核心的50%。
内存限制：
- ```
MemoryLimit=value
```
  ：限制服务可以使用的最大内存量，例如
```
MemoryLimit=2G
```
  。
- ```
MemorySwapMax=value
```
  ：限制服务可以使用的最大交换空间。
进程数限制：
- ```
TasksMax=value
```
  ：限制服务可以创建的最大进程/线程数。

示例：为Nginx服务设置CPU和内存限制

假设你想限制Nginx服务最多使用一个CPU核心的50%，并且内存不超过2GB。你可以创建一个

systemd

override文件：

sudo mkdir -p /etc/systemd/system/nginx.service.d/
sudo vi /etc/systemd/system/nginx.service.d/resource_limits.conf

文件内容如下：

[Service]
CPUQuota=50%
MemoryLimit=2G
TasksMax=1000 # 限制最大进程/线程数

保存后，重新加载

systemd

配置并重启Nginx服务：

sudo systemctl daemon-reload
sudo systemctl restart nginx

通过这种方式，你可以在不影响系统其他部分的情况下，为特定的服务提供强隔离的资源保障。Cgroups的引入，极大地提升了Linux系统在多租户和容器化环境下的资源管理能力。

资源限制配置中的常见误区与最佳实践

在CentOS中配置资源限制，虽然看起来直接，但实际操作中还是有不少坑点和值得注意的地方。我见过不少因为资源限制配置不当，导致服务不稳定甚至系统崩溃的案例。

常见误区：

修改
limits.conf
后未重新登录/重启服务：这是最常见的错误。
```
limits.conf
```
的设置是通过PAM模块在用户登录时加载的。对于一个已经登录的用户或正在运行的服务，除非重新登录或重启，否则新的限制不会生效。特别是对于系统服务，通常需要
```
systemctl restart service_name
```
。
混淆
soft
和
hard
限制：
```
soft
```
限制是实际生效的限制，但用户可以在
```
hard
```
限制范围内自行提高。
```
hard
```
限制是用户可以设置的上限，普通用户无法超越。如果
```
soft
```
限制太低，可能会导致服务很快达到瓶颈；如果
```
hard
```
限制太低，即使是root用户也无法临时提高。通常，我们会把
```
soft
```
和
```
hard
```
设置成相同的值，以确保一致性。
盲目设置过高的限制： 有些人为了避免出现“too many open files”这类错误，直接把
```
nofile
```
限制设成一个极大的值，比如100万。虽然这可能暂时解决了问题，但过高的限制可能掩盖了程序设计上的缺陷（例如文件句柄未正确关闭），而且在极端情况下，确实可能导致系统资源耗尽。
未考虑父进程的限制： 如果一个服务是由另一个进程启动的，它的资源限制可能会受到父进程的限制。例如，通过SSH登录后启动的服务，会受到SSH会话的
```
ulimit
```
影响。
忽略
systemd
单元文件的优先级：如果同时在
```
limits.conf
```
和
```
systemd
```
单元文件（或override文件）中设置了相同类型的限制，
```
systemd
```
的设置通常会优先，因为它更直接地控制了服务的cgroup和进程环境。
仅关注
nofile
和
nproc
：虽然这两个是常见的瓶颈，但
```
memlock
```
（内存锁定，对数据库或高性能计算很重要）、
```
cpu
```
（CPU时间）等也同样关键，需要根据应用特性进行综合考虑。

最佳实践：

明确目标： 在修改任何限制之前，先弄清楚为什么要修改，以及预期的效果是什么。是为了防止某个应用耗尽资源，还是为了让某个应用能使用更多资源？
从小处着手，逐步调整： 不要一次性将限制调到最大。先设置一个合理的值，观察服务运行情况，如果仍然出现资源不足的错误，再逐步提高。
测试与监控并行： 每次修改资源限制后，务必进行充分的测试，并结合系统监控工具（如
```
top
```
,
```
htop
```
,
```
vmstat
```
,
```
iostat
```
,
```
ss -s
```
等）观察实际资源使用情况。例如，
```
lsof -p 
```
可以查看某个进程打开的文件句柄数。
为特定用户或服务设置： 尽量避免对
```
*
```
（所有用户）设置过于严格的限制，这可能会影响到系统其他功能。最好是为运行特定服务的用户或通过
```
systemd
```
单元文件为服务单独设置。
记录变更： 任何对资源限制的修改都应该记录下来，包括修改时间、原因、修改前后的值以及相关测试结果。这对于后续的故障排查非常有帮助。
理解应用的资源需求： 不同的应用对资源的需求差异很大。例如，数据库服务通常需要大量的
```
nofile
```
和
```
nproc
```
，以及充足的内存；而计算密集型应用则更关注CPU和内存。了解你的应用特性是合理配置的基础。
备份配置文件： 在修改
```
/etc/security/limits.conf
```
或
```
systemd
```
单元文件之前，最好备份原始文件，以防配置错误导致系统问题。
考虑
/etc/sysctl.conf
：有些全局的系统参数，如TCP连接数限制 (
```
net.core.somaxconn
```
)、文件句柄总数 (
```
fs.file-max
```
) 等，是通过
```
/etc/sysctl.conf
```
配置的。这些参数会影响整个系统的能力上限，与
```
limits.conf
```
形成互补。例如，如果
```
fs.file-max
```
设置得太低，即使
```
nofile
```
很高也无济于事。