优化 Nginx worker 进程最大打开文件数

[[email protected] ~]# cat /usr/local/nginx/conf/nginx.conf
worker_processes  2;
worker_cpu_affinity 01 10;worker_rlimit_nofile 65535;    # worker 进程最大打开文件数,可设置为优化后的 ulimit -HSn 的结果
user nginx nginx;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server_tokens   off;
    server {
        listen       80;
        server_name  www.abc.com;
        location / {
            root   html/www;
            index  index.html index.htm;
        }
    }
}
时间: 2024-10-07 17:12:32

优化 Nginx worker 进程最大打开文件数的相关文章

修改用户进程可打开文件数限制(转)

1.修改用户进程可打开文件数限制 在Linux平台上,无论编写客户端程序还是服务端程序,在进行高并发TCP连接处理时,最高的并发数量都要受到系统对用户单一进程同时可打开文件数量 的限制(这是因为系统为每个TCP连接都要创建一个socket句柄,每个socket句柄同时也是一个文件句柄).可使用ulimit命令查看系统允许 当前用户进程打开的文件数限制: [[email protected] ~]$ ulimit -n 1024 这表示当前用户的每个进程最多允许同时打开1024个文件,这1024个

优化 Nginx 单个进程允许的最大连接数

(1) 控制 Nginx 单个进程允许的最大连接数的参数为 worker_connections ,这个参数要根据服务器性能和内存使用量来调整 (2) 进程的最大连接数受 Linux 系统进程的最大打开文件数限制,只有执行了 "ulimit -HSn 65535" 之后,worker_connections 才能生效 (3) 连接数包括代理服务器的连接.客户端的连接等,Nginx 总并发连接数 = worker 数量 * worker_connections [[email prote

centos7,进程最大打开文件数 too many open files错误

遇到一问题,tomcat最近发生几次异常,查看日志,发现一直报 too many open files,熟悉的同学都知道这是用户打开文件数过多导致的, 再用命令ls /proc/20861/fd/ | wc -l 查看当前tomcat进程打开文件数,果然已经4095个,这种问题解决办法就是增大文件打开数即可,简单的很. 但如果能这么容易的解决了,我也就不用再写这篇博客了.因为我查了下当前用户所能打开的文件数发现最大能打开的文件数是65535,远远大于4096. 而/etc/security/li

nginx worker进程循环

worker进程启动后,其首先会初始化自身运行所需要的环境,然后会进入一个循环,在该循环中不断检查是否有需要执行的事件,然后处理事件.在这个过程中,worker进程也是需要与master进程交互的,更有甚者,worker进程作为一个子进程,也是可以接收命令行指令(比如kill等)以进行相应逻辑的处理的.那么worker进程是如何与master或者命令行指令进行交互的呢?本文首先会对worker进程与master进程交互方式,以及worker进程如何处理命令行指令的流程进行讲解,然后会从源码上对w

配置nginx worker 进程数

一般修改为cpu的核数的个数那么多 cd /application/nginx/conf grep worker_processes nginx.conf sed -i 's/worker_processes  1/worker_processes  10/g' nginx.conf grep worker_processes nginx.conf /application/nginx/sbin/nginx -s reload ps -ef |grep nginx ###############

Nginx工作进程模型

前面提到过,Nginx不为每个连接派生进程或线程,而是由worker进程通过监听共享套接字接受新请求,并且使用高效的循环来处理数千个连接.Nginx不使用仲裁器或分发器来分发连接,这个工作由操作系统内核机制完成.监听套接字在启动时就完成初始化,worker进程通过这些套接字接受.读取请求和输出响应. 事件处理循环是Nginx worker代码中最复杂的部分,它包含复杂的内部调用,并且严重依赖异步任务处理的思想.异步操作通过模块化.事件通知.大量回调函数以及微调定时器等实现.总的来说,基本原则就是

nginx之旅(第六篇):nginx优化--nginx优化目的、工作进程优化、长连接设置、数据压缩、客户端缓存

一.Nginx优化目的 标准情况下,软件默认的参数都是对安装软件的硬件标准来设置的,目前我们服务?的硬件资源远远大于要求的标准,所以为了让服务?性能更加出众,充分利用服务?的硬件资源,我们一般需要优化APP的并发数来提升服务器?的性能. 二.工作进程优化 1) worker_processes worker_processes指Nginx的工作进程,这个值是直接受到服务器CPU核数量影响的(当然也有其他影响),Nginx默认配置为auto,意思是会自动检测CPU核做修改,建议worker_pro

nginx源码分析--master和worker进程模型

一.Nginx整体架构 正常执行中的nginx会有多个进程,最基本的有master process(监控进程,也叫做主进程)和woker process(工作进程),还可能有cache相关进程. 一个较为完整的整体框架结构如图所示: 二.核心进程模型 启动nginx的主进程将充当监控进程,而由主进程fork()出来的子进程则充当工作进程. nginx也可以单进程模型执行,在这种进程模型下,主进程就是工作进程,没有监控进程. Nginx的核心进程模型框图如下: master进程 监控进程充当整个进

关于nginx的master进程可worker进程的概念

nginx的master和worker进程之间的关系,就像是坐台的"***"与"老鸨"之间的关系. 假如说一个妓院有多名***,而管理每个***的老鸨只有一个,其中老鸨负责对外招揽业务,而***负责干活(处理业务),如果一个***接待不完这些客人,老鸨会把随后的客人交给其他的***去接待. 在这里,老鸨就属于master进程,客户端所有的请求都是由master来接收,***呢,就相当于woker进程,(真正处理客户端请求的是下面这些woker进程).