linux最大文件句柄数量总结(转载)

  最近部署上线的一个引擎,启动之后内存、日志显示一切正常,但是外部无法进行引擎访问。几经周折,在同事的协助下,找出了问题:root用户的open files为1024,引擎启动时,1024个文件句柄已经用尽。在晚上看到一篇不错的文章,就转下来了:http://jameswxx.iteye.com/blog/2096461。以下是文章内容:

  写这个文章是为了以正视听,网上的文章人云亦云到简直令人发指。到底最大文件数被什么限制了?too many open files错误到底可以通过什么参数控制?网上的很多文章说的大致步骤是没有错的,大致如下:

shell级限制
通过ulimit -n修改,如执行命令ulimit -n 1000,则表示将当前shell的当前用户所有进程能打开的最大文件数量设置为1000.

用户级限制 
ulimit

-n是设置当前shell的当前用户所有进程能打开的最大文件数量,但是一个用户可能会同时通过多个shell连接到系统,所以还有一个针对用户的限制,通过修改
/etc/security/limits.conf实现,例如,往limits.conf输入以下内容:

root soft nofile 1000
root hard nofile 1200
soft nofile表示软限制,hard nofile表示硬限制,软限制要小于等于硬限制。上面两行语句表示,root用户的软限制为1000,硬限制为1200,即表示root用户能打开的最大文件数量为1000,不管它开启多少个shell。

系统级限制
修改cat /proc/sys/fs/file-max

但是呢,有很多很重要的细节,有很多错误的描述,一塌糊涂,因此特的在这里做一个说明。

一  ulimit -n

网上很多人说,ulimit -n限制用户单个进程的问价打开最大数量。严格来说,这个说法其实是错误的。看看ulimit官方描述:
Provides
control over the resources available to the shell and to processes
started by  it,  on  systems that allow such control.
The
-H and -S options specify that the hard or soft limit is set for the
given resource. A hard limit cannot be increased once it is set; a soft
limit may  be  increased  up  to  the value of the hard limit. If
neither -H nor -S is specified, both the soft and hard limits are set.
The value of limit can be a number in the unit specified for the
resource or one of the special values hard, soft,  or  unlimited, 
which  stand  for  the  current hard limit, the current soft limit, and
no limit,  respectively.

If
limit is omitted, the current value of the soft limit  of  the 
resource  is  printed,  unless  the  -H  option is given.  When more
than one resource is specified, the limit name and unit are  printed
before the value.

 
人家从来就没说过是限制用户的单个进程的最大文件打开数量,看看红色部分,是限制当前shell以及该shell启动的进程打开的文件数量。为什么会给人限制单个线程的最大文件数量的错觉,因为很多情况下,在一个shell环境里,虽然可能会有多个进程,但是非常耗费文件句柄的进程不会很多,只是其中某个进程非常耗费文件句柄,比如服务器上运行着一个tomcat,那么就是java进程要占用大多数文件句柄。此时ulimit设置的最大文件数和java进程耗费的最大文件数基本是对应的,所以会给人这样的一个错觉。

还有,很多文章称ulimit -n 只允许设置得越来越小,比如先执行了ulimit -n 1000,在执行ulimit
-n 1001,就会报"cannot modify limit: Operation not
permitted"错误。这个其实也是不准确的说法。首先要搞清楚,任何用户都可以执行ulimit,但root用户和非root用户是非常不一样的。

非root用户只能越设置越小,不能越设置越大

我在机器上以非root先执行:

[[email protected] etc]$ ulimit -n 900
[[email protected] etc]$

执行成功,再增大:

[[email protected] etc]$ ulimit -n 901
-bash: ulimit: open files: cannot modify limit: Operation not permitted

[[email protected] etc]$

增加失败,如果减少则是OK的:

[[email protected] etc]$ ulimit -n 899

[[email protected] etc]$

如果再增加到900是不行的:

[[email protected] etc]$ ulimit -n 900
-bash: ulimit: open files: cannot modify limit: Operation not permitted

[[email protected] etc]$ 

root用户不受限制

首先切换到root:

[[email protected] etc]$ sudo su -
[[email protected] ~]#

查看下当前限制:

[[email protected] ~]# ulimit -n
1000000

[[email protected] ~]#

增大:

 [[email protected] ~]# ulimit -n 1000001

