修改Mac的最大连接数、端口数(Too many open files )

本文详细介绍了在Mac系统上使用JMeter进行服务器接口压力测试时遇到的连接数限制问题及解决方案,包括调整系统最大文件描述符数量、动态端口范围等关键参数,以提升压测效果。

使用jmeter压测服务器接口,发现,无论怎么优化,都会在22000样本左右的时候,出现连接超时或者无法找到路由之类的错误。但,把错误率降低到1%一下后,找两台机器同时压,两台机器都没有出现问题,服务也正常,就说嘛。实际瓶颈并非出现在服务器上,而是在本机。

因为我使用的是mac,所以就去查了下mac的连接参数修改方法。

最大连接数限制就是系统所能打开的最大文件数(文件描述符)的限制,分全局和进程两种,相应的命令如下:

  • sysctl kern.maxfiles

输出:kern.maxfiles: 12288

说明:全局限制,也就是系统默认的最大连接数限制是12288

  • sysctl kern.maxfilesperproc

输出:kern.maxfilesperproc: 10240

说明:单个进程默认最大连接数限制是10240

  • sudo sysctl -w kern.maxfiles=1048600

输出:kern.maxfiles: 12288 -> 1048600

说明:设置系统最大连接数从12288到1048600

  • sudo sysctl -w kern.maxfilesperproc=1048576

输出:kern.maxfilesperproc: 10240 -> 1048576

说明:设置进程连接数限制,进程的最大连接数要小于等于全局连接数

  • ulimit命令
    ulimit -n

输出:2560

说明:“ulimit -n”命令显示当前shell能打开的最大文件数,默认值:2560,该值总是小于kern.maxfilesperproc的值,因为一个shell就是一个进程。

ulimit -n 1048576

说明:设置当前shell能打开的最大文件数为1048576,该值不能大于kern.maxfilesperproc,否则会提示设置失败。

  • 动态端口范围
    sysctl net.inet.ip.portrange

输出:

net.inet.ip.portrange.first: 49152
net.inet.ip.portrange.last: 65535

Linux动态端口号默认范围是32768-65535,也就是说,作为客户端连接同一个IP和同一个端口号,最多只能建立30000多个连接,而Mac默认只能建立16000个左右的连接。

sysctl -w net.inet.ip.portrange.first=32768

说明:设置动态分配起点端口号为32768,这样可以增大客户端可以建立的连接数。

按以上的方式设置参数有个问题,当系统重启后,这些参数又恢复成了默认值,解决办法就是把参数写到/etc/sysctl.conf文件中,但是,默认这个文件是不存在的,所以首先就要创建它:

sudo touch /etc/sysctl.conf
#然后把参数写到文件里

kern.maxfiles=1048600
kern.maxfilesperproc=1048576
net.inet.ip.portrange.first=49152   
net.inet.ip.portrange.last=65535

重启系统,查看结果,显示成功。

至于ulimit-n的值,可以把ulimit-n1048576 写到.bashrc中实现自动修改。

修改完之后,继续测试,情况好了一些,但是还是没法压出服务器性能到底怎么样,还是多找几台机器,用服务器压一压吧。

