Linux - 修改系统的max open files、max user processes(附ulimit的使用方法) ...

本文介绍如何在Linux系统中调整maxopenfiles和maxuserprocesses的值,并提供了多种配置方法及注意事项。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Linux - 修改系统的max open files、max user processes(附ulimit的使用方法)
目录

1 问题说明
2 修改max open files
3 修改max user processes
4 附录: ulimit命令说明
1 问题说明
Linux 系统默认的 max open files = 1024, 在大内存服务器中, 如果运行负载比较大的程序, 很容易发生 error: too many open files, 特别是提供大量静态文件访问的Web服务器、缓存服务器中这种错误更加常见.

open files 表示系统级别的能够打开的文件句柄的数量, 是系统级别的安全策略: 限制所有应用打开的文件数量.

发生 error: too many open files 时, 如果不好定位程序问题, 可在系统的配置文件中做一定的修改.

为了让服务器重启之后, 配置仍然有效, 需要用永久生效的配置方法进行修改.

2 修改max open files
说明: 这里以Cent OS 6.5为例.

使用 ulimit -a 命令可以查看当前系统的所有限制值, 括号中的命令是查看单项限制值的方式, 比如要查看系统可打开的最大文件数量(open files), 就可以用 ulimit -n 命令: (具体命令说明请参考末尾部分的附录)

[root@localhost ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited # 数据段长度
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 1031426
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited # 最大内存大小
open files (-n) 65536 # 最大打开文件数
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240 # 栈大小
cpu time (seconds, -t) unlimited # CPU时间
max user processes (-u) 131072
virtual memory (kbytes, -v) unlimited # 虚拟内存大小
file locks (-x) unlimited
(1) 短期修改, 重启服务器后即失效:

把文件句柄数改为65535

ulimit -n 65535

也可用下属方式修改:

ulimit -SHn 65535

其中-S是soft软限制模式, -H指hard硬限制模式;

默认是软限制, 如果只指定-n, 那就会同时配置-SH.

(2) 永久修改, 重启服务器也不变:

网络上常见的方式有如下三种:

① 在 /etc/security/limits.conf 最后增加如下两行记录:

nofile - 可以打开的最大文件数, *通配符表示对所有用户有效

  • soft nofile 65536
  • hard nofile 65536
    修改完成后保存, 退出当前用户并重新登录(不用重启服务器), 当前修改就会生效.

② 在 /etc/profile 中增加一行 ulimit -SHn 65535, 然后运行 source /etc/profile 命令让修改立即生效.

—— /etc/profile 文件是所有系统用户的配置文件, 修改后会影响当前系统的所有注册用户.

③ 在 /etc/rc.local 文件中增加一行 ulimit -SHn 65535, 修改完后, 重启服务器就可生效.

值得注意的是, 博主在CentOS 6.5系统中测试, 发现只有第 ① 和第 ② 种方式才有效.

另外, 在《阿里巴巴Java开发手册》中, 关于最大文件句柄数有这样的描述:

【推荐】调大服务器所支持的最大文件句柄数(File Descriptor,简写为fd)。

说明:主流操作系统的设计是将 TCP/UDP 连接采用与文件一样的方式去管理,即一个连接对应于一个 fd。主流的 Linux 服务器默认所支持最大 fd 数量为 1024,当并发连接数很大时很容易因为 fd 不足而出现“open too many files”错误,导致新的连接无法建立。 建议将 Linux 服务器所支持的最大句柄数调高数倍(与服务器的内存数量相关)。

3 修改max user processes
(1) 问题描述: 在使用Java程序多线程大批量生成模拟数据时, Cent OS报出如下错误:

ulimit: max user processes: cannot modify limit
错误说明: Linux系统为每个用户都设置了一个最大进程数, 这个特性可以让我们控制服务器上现有用户可以创建的进程数量.

(2) 查看 max user processes:

与查看max open files类似, 可使用 ulimit -u查看max user processes:

ulimit -u
(3) 修改 max user processes:

① 方案一: 修改 /etc/security/limits.conf 文件, 在文件最后添加下述内容:

  • soft nproc 131072
  • hard nproc 131072
    ② 方案二: 修改 /etc/security/limits.d/90-nproc.conf文件, 在文件最后添加下述内容:

用户进程数的默认限制, 下面这个是对root外的其他用户限制max user processes, 要注释掉:

* soft nproc 1024

root soft nproc 131072
(4) 关于nproc配置信息的扩展说明:

对 max user processes 的配置, Linux系统默认先读取 /etc/security/limits.conf 中的信息, 如果 /etc/security/limits.d/ 目录下还有配置文件的话, 也会依次遍历读取, 最终, /etc/security/limits.d/ 中的配置会覆盖 /etc/security/limits.conf 中的配置.

另外, max open files 和 max user processes 是不能配置 unlimited 的 —— 极不安全的设置, 此时系统会使用默认的配置值. 对 nproc 而言, 默认值的计算方法为:

计算公式为:

default_nproc = max_threads / 2;

其中, max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);

