fs.inotify.max_user_watches默认值太小,导致too many open files

看到too many open files可能想到fs.file-max参数,其实还受下面参数影响:

  1. fs.inotify.max_queued_events:表示调用inotify_init时分配给inotify instance中可排队的event的数目的最大值,超出这个值的事件被丢弃,但会触发IN_Q_OVERFLOW事件。
  2. fs.inotify.max_user_instances:表示每一个real user ID可创建的inotify instatnces的数量上限,默认128.
  3. fs.inotify.max_user_watches:表示同一用户同时可以添加的watch数目(watch一般是针对目录,决定了同时同一用户可以监控的目录数量)
  4. 查看系统默认参数值:
  5. [[email protected] ~]#sysctl -a | grep max_queued_events
  6. fs.inotify.max_queued_events= 16384
  7. [[email protected] ~]#sysctl -a | grep max_user_watches
  8. fs.inotify.max_user_watches= 8192
  9. fs.epoll.max_user_watches= 201707
  10. [[email protected] ~]#sysctl -a | grep max_user_instances
  11. fs.inotify.max_user_instances= 128

建议修改系统默认参数,方法如下(vi /etc/sysctl.conf):

  1. fs.inotify.max_user_instances=8192
  2. 或者
  3. vim /etc/sysctl.conf
  4. fs.inotify.max_queued_events= 99999999
  5. fs.inotify.max_user_watches= 99999999
  6. fs.inotify.max_user_instances= 65535

注意: max_queued_events 是inotify管理的队列的最大长度,文件系统变化越频繁,这个值就应该越大。如果你在日志中看到Event Queue Overflow,说明max_queued_events太小需要调整参数后再次使

时间: 2024-11-08 07:54:02

fs.inotify.max_user_watches默认值太小,导致too many open files的相关文章

ssas 为绑定指定的大小太小,导致一个或多个列值被截断

错误信息:ssas 为绑定指定的大小太小,导致一个或多个列值被截断 如果更改了某个维度或是事实表的字段长度,在处理CUBE时提示此错误,我们要做以下更新: 1.刷新数据源视图. 2.打开多维数据集,查看代码,去修改相关字段的DataSize. 3.如果是维度,还要打开维度,去修改相关字段的DataSize.

inotify报错Failed to watch /opt; /proc/sys/fs/inotify/max_user_watches,K哥

2016.11.8 K哥有2台服务器使用了unison+inotify达到网站文件夹时时同步的效果 今天突然发现inotify占用很大CPU,可以用top命令查看 打开inotify日志查看原因 发现这一报错 Failed to watch /opt; upper limit on inotify watches reached!Please increase the amount of inotify watches allowed per user via `/proc/sys/fs/ino

python 函数默认值的小坑啊

import datetime import time def test(day=datetime.datetime.now()): print day while True: test() time.sleep(1) run result: 2015-06-05 16:52:47.106000 2015-06-05 16:52:47.106000 2015-06-05 16:52:47.106000 2015-06-05 16:52:47.106000 2015-06-05 16:52:47.

php中max_input_vars默认值为1000导致多表单提交失败

转载于:http://54im.com/php-2/php-max-input-vars-default-value-1000-fail-post-form.html 公司内一个php的后台管理系统,之前运行在apache上,后来我给转到nginx+php上后,其他功能运行正常,有一个修改功能提交表单后没有提交成功,查了代码没查出来什么问题,后来看了下php error日志,也没有什么线索,打印post请求后,也发现提交表单个数和正在表单个数对不上(当时怀疑过是不是某个插件是不是没装,字符集对不

Linux重启inotify配置max_user_watches无效被恢复默认值8192的正确修改方法

Linux下Rsync+inotify-tools实现数据实时同步中有一个重要的配置就是设置Inotify的max_user_watches值,如果不设置,当遇到大量文件的时候就会出现出错的情况. 一般网上修改方法就是直接修改文件: /proc/sys/fs/inotify/max_user_watches 或者修改方法: sysctl -w fs.inotify.max_user_watches="99999999" 但是这些修改后,Linux系统重启inotify配置max_use

tail: inotify cannot be used, reverting to polling: Too many open files

tail -f catalina.out 出现警告: lsof | awk '{ print $2; }' | sort -rn | uniq -c | sort -rn | head 查到是tomcat进程打开了很多文件,处理方法: 在 /etc/sysctl.conf文件中加入下面的配置: fs.inotify.max_user_watches=1048576fs.inotify.max_user_instances=1048576 sysctl -p /etc/sysctl.conf 使修

容器数量增加香港赛马平台搭建导致fs.inotify.max_user_instances超过限制

1.现象描述2.问题分析3.解决办法4.总结5.参考链接1.现象描述 平台架构:Rancher,k8s,微服务 问题的香港赛马平台搭建论坛:haozbbs.com Q1446595067 出现发生在最近,当服务的数量增加到一定程度时,出现了容器日志不定期丢失的情况,通过以下方式均没有日志信息输出:1)通过Rancher,Kubernetes UI查看容器日志2)通过docker logs查看2.问题分析2.1 初步分析 由于是日志出现问题,首先考虑到的是rsyslog和journal服务是否工作

【H3 BPM工作流程管理产品小故事】第二篇 文本默认值

Boss感觉方便了很多,然而采购部采购员阿海却还是有点意见,他跑来找小明. 阿海:现在申请都是我在提交,申请人和申请部门能不能不要每次都要填写啊,好麻烦的.小明:没问题,这个简单.小明在表单中把申请人.申请部门的"DefaultValue"属性分别设为"{Originator.UserName}"."{Originator.OUName}",保存然后预览了一下效果,果然OK,阿海满意而归. 默认值属性 文章来源于:H3 BPM社区 http://

ORA-06502: PL/SQL: 数字或值错误 : 字符串缓冲区太小解决办法

1.今天写的存储过程在执行过程中,报如下错误. exec PRO_T_008pro_update_add_delete(17,1,1,1,1,45.0,54.0,45.0,45.0,45.0,54.0,45.0,54.0,'生产厂家','CYB10-2',54.0,45.0,25.0,1.0,45.0,25.0,1.0,45.0,25.0,1.0,45.0,1,4545.0,0,0,0,'no'); begin PRO_T_008pro_update_add_delete(17,1,1,1,1,