背景: TOMCAT7已加APR或者NIO。已装简单监控JCONSOLE,监控服务器内存，线程等基本情况。
问题1 一个Tomcat他的maxThreads到底配置多少合适?
一个好的maxThreads的配置就是达到资源的合理化应用。
资源池：
在讲其它东西之前，我们先引入一个概念，就是资源池。tomcat7中，他对http请求的处理，也有一个池的概念，配置可以参考这里。每一个请求进来后都是使用线程池中的一个来处理，线程池的大小是由maxThreads来限定的。
异步IO：
当前Tomcat通过使用JAVA NIO或者Apache Portable Runtime这样的异步IO来支持性能的优化。异步IO就是当应用需要进行耗时的IO操作时，向内核发出请求，不用真正等IO操作完成，就去处理其它的请求了，当IO真正完成时会有回调或通知机制通知并完成余下工作。而一般的同步IO是当应用需要IO操作时，向操作系统发出IO Read/Write请求。同时阻塞当前应用，并等待IO返回，返回后才进行后续的操作。从这里可以看出异步IO实际是将请求的处理和IO处理并行了，这样自然能较大的提高系统的吞吐量。
maxThreads的大小:
第一点：从上面的异步IO的机制来看，实际上我们可能可以用一个很小的线程池处理较大的连接数。如当前有100个请求要被处理，处理过程中50个进程都处于IO等待的状态，所以我们实际可能只需要50就能够处理那些不处于IO等待状态的请求就能满足需要了。注意在Tomcat中是使用maxConnection这个配置参数来配置Tomcat的同时处理连接数的。
第二点：盲目的加大线程数会带来一些下面的影响。由于Tomcat处理的线程均会在操作系统中产生对应的实际线程，这就意味着对应的资源消耗（内存，SOCKET等）。另一个影响就是同时处理的请求加大可能导致JAVA内存回收的问题,不同的并发对内存的占用是不同，而实际上90%的内存都是临时变量，可以很快回收。较大的并发同时占用较多的临时变量就会导致容易撑满年青代，从而导致部分内存进入老年代，从而引起更多的Stop The World，甚至OOM，影响JVM性能。其它的影响还包括更高的CPU占用和更多的硬盘读写。这些实际都跟硬件有关。
第三点： 我们可以通过配置一个较合理的资源池，由于资源充裕，单个请求处理迅速，这样能达到最优的系统效率。但是有的时候我们并不总是追求这样的一种情况。比如下载时，单个请求的响应时间将受限于网络，下100M的包可能需要20分钟，我们就不应该通过一个较小的资源池来提升整体的效率，而应该配置一个较大的资源池，让较多用户连接上并进行下载，否则多数的用户都将会因超时被拒绝，从而造成连接上的超快，连不上的就直接被拒绝。
第四点：单个JVM的内存分配较大将导致Full Gc(Stop The World)的中断时间变得更长，影响实时性。高的可达10秒以上的停顿，这段时间所有的东西将被挂起。
配置大小优化思路:
配置时应该根据你应用的实际情况,是最占CPU,内存还是IO，最后达到一个平衡就好，下面来说明思路。
1. 自行保证服务器的资源较够用，如IO、CPU、内存。
2. 在硬件较充裕的情况下尝试以maxThreads配置300、600、1200、1800，分析Tomcat的连接时间，请求耗时，吞吐量等参数。在测试的时候需要密切注意硬盘、带宽、CPU、内存是否处于一个瓶颈情况下。
3. 其实所有的东西最后都有一个极限就是硬件。应用分CPU，IO，内存密集型，这些都会成为你最终的限制性因素。一般应用根据自己的特性划分到不同的机群中，如CPU密集型的会分到一群有更好CPU的集群中。这样可以能充分利用资源。我们以常见的内存为最终限制性因素，并假设CPU足够好，且IO很少来说明思路。通过一些压测工具，我们能容易的找到一个在300~8000的并发数的情况下一个性能的拐点，通过对比不同线程数下请求连接时间、单请求的平均响应时间，总体的吞吐量。这个拐点往往意味着此时的内存回收出现异常，JVM花了更多的时间在回收内存,我们一般可以通过打出gc日志，并使用jmeter等工具来分析得知。此时你可以尝试优化内存结构或加大内存 来解决，若不能解决，可能就意味你前一次的配置就是一个好的选择。当然这些限制因素是可能互相转换的，可能你增加了内存之后内存没有问题了，但是却导致CPU达到100%，从而导致性能下降。此时则要以CPU为最终限制性因素了。
优化测试中陷阱：
以一个下载服务器来例子说明。我们以下载10m的包来做测试，其实你会发现整个服务器的吞吐量很差，响应时间慢。但细心的人会发现此时连接服务器的时间却是很快的，也就是说服务器很快accpet了你的请求，虽然你的吞吐量不大，处理耗时也大。原因是什么呢,其实是你的带宽已经被占满了，你会发现并发下载10个文件就能占满你的所有带宽。所以此时呢你的测试时的对比对象变成了对比连接时间会更加合理。
当然你也可以通过减少包的大小，比如降到 1k，以使带宽不成为瓶颈.这样可能测试出来你的服务器并发极限量，但该并发量可能并不能反应出实际下载的情况，实际的情况就是带宽容易被占满,下载服务器会有一个很大量的连接存在的情况。
问题2. NGINX到底能带来怎么样的性能提升，或者说有什么好处？
1. 测试后发现，NGINX并不能加快响应的速度，为什么呢，因为这是由于NGINX会代理你同后端的请求。也就意味着你原来只需要建立同服务器的一次连接即可完成请求，现在变成了先同NGINX建立连接，NGINX再同后端建立连接。所以引入NGINX后带来了更多的时间消耗，两倍的SOCKET连接消耗。
2. 引入后的好处体现如下。
1) 整体的性能会有提升，通过实测后发现能很大程度上降低最大返回耗时的情况。请求返回更稳定。
2) 降低后端的资源消耗。原来由于客户端网络较慢等因素会让后端在返回数据时处于繁忙的情况，占用资源。通过NGINX向后端代理，同时由于NGINX的缓存机制，后端可以快速返回，并将资源更集中用到处理请求上，这样可以发挥后端的能力。NGINX在保持大量连接这块就得很优秀，内存，CPU都占用很少。
3) 支持非常方便的扩展，高可用性等。
基本的 (优化过的)配置
我们将修改的唯一文件是nginx.conf，其中包含Nginx不同模块的所有设置。你应该能够在服务器的/etc/nginx目录中找到nginx.conf。首先，我们将谈论一些全局设置，然后按文件中的模块挨个来，谈一下哪些设置能够让你在大量客户端访问时拥有良好的xìng能，为什么它们会提高xìng能。本文的结尾有一个完整的配置文件。
nginx要开启的进程数 一般等于cpu的总核数 其实一般情况下开4个或8个就可 我开2个
以了 多了没有太多用
每个nginx进程消耗的内存10兆的模样
worker_cpu_affinity
仅适用于linux，使用该选项可以绑定worker进程和CPU（2.4内核的机器用不
了）
假如是8 cpu 分配如下：
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000
00100000 01000000 10000000
nginx可以使用多个worker进程，原因如下：
to use SMP
to decrease latency when workers blockend on disk I/O
to limit number of connections per process when select()/poll() is
used
The worker_processes and worker_connections from the event sections
allows you to calculate maxclients value: k
max_clients = worker_processes * worker_connections
worker_rlimit_nofile 102400;
每个nginx进程打开文件描述符最大数目 配置要和系统的单进程打开文件数一
致,linux 2.6内核下开启文件打开数为65535，worker_rlimit_nofile就相应
应该填写65535
nginx调度时分配请求到进程并不是那么的均衡，假如超过会返回502错误。我
这里写的大一点
use epoll
Nginx使用了最新的epoll（Linux 2.6内核）和kqueue（freebsd）网络I/O模
型，而Apache则使用的是传统的select模型。
处理大量的连接的读写，Apache所采用的select网络I/O模型非常低效。
在高并发服务器中，轮询I/O是最耗时间的操作 目前Linux下能够承受高并发
访问的Squid、Memcached都采用的是epoll网络I/O模型。
worker_connections 65535;
每个工作进程允许最大的同时连接数 （Maxclient = work_processes * worker_connections）
keepalive_timeout 75
keepalive超时时间
这里需要注意官方的一句话：
The parameters can differ from each other. Line Keep-Alive:
timeout=time understands Mozilla and Konqueror. MSIE itself shuts
keep-alive connection approximately after 60 seconds.
client_header_buffer_size 16k
large_client_header_buffers 4 32k
客户请求头缓冲大小
nginx默认会用client_header_buffer_size这个buffer来读取header值，如果
header过大，它会使用large_client_header_buffers来读取
如果设置过小HTTP头/Cookie过大 会报400 错误 nginx 400 bad request
求行如果超过buffer，就会报HTTP 414错误(URI Too Long)
nginx接受最长的HTTP头部大小必须比其中一个buffer大，否则就会报400的
HTTP错误(Bad Request)。
open_file_cache max 102400
使用字段:http, server, location 这个指令指定缓存是否启用,如果启用,将记录文件以下信息: ·打开的文件描述符,大小信息和修改时间. ·存在的目录信息. ·在搜索文件过程中的错误信息 -- 没有这个文件,无法正确读取,参考open_file_cache_errors 指令选项:
·max - 指定缓存的最大数目,如果缓存溢出,最长使用过的文件(LRU)将被移除
例: open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;
open_file_cache_errors
语法:open_file_cache_errors on | off 默认值:open_file_cache_errors off 使用字段:http, server, location 这个指令指定是否在搜索一个文件是记录cache错误.
open_file_cache_min_uses
语法:open_file_cache_min_uses number 默认值:open_file_cache_min_uses 1 使用字段:http, server, location 这个指令指定了在open_file_cache指令无效的参数中一定的时间范围内可以使用的最小文件数,如 果使用更大的值,文件描述符在cache中总是打开状态.
open_file_cache_valid
语法:open_file_cache_valid time 默认值:open_file_cache_valid 60 使用字段:http, server, location 这个指令指定了何时需要检查open_file_cache中缓存项目的有效信息.
开启gzip
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css
application/xml;
gzip_vary on;
缓存静态文件：
location ~* ^.+\.(swf|gif|png|jpg|js|css)$ {
root /usr/local/ku6/ktv/show.ku6.com/;
expires 1m;
}
优化Linux内核参数
vi /etc/sysctl.conf
# Add
net.ipv4.tcp_max_syn_backlog = 65536
net.core.netdev_max_backlog = 32768
net.core.somaxconn = 32768
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_tw_recycle = 1
#net.ipv4.tcp_tw_len = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_max_orphans = 3276800
#net.ipv4.tcp_fin_timeout = 30
#net.ipv4.tcp_keepalive_time = 120
net.ipv4.ip_local_port_range = 1024 65535
附录：一些错误排查
php-cgi进程数不够用、php执行时间长（mysql慢）、或者是php-cgi进程死掉
，都会出现502错误
一般来说Nginx 502 Bad Gateway和php-fpm.conf的设置有关，而Nginx 504 Gateway Time-out则是与nginx.conf的设置有关
1、查看当前的PHP FastCGI进程数是否够用：
netstat -anpo | grep "php-cgi" | wc -l
如果实际使用的“FastCGI进程数”接近预设的“FastCGI进程数”，那么
，说明“FastCGI进程数”不够用，需要增大。
2、部分PHP程序的执行时间超过了Nginx的等待时间，可以适当增加
nginx.conf配置文件中FastCGI的timeout时间，例如：
http
{
......
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......
}
413 Request Entity Too Large
增大client_max_body_size
client_max_body_size:指令指定允许客户端连接的最大请求实体大小,它出现在请求头部的Content-Length字段. 如果请求大于指定的值,客户端将收到一个"Request Entity Too Large" (413)错误. 记住,浏览器并不知道怎样显示这个错误.
php.ini中增大
post_max_size 和upload_max_filesize
高层的配置
nginx.conf文件中，Nginx中有shao数的几个高级配置在模块部分之上。
user www-data;
pid /var/run/nginx.pid;
worker_processes auto;
worker_rlimit_nofile 100000;
user和pid应该按默认设置 - 我们不会更改这些内容，因为更改与否没有什么不同。
worker_processes 定义了nginx对外提供web服务时的worker进程数。最优值取决于许多因素，包括（但不限于）CPU核的数量、存储数据的硬盘数量及负载模式。不能确定的时候，将其设置为可用的CPU内核数将是一个好的开始（设置为“auto”将尝试自动检测它）。
worker_rlimit_nofile 更改worker进程的最大打开文件数限制。如果没设置的话，这个值为操作系统的限制。设置后你的操作系统和Nginx可以chǔ理比“ulimit -a”更多的文件，所以把这个值设高，这样nginx就不会有“too many open files”问题了。
Events模块
events模块中包含nginx中所有chǔ理连接的设置。
events {
worker_connections 2048;
multi_accept on;
use epoll;
}
worker_connections 设置可由一个worker进程同时打开的最大连接数。如果设置了上面提到的worker_rlimit_nofile，我们可以将这个值设得很高。
记住，最大客户数也由系统的可用socket连接数限制（~ 64K），所以设置不切实际的高没什么好chǔ。
multi_accept 告诉nginx收到一个新连接通知后接受尽可能多的连接。
use 设置用于复用客户端线程的轮询方法。如果你使用Linux 2.6+，你应该使用epoll。如果你使用*BSD，你应该使用kqueue。
（值得注意的是如果你不知道Nginx该使用哪种轮询方法的话，它会选择一个最适合你操作系统的）
HTTP 模块
HTTP模块控制着nginx httpchǔ理的所有核心特xìng。因为这里只有很shao的配置，所以我们只节选配置的一小部分。所有这些设置都应该在http模块中，甚至你不会特别的注意到这段设置。
http {
server_tokens off;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
...
}
server_tokens 并不会让nginx执行的速度更快，但它可以关闭在错误页面中的nginx版本数字，这样对于安全xìng是有好chǔ的。
sendfile 可以让sendfile()发挥作用。sendfile()可以在磁盘和TCP socket之间互相拷贝数据(或任意两个文件描述符)。Pre-sendfile是传送数据之前在用户空间申请数据缓冲区。之后用read()将数据从文件拷贝到这个缓冲区，write()将缓冲区数据写入网络。sendfile()是立即将数据从磁盘读到OS缓存。因为这种拷贝是在内核完成的，sendfile()要比组合read()和write()以及打开关闭丢弃缓冲更加有效(更多有关于sendfile)。
tcp_nopush 告诉nginx在一个数据包里发送所有头文件，而不一个接一个的发送。
tcp_nodelay 告诉nginx不要缓存数据，而是一段一段的发送--当需要及时发送数据时，就应该给应用设置这个属xìng，这样发送一小块数据信息时就不能立即得到返回值。
access_log off;
error_log /var/log/nginx/error.log crit;
access_log 设置nginx是否将存储访问日志。关闭这个选项可以让读取磁盘IO操作更快(aka,YOLO)
error_log 告诉nginx只能记录严重的错误：
keepalive_timeout 10;
client_header_timeout 10;
client_body_timeout 10;
reset_timedout_connection on;
send_timeout 10;
keepalive_timeout 给客户端分配keep-alive链接超时时间。服务器将在这个超时时间过后关闭链接。我们将它设置低些可以让ngnix持续工作的时间更长。
client_header_timeout 和client_body_timeout 设置请求头和请求体(各自)的超时时间。我们也可以把这个设置低些。
reset_timeout_connection 告诉nginx关闭不响应的客户端连接。这将会释放那个客户端所占有的内存空间。
send_timeout 指定客户端的响应超时时间。这个设置不会用于整个转发器，而是在两次客户端读取操作之间。如果在这段时间内，客户端没有读取任何数据，nginx就会关闭连接。
limit_conn_zone $binary_remote_addr zone=addr:5m;
limit_conn addr 100;
limit_conn_zone 设置用于保存各种key（比如当前连接数）的共享内存的参数。5m就是5兆字节，这个值应该被设置的足够大以存储（32K*5）32byte状态或者（16K*5）64byte状态。
limit_conn 为给定的key设置最大连接数。这里key是addr，我们设置的值是100，也就是说我们允许每一个IP地址最多同时打开有100个连接。
include /etc/nginx/mime.types;
default_type text/html;
charset UTF-8;
include 只是一个在当前文件中包含另一个文件内容的指令。这里我们使用它来加载稍后会用到的一系列的MIME类型。
default_type 设置文件使用的默认的MIME-type。
charset 设置我们的头文件中的默认的字符集
gzip on;
gzip_disable "msie6";
# gzip_static on;
gzip_proxied any;
gzip_min_length 1000;
gzip_comp_level 4;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
gzip 是告诉nginx采用gzip压缩的形式发送数据。这将会减shao我们发送的数据量。
gzip_disable 为指定的客户端禁用gzip功能。我们设置成IE6或者更低版本以使我们的方案能够广泛兼容。
gzip_static 告诉nginx在压缩资源之前，先查找是否有预先gzipchǔ理过的资源。这要求你预先压缩你的文件（在这个例子中被注释掉了），从而允许你使用最高压缩比，这样nginx就不用再压缩这些文件了（想要更详尽的gzip_static的信息，请点击这里）。
gzip_proxied 允许或者禁止压缩基于请求和响应的响应流。我们设置为any，意味着将会压缩所有的请求。
gzip_min_length 设置对数据启用压缩的最shao字节数。如果一个请求小于1000字节，我们最好不要压缩它，因为压缩这些小的数据会降低chǔ理此请求的所有进程的速度。
gzip_comp_level 设置数据的压缩等级。这个等级可以是1-9之间的任意数值，9是最慢但是压缩比最大的。我们设置为4，这是一个比较折中的设置。
gzip_type 设置需要压缩的数据格式。上面例子中已经有一些了，你也可以再添加更多的格式。
# cache informations about file descriptors, frequently accessed files
# can boost performance, but you need to test those values
open_file_cache max=100000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
##
# Virtual Host Configs
# aka our settings for specific servers
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
open_file_cache 打开缓存的同时也指定了缓存最大数目，以及缓存的时间。我们可以设置一个相对高的最大时间，这样我们可以在它们不活动超过20秒后清除掉。
open_file_cache_valid 在open_file_cache中指定检测正确信息的间隔时间。
open_file_cache_min_uses 定义了open_file_cache中指令参数不活动时间期间里最小的文件数。
open_file_cache_errors 指定了当搜索一个文件时是否缓存错误信息，也包括再次给配置中添加文件。我们也包括了服务器模块，这些是在不同文件中定义的。如果你的服务器模块不在这些位置，你就得修改这一行来指定正确的位置。
一个完整的配置
user www-data;
pid /var/run/nginx.pid;
worker_processes auto;
worker_rlimit_nofile 100000;
events {
worker_connections 2048;
multi_accept on;
use epoll;
}
http {
server_tokens off;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
access_log off;
error_log /var/log/nginx/error.log crit;
keepalive_timeout 10;
client_header_timeout 10;
client_body_timeout 10;
reset_timedout_connection on;
send_timeout 10;
limit_conn_zone $binary_remote_addr zone=addr:5m;
limit_conn addr 100;
include /etc/nginx/mime.types;
default_type text/html;
charset UTF-8;
gzip on;
gzip_disable "msie6";
gzip_proxied any;
gzip_min_length 1000;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
open_file_cache max=100000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
编辑完配置后，确认重启nginx使设置生效。
sudo service nginx restart
扫一扫
385
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
