您的位置:新葡亰496net > 电脑系统 > 新葡亰496net:mongo连接数满难题管理,Linux最大张

新葡亰496net:mongo连接数满难题管理,Linux最大张

发布时间:2019-06-30 11:24编辑:电脑系统浏览(188)

      近期配备上线的三个斯特林发动机,运营未来内部存款和储蓄器、日志呈现一切平常,不过表面无法张开引擎访问。几经周折,在同事的帮心悸,找寻了难点:root用户的open files为1024,引擎运营时,1023个公文句柄已经用尽。在夜间看到一篇不错的篇章,就转下来了:

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

      近期配备上线的一个内燃机,运营之后内存、日志呈现一切平常,可是表面不能开始展览斯特林发动机访问。几经周折,在同事的声援下,寻找了难题:root用户的open files为1024,引擎运行时,1022个公文句柄已经用尽。在夜间看来一篇不错的小说,就转下来了:

      写这些稿子是为了以注重听,网络的作品未有主见只会回船转舵到俨然令人切齿。到底最大文件数被什么范围了?too many open files错误到底能够透过哪些参数调控?网络的重重小说说的大意步骤是绝非错的,几乎如下:

    新葡亰496net:mongo连接数满难题管理,Linux最大张开文件汇报符数。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集群的故障解析及化解

    Linux最大张开文件陈诉符数

      写这几个稿子是为了以珍视听,英特网的小说盲目跟风到几乎令人切齿。到底最大文件数被怎么样范围了?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
    2000 那是因为自个儿的limits.conf里的文件展开数是两千,如下:[[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.

    二  /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

    新葡亰496net 1

    从log文件中得以看看connection refused because too many open connections: 819,不能够创制越多的总是产生,mongo服务端主动拒绝,形成客户端不也许访问。于是想到系统允许进程打开的的最大文件具柄数的范围。

     

    1.    系统最大展开文件汇报符数:/proc/sys/fs/file-max

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

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

    三. 深入分析消除 

    a.    查看

    系统级限制
    修改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     虚拟内存的上限
    

    $ cat /proc/sys/fs/file-max

     

    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
    

     

    186405

    唯独呢,有好些个很首要的内部意况,有好多张冠李戴的陈说,一塌糊涂,因而特的在那边做二个验证。

    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 一千,在施行ulimit -n 1001,就能够报"cannot modify limit: Operation not permitted"错误。那些实在也是不标准的说法。首先要搞领会,任何用户都能够实践ulimit,但root用户和非root用户是老大不等同的。

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

     

    1. 设置

    一  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先举行:

    [wxx@br162 etc]$ ulimit -n 900
    [新葡亰496net,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里的设定值

     

     

     

    4. 到底最大文件数被哪些范围了?too many open files错误到底能够通过怎么着参数调节?

    shell级限制 
    通过ulimit -n修改,如实行命令ulimit -n 一千, 当前session会话生效,则象征将眼下shell的当下用户具备进度能开发的最大文件数量设置为一千.

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

    系统级限制

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

     

    ulimit修改后生效周期

    修改后马上生效,重新登陆进来后失效,因为被重新载入参数为limits.conf里的设定值。

     

    修改了limits.conf供给重启系统?

    再次登入进来就一蹴而就了。

     

    a.    临时性

    二  /etc/security/limits.conf

    互连网还或然有缪传,ulimit -n设定的值不能够高出limits.conf里设定的公文打开数(即soft nofile)

    好吧,其实那要分二种情景,root用户是足以当先的,比如当前limits.conf设定如下:

    root soft nofile 2000

    root hard nofile 2001

    但是自身用root将最大文件数设定到6000是马到功成的:

    [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。

     

    # echo 1000000 > /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

     

     

    6. 修改limit限制

    #  在文件末尾添加,永久生效
    # vim /etc/security/limits.conf
    mongodb                soft    nofile  100000
    mongodb                hard    nofile  100000
    
    # 切换到mongodb用户下查看
    # ulimit -n 
    100000
    

    重启mongo后,故障恢复生机!

     

    1.    永久性:在/etc/sysctl.conf中设置

    四  总括一下

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

     

    fs.file-max = 1000000

     

    1.    进度最大张开文件汇报符数:user limit中nofile的soft limit

    a.    查看

    $ ulimit -n

    1700000

    1. 设置

    a.    一时性:通过ulimit -Sn设置最大展开文件陈诉符数的soft limit,注意soft limit不能当先hard limit(ulimit -Hn可查阅hard limit),其它ulimit -n暗中同意查看的是soft limit,但是ulimit -n 1九千00则是还要设置soft limit和hard limit。对于非root用户只好设置比原来小的hard limit。

    查看hard limit:

    $ ulimit -Hn

    1700000

    设置soft limit,必须小于hard limit:

    $ ulimit -Sn 1600000

    1.    永恒性:上面包车型地铁诀要只是临时性的,注销重复登入就失效了,而且无法增大hard limit,只可以在hard limit范围内修改soft limit。若要使修改永远有效,则须要在/etc/security/limits.conf中张开安装(要求root权限),可加多如下两行,表示用户chanon最大展开文件呈报符数的soft limit为1700000,hard limit为贰仟000。以下设置必要注销之后再行登陆技巧见效:

    chanon           soft    nofile          1800000

    chanon           hard   nofile          2000000

    设置nofile的hard limit还大概有有个别要留神的正是hard limit无法超出/proc/sys/fs/nr_open,假如hard limit大于nr_open,注销后不可能寻常登录。能够修改nr_open的值:

    # echo 2000000 > /proc/sys/fs/nr_open

     

    1.    查看当前系统运用的张开文件汇报符数

    [[email protected] bin]# cat /proc/sys/fs/file-nr

    5664        0        186405

    里头第三个数表示近期系统已分配使用的开发文件叙述符数,第2个数为分配后已出狱的(如今已不复采用),第八个数等于file-max。

     

    1.    总结:

    a.    全数进度打开的文本叙述符数不能够当先/proc/sys/fs/file-max

    b.    单个进度打开的文书陈说符数无法超越user limit中nofile的soft limit

    c.    nofile的soft limit无法超越其hard limit

    d.    nofile的hard limit不可能超越/proc/sys/fs/nr_open

     

    1. 系统最大张开文件陈诉符数:/proc/sys/fs/file-max a. 查看 $ cat /proc/sys/fs/file-max 186405 2. 安装 a. 有的时候性 # echo 10000...

    本文由新葡亰496net发布于电脑系统,转载请注明出处:新葡亰496net:mongo连接数满难题管理,Linux最大张

    关键词:

上一篇:没有了

下一篇:没有了