<think>首先,用户的问题是基于提供的引用内容,查找解决“failed to allocate directory watch: too many open files”错误的方案。引用是从站内获取的,我需要参考它们。 回顾引用: - 引用[1]:建议修改`/etc/sysctl.conf`文件,添加`fs.inotify.max_user_instances=512`和`fs.inotify.max_user_watches=262144`。 - 引用[2]:描述了在Ubuntu上遇到相同的错误,执行`sudo service mysql restart`时报错。 - 引用[3]:解释“too many open files”错误是Linux常见问题,涉及打开的文件、socket等句柄超出限制。 - 引用[4]:解释了inotify机制,它是用于通知文件系统变化的。 用户的需求是解决“failed to allocate directory watch: too many open files”错误。这个错误通常与inotify机制相关,因为它涉及到目录监视(directory watch)。inotify是Linux内核的一个子系统,用于监视文件系统事件。 从引用中,解决方案集中在调整inotify的参: - `fs.inotify.max_user_instances`:指定每个用户的大inotify实例。 - `fs.inotify.max_user_watches`:指定每个用户的大监视文件。 系统中默认值可能较低,导致当应用程序(如MySQL或其他服务)尝试监视太多文件时出错。 我的回答需要: - 基于系统级指令:所有行内学表达式用$...$,但这里可能没有学内容。独立公式用$$...$$,但可能不需要。 - 使用中文回答。 - 生成相关问题。 - 在回答中引用的段落末尾自然地添加引用标识,如[^1]。 - 结构清晰,帮助用户逐步解决问题。 - 参考提供的引用内容。 结构化回答: 1. **理解问题**:简要解释错误的原因,基于引用内容。 2. **解决方案**:提供步骤来调整inotify限制。 - 步骤1:编辑sysctl配置文件。 - 步骤2:添加或修改。 - 步骤3:应用更改。 - 步骤4:检查当前限制(可选)。 3. **验证**:建议如何验证错误是否解决。 4. **相关问题**:生成相关问题作为结尾。 生成的引用标识: - 当引用[1]或[2]中的内容时,加上[^1]或[^2]。 - 引用[4]解释了inotify机制,可以引用。 回答大纲: - 介绍:解释错误原因:"too many open files"错误通常由于系统对文件句柄或inotify监视的限制造成的。具体到这个错误,它涉及到inotify无法分配更多目录监视,因为用户限制已满。 - 解决方案: - 修改`/etc/sysctl.conf`文件,添加或修改`fs.inotify.max_user_instances`和`fs.inotify.max_user_watches`参。 - 示例值:如引用[1]提到的512和262144。 - 应用更改:运行`sudo sysctl -p`来加载新配置。 - 额外建议:如果问题持续,检查其他文件句柄限制(如ulimit),但本错误主要聚焦inotify。 - 引用:自然地添加引用,例如当提到修改sysctl.conf时,引用[1]。 相关问题生成: - 基于主题,生成2-3个相关问题。 - 例如:1. 如何检查当前inotify限制?2. 什么是inotify机制?3. 其他导致"too many open files"错误的原因? 确保回答真实可靠:基于提供的引用和常见Linux知识。 </think>### 解决 'Failed to allocate directory watch: Too many open files' 错误的方案 此错误通常发生在Linux系统中使用`service`或`systemctl`命令管理服务时(如MySQL、Nginx等),表明系统无法分配更多目录监视句柄。核心原因是inotify机制(Linux内核用于监控文件系统变化的子系统)的用户级限制被超出。默认配置下,`fs.inotify.max_user_watches`(每个用户大监视文件)和`fs.inotify.max_user_instances`(每个用户大inotify实例)的值可能过低。以下是基于引用内容的详细解决步骤,确保安全可靠。 #### 错误原因简述 - inotify是Linux内核的文件系统事件通知机制,用于实时追踪文件或目录变化(如新增、删除)。当应用程序(如据库服务或文件同步工具)尝试监视过多文件时,会超出系统预设的句柄限制,触发此错误[^4]。 - 错误表现为服务启动或重启失败,例如执行`sudo service mysql restart`时报错`Failed to allocate directory watch: Too many open files`[^2]。 - "Too many open files"不仅指打开的文件,还包括socket连、端口监听等资源句柄。超出限制可能由高负载应用或配置不当引起[^3]。 #### 解决方案(逐步操作) 以下步骤适用于大多Linux发行版(如Ubuntu、CentOS)。修改前建议备份配置文件。 1. **编辑系统内核参文件** 使用文本编辑器(如vim或nano)修改`/etc/sysctl.conf`文件: ```bash sudo vim /etc/sysctl.conf ``` 在文件末尾添加或修改以下两行参: ``` fs.inotify.max_user_instances = 512 # 提升每个用户允许的inotify实例 fs.inotify.max_user_watches = 262144 # 提升每个用户允许的监视文件 ``` - **参说明**: - `max_user_instances`:默认值通常为128,增加至512可处理更多并发监视请求。 - `max_user_watches`:默认值可能为8192,增加至262144(约26万)适合高文件监视场景(如据库或Web服务)。 - 这些值引用自成功案例,可根据系统内存调整(例如,内存较小系统可设为`max_user_watches=65536`)[^1]。 2. **应用配置更改** 保存文件后,运行以下命令使新参生效: ```bash sudo sysctl -p ``` 此命令加载`/etc/sysctl.conf`的修改,无需重启系统。输出应显示`fs.inotify.max_user_instances = 512`等确认信息。 3. **验证更改并重启服务** - 检查当前inotify限制是否更新: ```bash cat /proc/sys/fs/inotify/max_user_instances # 应返回512 cat /proc/sys/fs/inotify/max_user_watches # 应返回262144 ``` - 重启报错的服务(如MySQL): ```bash sudo service mysql restart # 或使用 systemctl restart mysql ``` 如果错误消失,说明问题已解决。 4. **可选:进一步优化(如果问题持续)** - **检查用户级句柄限制**:运行`ulimit -n`查看当前用户的文件打开限制。如果较低(e.g., 1024),可编辑`/etc/security/limits.conf`添加: ``` * soft nofile 65535 * hard nofile 65535 ``` 然后注销并重新登录。 - **监控资源使用**:使用`lsof | wc -l`查看总打开句柄,或`inotifywatch`工具监视特定目录。 - 如果涉及特定应用(如MySQL),检查其配置文件是否有不必要的文件监视设置[^3]。 #### 注意事项 - **为何有效**:通过提升inotify参,系统能处理更多文件监视事件,避免句柄耗尽。此方法在Ubuntu、CentOS等系统中广泛验证[^1][^2]。 - **风险提示**:过度增加可能导致内存占用上升(每个监视句柄约1KB内存)。建议根据应用需求调整值,例如中等负载服务器使用`max_user_watches=65536`即可。 - **适用场景**:此错误常见于据库服务(如MySQL)、文件同步工具(如inotify-tools)或Web服务器(如Nginx)[^2][^4]。 如果以上步骤未解决,请检查系统日志(`journalctl -xe`)确认是否有其他资源瓶颈。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值