使用ulimit命令可限制用户或进程的cpu时间和内存使用，通过ulimit -t设置cpu时间（秒），ulimit -m设置常驻内存（kb）；2. 永久限制需配置/etc/security/limits.conf文件，指定domain、type（soft/hard）、item（如cpu、rss）和value；3. 软限制可由用户在硬限制范围内调整，达到时发送sigxcpu信号，硬限制为root才能修改的绝对上限；4. 限制cpu时间针对进程累计cpu使用，非实时运行时间，适用于cpu密集型任务，多线程进程总cpu时间累加；5. 内存限制中ulimit -v控制虚拟内存，ulimit -m控制常驻内存（rss），后者更反映实际物理内存消耗；6. 实际应用中建议优先监控rss，避免因虚拟内存预分配导致误限，同时注意单位换算和oom killer的影响；7. 配置ulimit应结合应用特性，先宽松测试再逐步收紧，确保系统稳定与资源公平分配，最终实现资源使用的精准控制。
在Linux系统中，限制用户或进程的资源使用，尤其是CPU时间和内存占用，
ulimit
命令无疑是核心工具。它允许系统管理员对用户会话或特定进程施加细粒度的资源限制，这对于维护系统稳定、防止资源滥用、以及确保多用户环境下的公平性至关重要。说实话，每次提到资源限制，我总会想到一把双刃剑：用得好，系统运行稳如磐山；用得不好，程序可能莫名其妙地崩溃，排查起来简直是噩梦。
限制用户资源使用：ulimit实战
要限制用户对CPU和内存的使用，
ulimit
提供了直接的接口。这个命令既可以在命令行临时设置，也可以通过修改系统配置文件实现永久生效。
在命令行中，你可以直接使用
ulimit -t
来限制CPU时间（单位为秒），以及
ulimit -m
来限制最大内存使用（单位为KB，通常指常驻内存，RSS）。例如，如果你想让当前shell及其子进程的CPU时间不超过60秒，内存不超过1GB，你可以这样做：
ulimit -t 60ulimit -m 1048576 # 1GB = 1024 * 1024 KB
这些设置只对当前shell会话及其派生的子进程有效。一旦会话结束，限制就会消失。对于系统级别的永久限制，我们需要编辑
/etc/security/limits.conf
文件。这个文件允许你为特定用户、组或所有用户设置硬限制（hard limit）和软限制（soft limit）。
文件的格式通常是：
：可以是用户名、组名（前缀@）、或通配符
*
（所有用户）。
：
soft
（软限制）或
hard
（硬限制）。软限制是系统首先尝试强制执行的限制，用户可以在其下自行调整；硬限制是系统强制执行的最大值，非root用户无法突破。
：要限制的资源类型，例如
cpu
（CPU时间）、
as
（虚拟内存，address space）、
rss
（常驻内存，resident set size）、
nproc
（最大进程数）等等。
：限制的具体数值。
举个例子，如果我想限制用户
devuser
的CPU时间不超过300秒，并且其常驻内存不能超过2GB：
# /etc/security/limits.confdevuser soft cpu 300devuser hard cpu 300devuser soft rss 2097152 # 2GB = 2 * 1024 * 1024 KBdevuser hard rss 2097152
修改完
/etc/security/limits.conf
后，用户需要重新登录才能使新设置生效。有时候，为了确保
limits.conf
的配置被PAM模块正确加载，还需要检查
/etc/pam.d/system-auth
或
/etc/pam.d/login
等文件中是否包含
session required pam_limits.so
这一行。大多数现代Linux发行版默认都已配置。
配置
ulimit
，我个人觉得，是个艺术活儿，不是简单敲几个数字就完事儿的。它要求你对你的应用和系统负载有深刻的理解。
ulimit的软限制与硬限制：它们如何影响资源管理？
理解
ulimit
的软限制（soft limit）和硬限制（hard limit）是高效管理系统资源的关键。它们就像是两道门槛，一道是提醒你“差不多到头了”，另一道则是“绝对不能再往前一步”。
软限制 (soft limit)：这是系统首先尝试执行的限制。用户可以在硬限制的范围内，自行提高或降低自己的软限制。例如，一个用户会话的CPU软限制是60秒，那么当其进程的CPU时间达到60秒时，系统会发送一个信号（通常是SIGXCPU）来终止该进程。但如果这个用户的硬限制是120秒，那么他可以通过
ulimit -t 90
来将自己的软限制提高到90秒，只要不超过硬限制就行。软限制通常用于提供一个警告或温和的终止机制，给予用户调整或保存工作的机会。
硬限制 (hard limit)：这是系统能够施加的最大限制。一旦设置，非root用户无法将其提高，只能降低。只有root用户才能修改硬限制。硬限制是最终的“红线”，它确保了无论用户如何操作，都不会突破这个上限。比如，如果一个用户的内存硬限制是2GB，那么无论他尝试运行多么内存密集型的程序，系统都不会允许其使用超过2GB的内存。硬限制对于防止单个用户或进程耗尽系统资源至关重要。
在
/etc/security/limits.conf
中，我们通常会同时设置软限制和硬限制。一个常见的做法是让软限制和硬限制相等，这样可以确保一旦达到限制，进程就会被终止，避免了用户自行调整的复杂性。但有时，为了给用户一些缓冲，硬限制会略高于软限制。这种设计哲学体现了系统管理员在资源控制上的灵活性和严谨性。
限制进程CPU使用时间：实际操作与考量
限制进程的CPU使用时间，主要通过
ulimit -t
来完成。这个限制是针对进程消耗的CPU时间总和，而不是实时运行时间。这意味着如果一个进程大部分时间都在等待I/O，那么它的CPU时间增长会比较慢。
当一个进程的CPU时间达到
ulimit -t
设置的软限制时，系统会向该进程发送
SIGXCPU
信号。如果进程没有捕获并处理这个信号，它通常会被终止。如果进程捕获了
SIGXCPU
，它有机会在被强制终止前进行清理工作或退出。当达到硬限制时，进程会被强制终止，不再有机会继续运行。
卡拉OK视频制作
卡拉OK视频制作，在几分钟内制作出你的卡拉OK视频
178 查看详情
实际操作举例：
假设你有一个批处理脚本，你希望它最多运行10分钟的CPU时间，以防它进入死循环：
#!/bin/bashulimit -t 600 # 限制CPU时间为600秒 (10分钟)# 你的批处理命令./my_batch_process.sh
将这个
ulimit -t 600
放在脚本的开头，就能确保脚本及其子进程在达到CPU时间限制时被终止。
考量点：
单位是秒，不是分钟或小时。 务必注意单位换算。并非实时时间。 一个进程可能运行了几个小时，但如果它大部分时间都在等待，其CPU时间可能远低于实际运行时间。因此，
ulimit -t
更适合限制CPU密集型任务。对于多线程应用：
ulimit -t
限制的是整个进程的CPU时间，而不是单个线程的。所有线程消耗的CPU时间会累加到进程的总CPU时间中。调试挑战： 我见过太多因为
ulimit
设置不当，导致程序莫名其妙崩溃的案例。当一个程序因为CPU时间或内存限制而被终止时，它可能不会留下清晰的错误日志。这使得排查问题变得非常困难。通常，我会建议在开发和测试阶段，先将这些限制放宽，甚至暂时取消，以便更好地捕获程序本身的错误。
限制用户内存使用：虚拟内存与常驻内存的权衡
在
ulimit
中，限制内存主要涉及到两个参数：
ulimit -v
（虚拟内存，address space）和
ulimit -m
（常驻内存，resident set size）。它们代表了内存使用的不同维度，选择哪个取决于你的具体需求和对内存的理解。
ulimit -v
(虚拟内存 / address space)：这是进程可以使用的最大虚拟内存空间。它包括了进程的代码段、数据段、堆、栈以及映射的文件等所有可寻址的内存区域。即使这些内存没有实际被加载到物理RAM中，只要进程“声明”要使用它们，就会计入虚拟内存。
ulimit -m
(常驻内存 / resident set size, RSS)：这是进程实际占用物理内存的最大值。它反映了进程真正驻留在RAM中的页面数量。相比虚拟内存，RSS更能直接体现进程对系统物理资源的实际消耗。
如何选择？
我个人在实际操作中，对于一般应用，更倾向于先关注
ulimit -m
（常驻内存）。因为它更直接反映了进程实际占用的物理内存，而
-v
（虚拟内存）有时候会显得有点虚高，容易误导，因为它包含了那些可能并未实际使用的虚拟地址空间。如果你想严格控制系统上的物理内存压力，
ulunit -m
通常是更有效的选择。
实际操作举例：
假设你想限制一个用户或进程最多只能使用512MB的物理内存：
ulimit -m 524288 # 512MB = 512 * 1024 KB
或者在
/etc/security/limits.conf
中：
myuser soft rss 524288myuser hard rss 524288
考量点：
内存单位是KB。 再次强调，单位很重要，经常有人会搞错。虚拟内存的误区： 有些程序（比如Java应用）会预分配大量的虚拟内存，但实际使用的物理内存可能远低于此。如果只限制
ulimit -v
，可能会导致这些程序无法启动，即使它们实际上并不会耗尽物理内存。OOM Killer： 即使设置了
ulimit
，Linux系统也有一个OOM Killer（Out-Of-Memory Killer）机制。当系统物理内存严重不足时，OOM Killer会根据一套启发式算法，选择并杀死一个或多个进程来释放内存，以避免系统崩溃。这意味着，即使你的进程没有达到
ulimit
的限制，也可能因为整个系统内存紧张而被OOM Killer杀死。逐步收紧策略： 在实际部署中，我通常会建议先用一个相对宽松的限制跑一段时间，观察程序的真实资源消耗（例如通过
top
、
htop
、
ps aux
等工具），然后再逐步收紧
ulimit
的限制。这样可以避免因为设置过严而导致程序不稳定或无法运行。
总的来说，
ulimit
是一个强大的工具，但它需要细致的配置和持续的监控。它不仅仅是关于限制，更是关于理解你的系统和应用的需求，从而实现资源的最佳平衡。
以上就是如何限制用户资源使用 ulimit限制CPU和内存的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/444903.html
微信扫一扫 
支付宝扫一扫 
