• ulimit设置以及相关报错解决方法 [Nginx: could not build the server_names_hash"]


    一、访问Nginx时,报错:"accept() failed (24: Too many open files)"
    原因时:nginx的连接数超过了系统设定的最大值造成的.
    处理办法如下: 

    [root@kvm-server nginx]# ulimit -n
    1024
    [root@kvm-server nginx]# ulimit -n 655360       #把打开文件数设置足够大,这是临时修改方案
    [root@kvm-server nginx]# ulimit -n
    655360
    
    同时修改nginx.conf文件,添加下面内容,然后重启nginx
    worker_rlimit_nofile 655350;
    
    这样就可以解决Nginx连接过多的问题,Nginx就可以支持高并发。
    另外, ulimit -n 还会影响到mysql 的并发连接数。提高文件连接数设置,也能提高mysql并发。
    
    注意: 用ulimit -n 655360 修改只对当前的shell有效,退出后失效。所以,需要永久性修改
    永久生效方法:
    修改/etc/security/limits.conf,在文件底部添加:
    * soft nofile 655360
    * hard nofile 655360
    星号代表全局, soft为软件,hard为硬件,nofile为这里指可打开文件数。
    
    另外,要使limits.conf文件配置生效,必须要确保 pam_limits.so 文件被加入到启动文件中。
    查看 /etc/pam.d/login 文件中有:
    session required /lib/security/pam_limits.so
    
    这样,问题就迎刃而解了!
    

    ulimit : 设置最大进程数和最大文件打开数, 这个一般是系统优化的必要手段.

    1) 临时修改
    为了优化linux性能,可能需要修改这个最大值。临时修改的话ulimit -n 655360就可以了,重启后失效。
    [root@localhost ~]# ulimit -n
    1024
    [root@localhost ~]# ulimit -n 655360
    [root@localhost ~]# ulimit -n
    655360
    
    2) 永久修改
    修改/etc/security/limits.conf文件, 在文件末尾添加
    [root@localhost ~]# vim /etc/security/limits.conf
    
    * soft nofile 655360
    * hard nofile 655360
    * soft nproc 655360
    * hard nproc 655360
    
    =============================
    上面配置内容中:
    *               代表针对所有用户 
    noproc     是代表最大进程数 
    nofile      是代表最大文件打开数
    
    如上修改后重启服务或服务器,如果发现没更改过来, 还需要修改下面梁文文件
    
    在/etc/security/limits.d/90-nproc.conf文件末尾添加
    [root@localhost ~]# vim /etc/security/limits.d/90-nproc.conf
    * soft nproc 655360
    * hard nproc 655360
    
    在/etc/security/limits.d/def.conf文件末尾添加
    [root@localhost ~]# vim /etc/security/limits.d/def.conf
    * soft nofile 655360
    * hard nofile 655360
    
    然后重启后生效

    二、普通用户登录系统,报错:"-bash: ulimit: open files: cannot modify limit: Operation not permitted"

    [root@locahost ~]# ssh -p22 work@172.16.60.20
    Authorized only. All activity will be monitored and reported
    Last login: Wed Dec 18 19:19:59 2019 from 172.16.60.11
    -bash: ulimit: open files: cannot modify limit: Operation not permitted
    -bash: ulimit: data seg size: cannot modify limit: Operation not permitted
    -bash: ulimit: max memory size: cannot modify limit: Operation not permitted
    -bash-4.1$ 
    
    -bash-4.1$ ulimit -n
    1024
    
    登录172.16.60.20机器的root用户查看
    [root@server-20 ~]# ulimit -n
    32726
    [root@server-20 ~]# cat /etc/security/limits.conf
    ........
    # End of file
    work             soft    nproc           8192
    work             hard    nproc           8192
    work             soft    nofile          16384
    work             hard    nofile          32768
    
    以上work普通用户登录系统后,出现"-bash: ulimit: open files: cannot modify limit: Operation not permitted."报错,
    并且work普通用户下查看ulimit数值是默认的1024,设置的ulimit值(32678)并没有生效!
    
    解决办法:
    修改sshd_config文件,将UseLogin默认的no改为yes
    [root@server-20 ~]# /etc/ssh/sshd_config
    .......
    UseLogin yes     
    
    然后重启sshd服务
    [root@server-20 ~]# service sshd restart
    
    再次登录172.16.60.20的work用户,就不会出现上面的报错信息了
    [root@locahost ~]# ssh -p22 work@172.16.60.20
    Authorized only. All activity will be monitored and reported
    Last login: Wed Dec 18 19:54:47 2019 from 172.20.20.161
    -bash-4.1$ 
    
    -bash-4.1$ ulimit -n
    32768
    
    =============================================================================================
    UseLogin 指令
    表示是否在交互式会话的登录过程中使用 login(1) 。默认值是"no"。
    
    如果开启此UseLogin指令,那么 X11Forwarding 将会被禁止,因为 login(1) 不知道如何处理 xauth(1) cookies 。
    需要注意的是,login(1) 是禁止用于远程执行命令的。如果指定了 UsePrivilegeSeparation ,那么它将在认证完成后被禁用。

    三、重启Nginx时, 出现报错提示: "could not build the server_names_hash, you should increase server_names_hash_bucket_size: 64"

    解释说明: 保存服务器名字的hash表是由指令 server_names_hash_max_size 和 server_names_hash_bucket_size所控制的。参数hash bucket size总是等于hash表的大小,并且是一路处理器缓存大小的倍数。在减少了在内存中的存取次数后,使在处理器中加速查找hash表键值成为可能。如果 hash bucket size等于一路处理器缓存的大小,那么在查找键的时候,最坏的情况下在内存中查找的次数为2。第一次是确定存储单元的地址,第二次是在存储单元中查找键值。因此,如果Nginx给出需要增大 hash max size 或 hash bucket size的提示,那么首要的是增大前一个参数的大小.

    解决办法在nginx配置文件nginx.conf里的http{}段增加一行配置"server_names_hash_bucket_size 64;" ,如果64还不够,那么就按32的倍数往上加,比如128或256或512。

    四、Nginx出现500 Internal Server Error 错误的解决方案

    500(服务器内部错误)      服务器遇到错误,无法完成请求。
    501(尚未实施)           服务器不具备完成请求的功能。例如,当服务器无法识别请求方法时,服务器可能会返回此代码。
    502(错误网关)           服务器作为网关或代理,从上游服务器收到了无效的响应。
    503(服务不可用)         目前无法使用服务器(由于超载或进行停机维护)。通常,这只是一种暂时的状态。
    504(网关超时)           服务器作为网关或代理,未及时从上游服务器接收请求。
    505(HTTP 版本不受支持)   服务器不支持请求中所使用的 HTTP 协议版本。
    
    Nginx 500错误(Internal Server Error  内部服务器错误):500错误指的是服务器内部错误,也就是服务器遇到意外情况,而无法履行请求。遇到这种nginx出现500错误,大致原因如下:
    
    1)磁盘空间是否不足?
    ----------------------------------------
    使用"df -h" 查看硬盘空间是否满了。清理硬盘空间就可以解决500错误。nginx如果开启了access log,在不需要的情况下,最好关闭access log。access log会占用大量硬盘空间。
    
    2) nginx配置文件错误?
    ----------------------------------------
    这里不是指语法错误,nginx如果配置文件有语法错误,启动的时候就会提示。当配置rewrite的时候,有些规则处理不当会出现500错误,请仔细检查自己的rewrite规则。
    如果配置文件里有些变量设置不当,也会出现500错误,比如引用了一个没有值的变量。
    
    3) 如果上面的问题都不存在,那么可能是模拟的并发数太多了(too many open files)?
    ----------------------------------------
    需要调整一下nginx.conf的并发设置数
    
    打开/etc/security/limits.conf文件,加上两句:
    * soft nofile 65535
    * hard nofile 65535
     
    打开nginx.conf,修改
    worker_rlimit_nofile 65535;
     
    重新启动nginx,重新载入设置
     
    4)索引节点(inode)用满导致?
    ----------------------------------------
    使用"df -i"命令查看系统的inode是否爆满,如果使用达到100%,就释放inode空间。
    
    5)数据库问题导致?
    ----------------------------------------
    如果上面情况都不存在,可以查看是否是因为数据库问题,比如数据库访问不到。
    
    6)如果按上述方法仍然解决不了问题,就可能是配置或是程序有错误了。
    ----------------------------------------
    查看nginx的错误日志,找到可能的原因。
    比如提示某些儿PHP扩展没有安装,则去php.ini中打开对应该的扩展或是安装对应该的扩展,重启nginx和php-fpm,再次刷新页面。
    
    如果数据库连接有问题,也可能会出现500错误,不过日志中一定会体现的
    在日志中提示相应的数据库连接有问题了,就要去查看数据库连接是否正确。根据日志,修改对应该的文件,数据库问题解决后,页面即恢复正常。
  • 相关阅读:
    OpenStack云桌面系列【2】—OpenStack和Spice
    Java中的读写锁 ReentrantReadWriteLock
    Spring Boot Actuator 监控实践
    java子线程中获取父线程的threadLocal中的值
    String源码解析
    Java基础一
    Java 8 Lambda表达式实现原理解析
    Rabbit MQ总结
    AtomicInteger及CAS源码解析
    Queue(队列)接口和其实现类PriorityQueue(优先级队列)源码解析
  • 原文地址:https://www.cnblogs.com/kevingrace/p/5815592.html
Copyright © 2020-2023  润新知