mongo连接数满难题处理,linux最大文件句柄数量计算

  目前布署上线的一个发动机,启动将来内存、日志彰显一切正常,可是表面不或然展开引擎访问。几经周折,在同事的增援下,找出了难点:root用户的open
files为1024,引擎启动时,1024个公文句柄已经用尽。在夜幕看来一篇不错的小说,就转下来了:

  近年来布局上线的一个发动机,启动今后内存、日志展现一切正常,然而表面不只怕举办发动机访问。几经周折,在同事的接济下,找出了难题:root用户的open
files为1024,引擎启动时,1024个文件句柄已经用尽。在夜晚来看一篇不错的篇章,就转下来了:

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

  近年来布局上线的一个发动机,启动今后内存、日志突显一切正常,不过表面不能展开发动机访问。几经周折,在同事的帮带下,找出了难点:root用户的open
files为1024,引擎启动时,1024个文件句柄已经用尽。在晚间看来一篇不错的篇章,就转下来了:

  写这些稿子是为了以爱抚听,网上的小说人云亦云到大概令人切齿。到底最大文件数被哪些范围了?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

 
不过呢,有过多很重大的底细,有不少谬误的讲述,乱七八糟,因而特的在此处做一个认证。

记一回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
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]
mongo连接数满难题处理,linux最大文件句柄数量计算。~]# 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里的设定值  
       

一. 问题:

次第不能连接mongo集群 

现象:

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

 

shell级限制
通过ulimit -n修改,如进行命令ulimit -n
1000,则意味着将日前shell的此时此刻用户所有进度能开拓的最大文件数量设置为1000.

shell级限制
透过ulimit -n修改,如举行命令ulimit -n
1000,则表示将目前shell的目前用户拥有进度能开拓的最大文件数量设置为1000.

二  /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,重新登录进来就见效了。在机械上试试就清楚了,好多少人真的很懒,宁愿各处问也不乐意花一分钟时间实际操作一下。
       

二. 排查及化解

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

telnet 192.168.1.100 20000

正规访问,端口存在

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

翻开进度

ps -ef | grep mongo

翻看端口

netstat -ntlp

肯定进程和端口都正常运转

  1. 翻开日志

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

亚洲必赢app官方下载 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用户的软限制为1000,硬限制为1200,即意味着root用户能打开的最大文件数量为1000,不管它打开多少个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。

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

目前布局上线的一个发动机,启动之后内存、日志突显一切正常,不过表面不大概举行发动机访问…

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环境里,固然只怕会有八个进度,但是充足用度文件句柄的历程不会过多,只是其中某个进度万分用度文件句柄,比如服务器上运行着一个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启动的长河打开的文本数量。为啥会给人限制单个线程的最大文件数量的错觉,因为不少状态下,在一个shell环境里,即便恐怕会有多少个经过,不过丰富成本文件句柄的长河不会过多,只是其中某个进程分外花费文件句柄,比如服务器上运行着一个tomcat,那么就是java进度要占用一大半文本句柄。此时ulimit设置的最大文件数和java进度成本的最大文件数基本是应和的,所以会给人这么的一个错觉。 

  
还有,很多稿子称ulimit -n 只同意设置得愈加小,比如先举行了ulimit -n
1000,在执行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里的文件打开数是2000,如下:

[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启动的长河打开的公文数量。为何会给人范围单个线程的最大文件数量的错觉,因为众多气象下,在一个shell环境里,尽管大概会有七个进程,但是那多少个成本文件句柄的长河不会众多,只是其中某个进程非凡用度文件句柄,比如服务器上运行着一个tomcat,那么就是java进度要占有大部分文件句柄。此时ulimit设置的最大文件数和java进度用度的最大文件数基本是呼应的,所以会给人如此的一个错觉。 

  
再有,很多小说称ulimit -n 只同意设置得越发小,比如先举行了ulimit -n
1000,在执行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里的文件打开数是2000,如下:

[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 1000,
当前session会话生效,则表示将日前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
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将最大文件数设定到5000是打响的:

[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的安装,那也只是一个表象,实际上是因为,逐个用户登录进来,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将最大文件数设定到5000是成功的:

[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的装置,那也只是一个表象,实际上是因为,各种用户登录进来,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是系统提交的提议值,系统会统计资源给出一个和合理性值,一般跟内存有关系,内存越大,改值越大,可是单纯是一个指出值,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是系统提交的提出值,系统会总结资源给出一个和客观值,一般跟内存有关系,内存越大,改值越大,可是单独是一个提出值,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

亚洲必赢app官方下载 ,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决定

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图