近年来布署上线的三个发动机,运营之后内存、日志显示一切不荒谬,然而表面无法开展发动机访问。几经周折,在同事的助手下,找出了难点:root用户的open
files为1024,引擎运维时,10二十三个文本句柄已经用尽。在晚间观察一篇不错的文章,就转下来了:

  近年来安插上线的二个发动机,运转未来内存、日志突显一切平日,然而表面无法举办发动机访问。几经周折,在同事的接济下,找出了难题:root用户的open
files为1024,引擎运营时,10二十四个文件句柄已经用尽。在早晨观望一篇不错的篇章,就转下来了:

linux最大文件句柄数量统计(转发),linux句柄

  目前安插上线的多个发动机,运转以往内存、日志突显一切不奇怪,可是表面不可以展开发动机访问。几经周折,在同事的帮扶下,找出了难题:root用户的open
files为1024,引擎运维时,10二十五个文件句柄已经用尽。在夜晚收看一篇不错的稿子,就转下来了:

  写这些文章是为着以着重听,网上的小说人云亦云到几乎令人切齿。到底最大文件数被如何范围了?too
many open
files错误到底可以经过什么参数控制?网上的不在少数文章说的大体步骤是绝非错的,大约如下:

shell级限制
通过ulimit -n修改,如举行命令ulimit -n
一千,则意味着将日前shell的当前用户拥有进度能打开的最大文件数量设置为一千.

用户级限制 
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

 
不过呢,有不可胜举很关键的底细,有很多荒唐的叙述,一无可取,因而特的在那边做二个证实。

记两回mongo服务端不可以树立越来越多连接造成的客户端无法访问mongo集群的故障分析及化解

  写这一个稿子是为了以重视听,网上的小说人云亦云到大概令人切齿。到底最大文件数被什么范围了?too
many open
files错误到底可以透过什么样参数控制?网上的过多小说说的大概步骤是尚未错的,几乎如下:

  写那几个稿子是为了以器重听,网上的小说人云亦云到大致令人发指。到底最大文件数被什么范围了?too
many open
files错误到底可以透过哪些参数控制?网上的累累稿子说的大体步骤是没有错的,大约如下:

一  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
一千,在执行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
2000linux最大文件句柄数量总计,mongo连接数满难点处理。 那是因为本人的limits.conf里的文件打开数是3000,如下:[[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里的设定值  
       

一. 问题:

程序不能连接mongo集群 

现象:

2017-09-05T01:29:08.765+0000 I NETWORK  [thread2] connection refused because too many open connections: 819

 

shell级限制
透过ulimit -n修改,如举行命令ulimit -n
一千,则意味将近年来shell的如今用户拥有进度能打开的最大文件数量设置为1000.

shell级限制
经过ulimit -n修改,如进行命令ulimit -n
1000,则象征将如今shell的眼下用户全体进度能开拓的最大文件数量设置为一千.

二  /etc/security/limits.conf

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

好呢,其实那要分两种情景,root用户是可以当先的,比如当前limits.conf设定如下:
*root soft nofile 2000

  • root hard nofile 2001 不过自身用root将最大文件数设定到五千是马到成功的:
    [[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,重新登录进来就一蹴而就了。在机械上尝试就了然了,好多个人真正很懒,宁愿各处问也不情愿花一分钟时间实际操作一下。
       

二. 排查及缓解

  1. 地面测试访问mongo主机及端口

telnet 192.168.1.100 20000

健康访问,端口存在

  1. 登陆mongo主机查看进程和端口是或不是留存。

翻看进度

ps -ef | grep mongo

查阅端口

netstat -ntlp

确认进程和端口都健康运作

  1. 查阅日志

tail -f /data/mongodb/log/mongos.log

澳门金沙国际 1

从log文件中能够看到connection refused because too many open connections:
819,不只怕树立越来越多的连日造成,mongo服务端主动拒绝,造成客户端不大概访问。于是想到系统允许进程打开的的最大文件具柄数的限量。

 

用户级限制 
ulimit
-n是设置当前shell的脚下用户拥有进度能打开的最大文件数量,不过一个用户或者会同时经过三个shell连接受系统,所以还有贰个针对性用户的界定,通过改动
/etc/security/limits.conf完成,例如,往limits.conf输入以下内容:

root soft
nofile 1000

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

用户级限制 
ulimit
-n是设置当前shell的当下用户拥有进度能开拓的最大文件数量,不过3个用户只怕会同时通过多少个shell连接受系统,所以还有3个对准用户的限定,通过修改
/etc/security/limits.conf已毕,例如,往limits.conf输入以下内容:

root soft
nofile 1000

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

三  /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*    

三. 分析化解 

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

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

四  统计一下

  • /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决定

近年来布署上线的3个发动机,运行未来内存、日志显示一切不荒谬,但是表面无法进展发动机访问…

1. 翻看系统默许的最大文件句柄数,系统暗中同意是1024

# ulimit -n
1024
参数:
命令参数
-a      显示所有限制
-c      core文件大小的上限
-d      进程数据段大小的上限
-f      shell所能创建的文件大小的上限
-m     驻留内存大小的上限
-s      堆栈大小的上限
-t      每秒可占用的CPU时间上限
-p     管道大小
-n     打开文件数的上限
-u     进程数的上限
-v     虚拟内存的上限

 

 

2. 查看当前进度打开了略微句柄数

# lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more
14505 2684
13937 2781
12992 2492
11616 2361
10486 2583
#其中第一列是打开的句柄数,第二列是进程ID。

据悉进程PID查看进度名

# ps -ef | grep 2684
mongodb   2684     1  0 04:19 ?        00:00:38 mongod -f /data/mongodb/config/shard2.conf

 

而是呢,有众多很首要的底细,有恒河沙数荒唐的叙述,一塌糊涂,因而特的在此地做三个表达。

而是呢,有为数不少很重大的细节,有许多谬误的描述,一塌糊涂,因而特的在那里做二个阐明。

3. 什么是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环境里,纵然只怕会有两个进度,可是丰富费用文件句柄的进程不会过多,只是其中有个别进程格外开销文件句柄,比如服务器上运维着1个tomcat,那么就是java进程要占用一大半文件句柄。此时ulimit设置的最大文件数和java进程用度的最大文件数基本是应和的,所以会给人那样的一个错觉。 

   
还有,很多稿子称ulimit -n 只同意设置得尤其小,比如先实施了ulimit -n
1000,在执行ulimit -n 1001,就会报”cannot modify limit: Operation not
permitted”错误。这一个实际也是不准确的传道。首先要搞明白,任何用户都得以执行ulimit,但root用户和非root用户是十分差距等的。

注:
非root用户只好越设置越小,无法越设置越大,root用户不受限制

 

一  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运转的历程打开的文本数量。为啥会给人范围单个线程的最大文件数量的错觉,因为不少情状下,在2个shell环境里,尽管大概会有几个进程,可是丰硕开销文件句柄的历程不会过多,只是其中某些进程十分开支文件句柄,比如服务器上运转着三个tomcat,那么就是java进度要占有大多数文件句柄。此时ulimit设置的最大文件数和java进度费用的最大文件数基本是相应的,所以会给人那样的一个错觉。 

  
还有,很多稿子称ulimit -n 只同意设置得愈加小,比如先举办了ulimit -n
一千,在执行ulimit -n 1001,就会报”cannot modify limit: Operation not
permitted”错误。那一个实际也是不确切的布道。首先要搞领会,任何用户都足以执行ulimit,但root用户和非root用户是10分不雷同的。

非root用户只可以越设置越小,不只怕越设置越大

自小编在机器上以非root先进行:

[wxx@br162 etc]$ ulimit -n 900
[wxx@br162 etc]$

举办成功,再附加:

[wxx@br162 etc]$ ulimit -n 901
-bash: ulimit: open files: cannot modify
limit: Operation not permitted

[wxx@br162 etc]$

充实战败,要是缩减则是OK的:

[wxx@br162 etc]$ ulimit -n 899

[wxx@br162 etc]$

若果再增加到900是非常的:

[wxx@br162 etc]$ ulimit -n 900
-bash: ulimit: open files: cannot modify
limit: Operation not permitted

[wxx@br162 etc]$ 

 

root用户不受限制

首先切换成root:

[wxx@br162 etc]$ sudo su –
[root@br162 ~]#

翻开下当前范围:

[root@br162 ~]# ulimit -n
1000000

[root@br162 ~]#

增大:

 [root@br162 ~]# ulimit -n
1000001

[root@br162
~]#

可以成功外加,再减小:

[root@br162 ~]# ulimit -n 999999

[root@br162 ~]#

减小也是水到渠成的,再附加:

 [root@br162 ~]# ulimit -n
1000002

[root@br162
~]#

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

 

ulimit里的最大文件打开数量的暗许值

要是在limits.conf里从未安装,则默认值是1024,假诺limits.con有设置,则暗许值以limits.conf为准。例如作者换了一台机械,登录进去,ulimit
-n彰显如下:

[root@zk203 ~]# ulimit -n
2000

那是因为本身的limits.conf里的文件打开数是两千,如下:

[root@zk203 ~]# cat
/etc/security/limits.conf

root soft nofile 2000

root hard nofile 2001

万一limits.conf里不做别的限制,则再次登录进来后,ulimit -n展现为1024。

 [root@zk203 ~]# ulimit -n

1024

 

ulimit修改后生效周期

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

 

 

 

一  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运行的长河打开的公文数量。为啥会给人限制单个线程的最大文件数量的错觉,因为不少地方下,在2个shell环境里,即便只怕会有五个进度,然则丰硕成本文件句柄的进程不会过多,只是其中有些进度卓殊费用文件句柄,比如服务器上运转着二个tomcat,那么就是java进度要占用超过一半文本句柄。此时ulimit设置的最大文件数和java进度花费的最大文件数基本是应和的,所以会给人如此的一个错觉。 

  
再有,很多篇章称ulimit -n 只允许设置得越发小,比如先实施了ulimit -n
一千,在执行ulimit -n 1001,就会报”cannot modify limit: Operation not
permitted”错误。这一个实际也是不纯粹的说教。首先要搞精晓,任何用户都可以执行ulimit,但root用户和非root用户是丰裕不平等的。

非root用户只好越设置越小,无法越设置越大

本身在机械上以非root先实施:

[wxx@br162 etc]$ ulimit -n 900
[wxx@br162 etc]$

执行成功,再附加:

[wxx@br162 etc]$ ulimit -n 901
-bash: ulimit: open files: cannot modify
limit: Operation not permitted

[wxx@br162 etc]$

充实失败,假使缩减则是OK的:

[wxx@br162 etc]$ ulimit -n 899

[澳门金沙国际,wxx@br162 etc]$

一旦再充实到900是格外的:

[wxx@br162 etc]$ ulimit -n 900
-bash: ulimit: open files: cannot modify
limit: Operation not permitted

[wxx@br162 etc]$ 

 

root用户不受限制

首先切换成root:

[wxx@br162 etc]$ sudo su –
[root@br162 ~]#

翻开下当前界定:

[root@br162 ~]# ulimit -n
1000000

[root@br162 ~]#

增大:

 [root@br162 ~]# ulimit -n
1000001

[root@br162
~]#

可以成功外加,再减小:

[root@br162 ~]# ulimit -n 999999

[root@br162 ~]#

减小也是马到成功的,再附加:

 [root@br162 ~]# ulimit -n
1000002

[root@br162
~]#

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

 

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

只要在limits.conf里没有设置,则默许值是1024,假使limits.con有设置,则暗中认可值以limits.conf为准。例如作者换了一台机械,登录进去,ulimit
-n突显如下:

[root@zk203 ~]# ulimit -n
2000

这是因为作者的limits.conf里的文件打开数是3000,如下:

[root@zk203 ~]# cat
/etc/security/limits.conf

root soft nofile 2000

root hard nofile 2001

即使limits.conf里不做别的限制,则再一次登录进来后,ulimit -n呈现为1024。

 [root@zk203 ~]# ulimit -n

1024

 

ulimit修改后生效周期

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

 

 

 

4. 终究最大文件数被哪些范围了?too many open files错误到底可以通过什么参数控制?

shell级限制 
经过ulimit -n修改,如举办命令ulimit -n 一千,
当前session会话生效,则意味将眼下shell的目前用户全部进度能开拓的最大文件数量设置为一千.

用户级限制  
ulimit
-n是设置当前shell的当下用户拥有进度能开拓的最大文件数量,可是2个用户只怕会同时通过四个shell连接受系统,所以还有3个对准用户的范围,通过修改
/etc/security/limits.conf已毕,例如,往limits.conf输入以下内容:
root soft nofile 1000 
root hard nofile 1200
soft nofile表示软限制,hard
nofile表示硬限制,软限制要低于等于硬限制。上边两行语句表示,root用户的软限制为1000,硬限制为1200,即意味着root用户能打开的最大文件数量为一千,不管它开启几个shell。

系统级限制

# cat /proc/sys/fs/file-max
1637385

 

ulimit修改后生效周期

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

 

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

重新登录进来就一蹴而就了。

 

二  /etc/security/limits.conf

网上还有缪传,ulimit
-n设定的值无法当先limits.conf里设定的文书打开数(即soft nofile)

可以吗,其实那要分三种意况,root用户是足以当先的,比如当前limits.conf设定如下:

root soft
nofile 2000

root hard nofile 2001

但是自身用root将最大文件数设定到四千是旗开得胜的:

[root@zk203 ~]# ulimit -n 5000
[root@zk203 ~]# ulimit -n 
5000
[root@zk203 ~]#

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

[wxx@zk203 ~]# ulimit -n 5000

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

[wxx@zk203 etc]$ 

由此网上的传道是不当的,尽管非root用户的最大文件数设置不或然超过limits.conf的安装,那也只是3个表象,实际上是因为,各种用户登录进来,ulimit
-n的暗中同意值是limits.conf的 soft nofile内定的,不过对于非root用户,ulimit
-n只好进一步小,不可以进一步大,其实那几个才是的确的由来,可是结果是一样的。

 

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

以此说法拾分搞笑,修改了limits.conf,重新登录进来就见效了。在机械上摸索就清楚了,好三个人实在很懒,宁愿遍地问也不甘于花一分钟时间实际操作一下。

 

 

二  /etc/security/limits.conf

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

行吗,其实那要分三种景况,root用户是可以当先的,比如当前limits.conf设定如下:

root soft
nofile 2000

root hard nofile 2001

可是本身用root将最大文件数设定到伍仟是成功的:

[root@zk203 ~]# ulimit -n 5000
[root@zk203 ~]# ulimit -n 
5000
[root@zk203 ~]#

可是非root用户是不大概超出limits.conf的设定,小编切换来wxx,执行命令如下:

[wxx@zk203 ~]# ulimit -n 5000

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

[wxx@zk203 etc]$ 

故而网上的说法是漏洞卓殊多的,就算非root用户的最大文件数设置不只怕当先limits.conf的安装,这也只是1个表象,实际上是因为,各个用户登录进来,ulimit
-n的暗中同意值是limits.conf的 soft nofile钦定的,不过对于非root用户,ulimit
-n只好进一步小,不或然进一步大,其实那几个才是真正的原由,不过结果是一致的。

 

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

其一说法拾贰分搞笑,修改了limits.conf,重新登录进来就卓有功能了。在机械上尝试就通晓了,好五人实在很懒,宁愿四处问也不情愿花一分钟时间实际操作一下。

 

 

5. 文件/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。

 

三  /proc/sys/fs/file-max

网上说,ulimit -n
和limits.conf里最大文件数设定不可以超越/proc/sys/fs/file-max的值,那也是搞笑了,/proc/sys/fs/file-max是系统提交的提议值,系统会计算能源给出二个和合理值,一般跟内存有关系,内存越大,改值越大,可是单纯是1个指出值,limits.conf的设定完全可以当先/proc/sys/fs/file-max。

[root@zk203 ~]# cat
/proc/sys/fs/file-max

  • 1610495*

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

[root@zk203 ~]# cat
/etc/security/limits.conf

root soft
nofile1610496

root hard nofile1610496

 

 

三  /proc/sys/fs/file-max

网上说,ulimit -n
和limits.conf里最大文件数设定不能够跨越/proc/sys/fs/file-max的值,那也是搞笑了,/proc/sys/fs/file-max是系统提交的指出值,系统会总括财富给出多少个和成立值,一般跟内存有关系,内存越大,改值越大,可是偏偏是1个提议值,limits.conf的设定完全能够超越/proc/sys/fs/file-max。

[root@zk203 ~]# cat
/proc/sys/fs/file-max

  • 1610495*

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

[root@zk203 ~]# cat
/etc/security/limits.conf

root soft
nofile1610496

root hard nofile1610496

 

 

6. 修改limit限制

#  在文件末尾添加,永久生效
# vim /etc/security/limits.conf
mongodb                soft    nofile  100000
mongodb                hard    nofile  100000

# 切换到mongodb用户下查看
# ulimit -n 
100000

重启mongo后,故障复苏!

 

四  总括一下

  • /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决定

四  计算一下

  • /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决定

四. 总结

  • /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决定

 

相关文章