mempages是机器的物理页面个数, THREAD_SIZE=8K, 所以, 计算公式为:

default_nproc = max_threads / 2

          = (mempages * PAGE_SIZE) / ( 2 * 8 *THREAD_SIZE ) 
          = total_memory / 128K;
          

计算本机默认nproc配置:

cat /proc/meminfo | grep MemTotal
MemTotal: 115571480 kB

echo "115571480 / 128" | bc
902902

ulimit -u
902682

算出来default_nproc = 902902, 和实际的902682很接近,

因为物理页面会存储一些关键数据, 所以实际的比计算出来的要小一些.

4 附录: ulimit命令说明
(1) 列出所有当前资源极限, 命令为: ulimit -a, 其他命令可参考输出信息中括号内的提示:

ulimit -a 命令的输出信息:

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited # 一个进程的数据段的最大值
scheduling priority (-e) 0
file size (blocks, -f) unlimited # Shell创建文件的最大体积, 1block = 512bytes
pending signals (-i) 1031426 # 最多允许多少个待处理的信号
max locked memory (kbytes, -l) 64 # 每个进程可以锁住的物理内存的最大值
max memory size (kbytes, -m) unlimited # 每个进程可以使用的常驻内存的最大值
open files (-n) 65536 # 每个进程可以同时打开的最大文件数, 不能是unlimited
pipe size (512 bytes, -p) 8 # 管道的最大值, 1block = 512bytes
POSIX message queues (bytes, -q) 819200 # POSIX的消息队列的最大值
real-time priority (-r) 0
stack size (kbytes, -s) 10240 # 单个进程能够使用的最大栈大小
cpu time (seconds, -t) unlimited # 单个进程的最大CPU时间, 也就是可使用CPU的秒数, 到硬极限时, 这个进程就会立即自杀; 到软极限时, 每秒发送一次限制超时信号SIGXCPU
max user processes (-u) 131072 # 单个用户可同时运行的最大进程数, 不能是unlimited
virtual memory (kbytes, -v) unlimited # 每个进程可使用的最大虚拟内存
file locks (-x) unlimited # 每个进程能锁住的最大文件个数
(2) ulimit的其他命令:

-H 设置某个给定资源的硬极限. 如果用户拥有root权限, 可以增大硬极限. 任何用户均可减少硬极限
-S 设置某个给定资源的软极限, 软极限可增大到硬极限的值
(3) 注意事项:

① 其中, unlimited 是指不限制用户可以使用的资源, 但这个设置对系统可打开的最大文件数(max open files)和各个用户可同时运行的最大进程数(max user processes)无效.

② 如果某个指标没有明确指定-H和-S限制, 那么当前的极限值就是 -H 和 -S 两者的极限值.

参考资料
ulimit限制之nproc问题

linux修改max user processes limits

版权声明
作者: ma_shoufeng(马瘦风)

出处: 博客园 马瘦风的博客