[[email protected] ~]#

可以成功增大,再减小:

[[email protected] ~]# ulimit -n 999999

[[email protected] ~]#

减小也是成功的,再增大:

 [[email protected] ~]# ulimit -n 1000002

[[email protected] ~]#

也是ok的,可见root是不受限制的。

ulimit里的最大文件打开数量的默认值

如果在limits.conf里没有设置,则默认值是1024,如果limits.con有设置,则默认值以limits.conf为准。例如我换了一台机器,登录进去,ulimit -n显示如下:

[[email protected] ~]# ulimit -n
2000

这是因为我的limits.conf里的文件打开数是2000,如下:

[[email protected] ~]# cat /etc/security/limits.conf

root soft nofile 2000

root hard nofile 2001

如果limits.conf里不做任何限制,则重新登录进来后,ulimit -n显示为1024。

 [[email protected] ~]# ulimit -n

1024

ulimit修改后生效周期

修改后立即生效,重新登录进来后失效,因为被重置为limits.conf里的设定值

二  /etc/security/limits.conf

网上还有缪传,ulimit -n设定的值不能超过limits.conf里设定的文件打开数(即soft nofile)

好吧,其实这要分两种情况,root用户是可以超过的,比如当前limits.conf设定如下:

root soft nofile 2000

root hard nofile 2001

但是我用root将最大文件数设定到5000是成功的:

[[email protected] ~]# ulimit -n 5000
[[email protected] ~]# ulimit -n 
5000
[[email protected] ~]#

但是非root用户是不能超出limits.conf的设定,我切换到wxx,执行命令如下:

[[email protected] ~]# ulimit -n 5000

-bash: ulimit: open files: cannot modify limit: Operation not permitted

[[email protected] etc]$ 

所以网上的说法是错误的,即使非root用户的最大文件数设置不能超过limits.conf的设置,这也只是一个表象,实际上是因为,每个用户登录进来,ulimit
-n的默认值是limits.conf的 soft nofile指定的,但是对于非root用户,ulimit
-n只能越来越小,不能越来越大,其实这个才是真正的原因,但是结果是一样的。

修改了limits.conf需要重启系统?

这个说法非常搞笑,修改了limits.conf,重新登录进来就生效了。在机器上试试就知道了,好多人真的很懒,宁愿到处问也不愿意花一分钟时间实际操作一下。

三  /proc/sys/fs/file-max

网上说,ulimit -n
和limits.conf里最大文件数设定不能超过/proc/sys/fs/file-max的值,这也是搞笑了,/proc/sys/fs/file-max是系统给出的建议值,系统会计算资源给出一个和合理值,一般跟内存有关系,内存越大,改值越大,但是仅仅是一个建议值,limits.conf的设定完全可以超过/proc/sys/fs/file-max。

[[email protected] ~]# cat /proc/sys/fs/file-max
1610495

我将limits.conf里文件最大数量设定为1610496,保存后,打印出来:

[[email protected] ~]# cat /etc/security/limits.conf

root soft nofile1610496

root hard nofile1610496

四  总结一下

  • /proc/sys/fs/file-max限制不了/etc/security/limits.conf
  • 只有root用户才有权限修改/etc/security/limits.conf
  • 对于非root用户, /etc/security/limits.conf会限制ulimit -n,但是限制不了root用户
  • 对于非root用户,ulimit -n只能越设置越小,root用户则无限制
  • 任何用户对ulimit -n的修改只在当前环境有效,退出后失效,重新登录新来后,ulimit -n由limits.conf决定
  • 如果limits.conf没有做设定,则默认值是1024
  • 当前环境的用户所有进程能打开的最大问价数量由ulimit -n决定
时间: 2025-01-02 14:31:32

linux最大文件句柄数量总结(转载)的相关文章

查询修改linux 打开文件句柄数量

查询系统支持最大可打开文件句柄数量: #vi /proc/sys/fs/file-max 查询当前连接用户最大可打开文件句柄数量: #ulimit -a 修改当前连接用户最大可打开文件句柄数量: #ulimit -f 81920 修改linux内核设置最大可打开文件句柄数量: #vi /etc/sysctl.conf fs.file-max=81920 修改系统软硬件支持打开最大够本数量 #vi /etc/security/limit.conf * soft nproc 81920 * hard

