写点什么

Too many open files 的四种解决办法

  • 2020-02-17
  • 本文字数:1419 字

    阅读完需:约 5 分钟

Too many open files的四种解决办法

【摘要】 Too many open files 有四种可能:一 单个进程打开文件句柄数过多,二 操作系统打开的文件句柄数过多,三 systemd 对该进程进行了限制,四 inotify 达到上限.


领导见了孔乙己,也每每这样问他,引人发笑。孔乙己自己知道不能和他们谈天,便只好向我们新员工说话。有一回对我说道,“你定位过问题么?”我略略点一点头。他说,“定位过,……我便考你一考。Too many open files,怎样解决?”我想,考评垫底的人,也配考我么?便回过脸去,不再理会。孔乙己等了许久,很恳切的说道,“不能解决罢?……我教给你,记着!这些方法应该记着。将来做接口人的时候,定位问题要用。”我暗想我和接口人的等级还很远呢,而且我们领导也从不将问题定位记功;又好笑,又不耐烦,懒懒的答他道,“谁要你教,不是 ulimit 太小么?”孔乙己显出极高兴的样子,将两个指头的长指甲敲着白板,点头说,“对呀对呀!……Too many open files 有四种可能,你知道么?”我愈不耐烦了,努着嘴走远。孔乙己却像是没有看到,自顾自的在白板上画了起来。

一 单个进程打开文件句柄数过多

ulimit 中的 nofile 表示单进程可以打开的最大文件句柄数,可以通过 ulimit -a 查看,子进程默认继承父进程的限制(注意,是继承,不是共享,子进程和父进程打开的文件句柄数是单独算的)。


网上还有一种解读是 nofile 表示单用户可以打开的文件句柄数,因为他们在 limit.conf 中看到类似于“openstack soft nofile 65536”,便认为是 openstack 用户最多可以打开的文件句柄数。该解读是错误的,“openstack soft nofile 65536”表示的含义是当你执行"su - openstack"切换到 openstack 用户后,你创建的所有进程最大可以打开的文件句柄数是 65536。


要查看一个进程可以打开的文件句柄数,可以通过“cat /proc/<pid>/limits”查看。


要修改 ulimit 中的 nofile,可以通过修改/etc/security/limits.conf 文件,在其中加入类似“openstack soft nofile 65536”的语句来进行修改。修改完成后,可以通过“su - openstack”切换用户,或者重新登录,来使该配置生效。


要动态修改一个进程的限制,可以使用 prlimit 命令,具体用法为:“prlimit --pid ${pid} --nofile=102400:102400”。

二 操作系统打开的文件句柄数过多

整个操作系统可以打开的文件句柄数是有限的,受内核参数“fs.file-max”影响。


可以通过执行“echo 100000000 > /proc/sys/fs/file-max”命令来动态修改该值,也可以通过修改"/etc/sysctl.conf"文件来永久修改该值。

三 systemd 对该进程进行了限制

该场景仅针对被 systemd 管理的进程(也就是可以通过 systemctl 来控制的进程)生效,可以通过修改该进程的 service 文件(通常在/etc/systemd/system/目录下),在“[Service]”下面添加“LimitNOFILE=20480000”来实现,修改完成之后需要执行"systemctl daemon-reload"来使该配置生效。

四 inotify 达到上限

inotify 是 linux 提供的一种监控机制,可以监控文件系统的变化。该机制受到 2 个内核参数的影响:“fs.inotify.max_user_instances”和“fs.inotify.max_user_watches”,其中“fs.inotify.max_user_instances”表示每个用户最多可以创建的 inotify instances 数量上限,“fs.inotify.max_user_watches”表示么个用户同时可以添加的 watch 数目,当出现 too many open files 问题而上面三种方法都无法解决时,可以尝试通过修改这 2 个内核参数来生效。修改方法是修改"/etc/sysctl.conf"文件,并执行"sysctl -p"。


2020-02-17 11:313965

评论

发布
暂无评论
发现更多内容

分布式系统的一些基础理论

俊俊哥

分布式事务 CAP Base

redis里的数据结构

流沙

redis

刘华:上云还是不上云,这是一个问题

刘华Kenneth

架构 敏捷

猿灯塔:spring Boot Starter开发及源码刨析(三)

猿灯塔

Java 猿灯塔

给 Spring Boot 项目减减肥!18.18M 到 0.18M 是如何做到的?

给你买橘子

Java 程序员 Spring Cloud 编码 SpringBoot 2

图说前端-ArrayBuffers 和 SharedArrayBuffers(2/3)

梦见君笑

大前端 内存管理

啃碎并发(九):内存模型之基础概述

猿灯塔

Java 猿灯塔

如果你想写自己的Benchmark框架

程序那些事

JVM 性能调优 GC benchmark

使用 Dockerfile 创建镜像 | Docker 系列

AlwaysBeta

Docker 容器 镜像 Dockerfile

DOM 树的构建

法正

html 大前端 DOM

游戏夜读 | 如何分析游戏体验?

game1night

如何搭建一个HBase集群

Rayjun

HBase

ARTS 打卡 第2周

Scotty

RESTful 架构及实践

Geek_z9ygea

Java 大前端 RESTf

计算机的时钟(一):NTP协议

ElvinYang

如何基于 BitMap 进行海量数据分析

GrowingIO技术专栏

互联网 数据分析 科技互联网 数据化

基于Kubernetes实现的大数据采集与存储实践总结

岿然独存5

Docker Kubernetes S3 EFK Fluentd

那些让程序员目瞪口呆的Bug

Java小咖秀

程序员 bug

java 后端博客系统文章系统——No3

猿灯塔

图说前端-内存管理(1/3)

梦见君笑

大前端 内存

图说前端-使用Atomics避免SharedArrayBuffers中的race conditions(3/3)

梦见君笑

大前端 内存管理

计算机操作系统基础(十七)---进程同步之Unix域套接字

书旅

php laravel 线程 操作系统 进程

无价值人生记录.0:浪费1000%时间去做一个用来节省1%时间的“轮子玩具”(上:因缘)

八苦-瞿昙

C# 程序员 随笔 随笔杂谈 aop

玩转Redis高可用 - 哨兵(Sentinel)模式

Man

高可用 redis高可用 中间件

架构师必须知道的架构知识

Chank

架构 架构师 Architecture Architect

redis系列之——Redis为什么这么快?

诸葛小猿

Java redis 程序员

Git 常用操作汇总-cheat sheet

多选参数

git GitHub gitlab gitee

图解:深度优先搜索与广度优先搜索

淡蓝色

Java 数据结构 算法

Java 线程的生老病死

武培轩

Java 线程 多线程 并发 线程状态

架构师训练营第六周作业

张明森

《精益思想》读后感分享

zhongzhq

高效工作 精益 精益思想 精益生产方式

Too many open files的四种解决办法_服务革新_华为云开发者联盟_InfoQ精选文章