<think>嗯,用户之前遇到了DataNode没有启动的问题,现在他们提供了`ulimit -a`的输出,并提到在日志中有很多带datanode的.log文件,其中一个内容如上。用户想知道这是什么错误。 首先,我需要分析用户提供的`ulimit -a`的输出,看看是否有系统资源限制导致DataNode启动失败。用户以root用户运行了`ulimit -a`,结果显示几个关键参数: - `open files (-n) 1024`:这个值可能太低,特别是如果DataNode需要处理大量文件或连接时。 - `max user processes (-u) 3766`:虽然看起来足够,但如果系统负载高,可能还是不够。 - `max locked memory (-l) 64`:这个值非常低,Hadoop特别是HDFS可能需要更高的锁内存,尤其是当使用内存映射文件时。 接下来,用户提到日志中有很多datanode的.log文件,但用户没有直接提供日志内容,而是引用了之前的问题。可能需要结合之前的错误场景来分析。比如,如果日志中有“Too many open files”错误,那么open files限制过低就是问题所在。或者,如果出现内存相关的错误,可能是max locked memory的问题。 可能的错误原因包括: 1. **文件描述符不足**:HDFS的DataNode需要同时处理多个连接和文件操作,如果open files限制过低,可能导致无法打开足够的文件或网络连接,从而崩溃。 2. **锁内存限制**:Hadoop可能使用内存映射文件或需要锁定内存,64KB的限制显然不够,导致启动失败。 3. **进程数限制**:虽然3766看起来足够,但如果其他进程也在运行,可能影响DataNode的子进程。 解决方案需要调整这些ulimit参数。对于root用户,需要修改系统级的限制,可以通过/etc/security/limits.conf文件设置,或者调整Hadoop启动脚本中的环境变量。此外,重启DataNode服务以使设置生效。 另外,用户可能需要检查具体的日志内容,确认是否有明确的错误信息,如“Cannot lock memory”或“Too many open files”,这可以帮助更精准地定位问题。如果用户提供的日志中有具体的错误堆栈,需要结合这些信息进一步分析。</think>--- ### 一、`ulimit -a` 输出的关键问题分析 你提供的 `ulimit -a` 输出中,有两个关键限制可能引发 DataNode 崩溃: #### 1. **`open files (-n) 1024`** - **影响**:Hadoop 的 DataNode 需要处理大量文件读写和网络连接,默认的 1024 文件描述符上限可能导致 `Too many open files` 错误。 - **典型日志特征**: ```log java.io.IOException: Too many open files at java.io.UnixFileSystem.createFileExclusively(Native Method) at java.io.File.createNewFile(File.java:1012) ``` #### 2. **`max locked memory (-l) 64`** - **影响**:Hadoop 依赖内存映射文件(如 HDFS 块操作),`max locked memory` 过低可能导致无法锁定内存页,触发以下错误: ```log java.lang.RuntimeException: Cannot start datanode because the configured max locked memory size is too low ``` --- ### 二、解决方案 #### **步骤 1:调整系统资源限制** - **修改 `/etc/security/limits.conf`** 添加以下配置(需 root 权限): ```conf hadoop_user(替换为实际运行Hadoop的用户) soft nofile 65535 hadoop_user hard nofile 65535 hadoop_user soft memlock unlimited hadoop_user hard memlock unlimited ``` - **作用**:将文件描述符上限提升至 65535,解除内存锁定限制。 - **验证生效** 重新登录用户后执行 `ulimit -a`,确认 `open files` 和 `max locked memory` 已更新。 #### **步骤 2:检查 DataNode 日志中的具体错误** 打开 `hadoop-*-datanode-*.log`,根据以下场景定位问题: 1. **文件描述符不足** 如果日志包含 `Too many open files`,说明需优先修复 `open files` 限制。 2. **内存锁定失败** 如果日志包含 `Cannot lock memory` 或 `mlockall failed`,需优先修复 `max locked memory` 限制。 #### **步骤 3:重启 DataNode 服务** ```bash # 停止 HDFS stop-dfs.sh # 启动 HDFS start-dfs.sh # 检查 DataNode 进程 jps | grep DataNode ``` --- ### 三、扩展优化建议 1. **调整内核参数**(可选) 在 `/etc/sysctl.conf` 中增加: ```conf vm.swappiness = 0 # 减少交换内存使用 vm.max_map_count = 262144 # 提升内存映射文件上限 ``` 执行 `sysctl -p` 生效。 2. **验证 Hadoop 配置** 确保 `hdfs-site.xml` 中未强制限制内存锁定(Hadoop 3.x 默认不依赖此配置): ```xml <!-- 如果存在以下配置,建议删除或注释 --> <property> <name>dfs.datanode.max.locked.memory</name> <value>...</value> </property> ``` --- ### 四、验证结果 1. **查看调整后的 `ulimit` 值** ```bash ulimit -n # 应输出 65535 ulimit -l # 应输出 "unlimited" ``` 2. **观察 DataNode 日志** 重启后日志中应无 `Too many open files` 或内存锁定相关错误。 --- ### :常见错误日志示例 #### 1. 文件描述符不足 ```log 2023-10-01 12:00:00 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException: Unable to create block file due to Too many open files ``` #### 2. 内存锁定失败 ```log 2023-10-01 12:00:00 WARN org.apache.hadoop.util.NativeCodeLoader: mlockall failed: Cannot allocate memory - HDFS may suffer performance degradation ``` 请根据实际日志内容选择针对性修复方案!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值