too many open files、超级的坏块

发布时间:2024年01月03日

文件系统上有超级的坏块

xfs_repair /dev/sdb1 -L
#检查和修复 XFS 文件系统
#-L 选项是为了将任何损坏的文件或目录都移动到 lost+found 目录中。
#lost+found 目录是 XFS 文件系统用于存储修复过程中找到的损坏文件和目录的地方。

打开了太多的文件

sysctl -w fs.file-max=1000000
#/etc/security/limits.conf或/etc/sysctl.conf改变:
#fs.file-max = 1000000
#fs.file-max: 控制系统级别的文件描述符总数。

fs.nr_open: 控制单个进程可以打开的文件描述符的最大数量。
单个进程的文件描述符限制可以通过 ulimit 命令来设置。
/proc/sys/fs/nr_open 是一个系统级别的全局参数,表示系统中所有进程能够打开的文件描述符总数的限制。

  • soft nofile 65535
  • hard nofile 65535
    这两个值都需要小于/proc/sys/fs/nr_open设置的值
    在许多 Linux 内核中,默认值可能是 1048576(2^20)
    关于 nr_open 的最大值,它是在 32 位系统上是 2^32 - 1,即 4294967295;
    在 64 位系统上是 2^64 - 1,即 18446744073709551615。这是因为文件描述符的数量是一个无符号整数,其最大值取决于系统的架构。这个值通常是一个非常大的数字,足够满足绝大多数的应用场景。
在实际应用中,如果你遇到了文件描述符不足的问题,可能需要优化你的应用程序或系统配置,而不是直接调整这个值。提高文件描述符总数的上限是有风险的,因为它会占用更多的系统资源。

# 当你报错
### failed to create fsnotify watcher: too many open filesfailed to create fsnotify watcher: too many open files
```bash
vi /etc/sysctl.conf

fs.inotify.max_user_instances=819200
fs.inotify.max_queued_events=1638400
fs.inotify.max_user_watches=52428800
sysctl -p
改这些就是在改 /proc/sys/fs/inotify/max_user_watches 下对应的文件

fs.inotify.max_user_instances:
含义: 限制单个用户能够创建的 inotify 实例的数量。 默认值: 取决于内核版本,通常是 128。 为什么会影响问题:
如果此值太低,用户将无法创建足够的 inotify 实例来监视文件和目录,可能导致 too many open files
错误。通过将其增加到 819200,你提高了系统同时处理的 inotify 实例的数量,从而有助于避免相关的错误。

fs.inotify.max_queued_events:
含义: 限制 inotify 队列中待处理事件的数量。 默认值: 通常是 16384。 为什么会影响问题:
如果监视的事件发生得太快,队列可能会变满,导致后续事件丢失。通过增加此值,你扩大了系统处理事件的缓冲区,有助于防止队列溢出。

fs.inotify.max_user_watches:
含义: 限制单个用户能够为其监视的文件和目录设置的监视器(watches)的总数。 默认值: 通常是 8192。 为什么会影响问题:
如果监视的文件或目录数量太多,可能会达到默认的监视器数目上限,导致 too many open files 错误。通过将其增加到
52428800,你提高了单个用户可以设置的监视器的数量,从而有助于避免相关的错误。 总体来说,通过调整这些 inotify
参数,你扩大了系统处理文件系统事件的容量,从而减少了 too many open files
错误的可能性。需要注意的是,在调整这些参数时,要确保系统资源足够,以及对应的硬件和内核版本支持所需的数值。在生产环境中,调整这些参数之前最好进行适当的测试和评估。

文章来源:https://blog.csdn.net/weixin_55000003/article/details/134744374
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。