【linux】查看某个进程PID对应的文件句柄数量,查看某个进程当前使用的文件句柄数量

================================ 1.linux所有句柄查询 lsof -n|awk '{print $2}'|sort|uniq -c |sort -nr|more 第一列是持有句柄数量,第二列是每个进程的PID 代表各个进程持有的句柄数量 2.查看java或tomcat句柄[查看当前进程持有文件句柄数量][查看当前进程文件句柄最大限制] 2.1查看java程序的PID ps -ef | grep tomcat 2.2查看这个PID持有的句柄数 ls /proc

大战C100K之-Linux内核调优篇--转载

原文地址:http://joyexpr.com/2013/11/22/c100k-4-kernel-tuning/ 早期的系统,系统资源包括CPU.内存等都是非常有限的,系统为了保持公平,默认要限制进程对资源的使用情况.由于Linux的默认内核配置无法满足C100K的要求,因此需要对其进行适当的调优. 我们可以通过 ulimit 查看一下典型的机器默认的限制情况: $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -

新一代 Linux 文件系统 btrfs 简介 【转载】

Btrfs 被称为是下一代 Linux 文件系统.近年来 ext2/3 遇到越来越多的扩展性问题,在期待 ext4 的同时,人们发现了 btrfs,据说它采用了很多先进的文件系统设计,不仅解决了 ext2/3 的扩展性问题,还让人们看到了下一代文件系统所具有的许多其他特性.这一切都让人不禁心生好奇,btrfs 究竟提供了哪些特性?它是如何实现的?本文便围绕这些问题展开探讨,首先研究了 btrfs 所提供的新特性,并简要介绍了 btrfs 内部实现这些特性的原理:然后演示了 btrfs 的常用命令

进程打开的文件句柄数量超过系统默认值1024,就会提示“too many files open”信息

在linux系统中,如果进程打开的文件句柄数量超过系统默认值1024,就会提示"too many files open"信息,所以要调整打开文件句柄限制. 有以下两种方法: 修改etc/security/limits.conf  配置文件,重启后永久生效 在文件的末尾加入下面两段: * soft nofile 65535 * hard nofile 65535 在控制台输入命令,立刻生效,但是重启后就会变成默认值1024 ulimit -SHn 65535 建议用第一种方式,永久生效

查看某个进程PID对应的文件句柄数量,查看某个进程当前使用的文件句柄数量

================================ 1.linux所有句柄查询 lsof -n|awk '{print $2}'|sort|uniq -c |sort -nr|more 第一列是持有句柄数量,第二列是每个进程的PID 代表各个进程持有的句柄数量 2.查看java或tomcat句柄[查看当前进程持有文件句柄数量][查看当前进程文件句柄最大限制] 2.1查看java程序的PID ps -ef | grep tomcat 2.2查看这个PID持有的句柄数 ls /proc

设置Linux打开文件句柄/proc/sys/fs/file-max和ulimit -n的区别

max-file 表示系统级别的能够打开的文件句柄的数量.是对整个系统的限制,并不是针对用户的. ulimit -n 控制进程级别能够打开的文件句柄的数量.提供对shell及其启动的进程的可用文件句柄的控制.这是进程级别的. 对于服务器来说,file-max和ulimit都需要设置,否则会出现文件描述符耗尽的问题. 一般如果遇到文件句柄达到上限时,会碰到"Too many open files"或者Socket/File: Can't open so many files等错误. 为了

Linux系统挂载NTFS文件系统(转载)

转自:http://hermesbox.blogbus.com/logs/47386987.html 今天尝试并成功的将一块500G的移动硬盘挂载到了RHEL5的系统上,甚感欣慰.想到也许以后自己或其他同学们会有类似经历,于是尽量细致的记录于此.     无论是一块安装了Windows/Linux双系统的硬盘,还是通过USB连接的移动硬盘/U盘,都是可以挂载到Linux系统中的.不过由于Windows本身常用的文件系统包括fat32和NTFS,因此还是需要区别的.废话少说,进入正题. 系统环境如

通过SSHFS在RHEL中安全的挂载远程Linux/UNIX目录或文件系统--转载

You can easily mount remote server file system or your own home directory using special sshfs and fuse tools. FUSE - Filesystem in Userspace FUSE is a Linux kernel module also available for FreeBSD, OpenSolaris and Mac OS X that allows non-privileged