这种结构对比互联网公司而言, 请求需要经过路由器防火墙 IDS/IPS 等好几层的设备最终才能由业务服务器来响应请求, 这期间请求没经过一层都需要消耗一定的时间, 通过累计这个时间就会被放大, 而且防火墙的性能直接决定了 Nginx 可以承载的请求数所以迫不得已要用防火墙的话, 请使用 30 万

Size: px

Start display at page:

Download "这种结构对比互联网公司而言, 请求需要经过路由器防火墙 IDS/IPS 等好几层的设备最终才能由业务服务器来响应请求, 这期间请求没经过一层都需要消耗一定的时间, 通过累计这个时间就会被放大, 而且防火墙的性能直接决定了 Nginx 可以承载的请求数所以迫不得已要用防火墙的话, 请使用 30 万"

冷韵廉
5 years ago
Views:

1 主题简介 : 1. 基础架构网络对 Nignx 性能的影响 2. Nignx 安装优化 3. Nignx 配置文件优化 4. Nignx 与 HAProxy Tomcat PHP FOM 搭配使用时的注意事项 5. TCP/IP 协议栈优化对 Nignx 的影响影响 Nginx 性能的因素 Nginx 的优化不能单纯看 Nginx 本身, 其实有很多方面会影响到 Nginx 的整体性能 1 网络层面带宽带宽对 Nginx 性能的影响是最为直接的, 就算如何独享 10M 的带宽也肯定不如 100M 带宽下 Nginx 的性能另外, 现在大部分公司的网站都拥有多个二级域名在提供服务, 而这多个二级域名通常是共享一个出口带宽的, 这样就造成 Nginx 来提供服务时, 资源会受干扰网络质量在中国的互联网中, 网络质量跟国外是没法比的, 经常出现的情况是客户端到 Nginx 服务端总是会经过好几个路由, 但凡其中任何一个路由节点出现问题, 会影响最终 Nginx 服务端的各种性能问题, 例如数据重传数据超时等 Nginx 直连交换机收敛比交换机收敛比通常指交换机接服务器的下行流量跟交换机上行链路的比例, 一般中型及中小型公司对 IDC 业务网络没有过多的规划, 导致交换机收敛比通常是大于 1 的, 也就意味着数据在交换机中是阻塞型转发, 会影响 Nginx 的数据转发, 尤其是作为反向代理时的影响更大 Nginx 架构中网络部署方式大部分互联网公司通常会采用如下结构的网络 :

这种结构对比互联网公司而言, 请求需要经过路由器防火墙 IDS/IPS 等好几层的设备最终才能由业务服务器来响应请求, 这期间请求没经过一层都需要消耗一定的时间, 通过累计这个时间就会被放大, 而且防火墙的性能直接决定了 Nginx 可以承载的请求数所以迫不得已要用防火墙的话, 请使用 30 万以上的防火墙来做, 几万的防火墙性能其实达不到业务需求的 2 服务器硬件层面 CPU Nginx

2 这种结构对比互联网公司而言, 请求需要经过路由器防火墙 IDS/IPS 等好几层的设备最终才能由业务服务器来响应请求, 这期间请求没经过一层都需要消耗一定的时间, 通过累计这个时间就会被放大, 而且防火墙的性能直接决定了 Nginx 可以承载的请求数所以迫不得已要用防火墙的话, 请使用 30 万以上的防火墙来做, 几万的防火墙性能其实达不到业务需求的 2 服务器硬件层面 CPU Nginx 的工作模型是 master worker 方式, 简单来说, 越多的 worker 也就意味着越多的承载力,CPU 的核心数从某种程度来说决定了 Nginx 最佳的 worker 工作数量内存内存的容量直接决定了 Nginx 可承载的最大连接数硬盘 Nginx 的使用过程中, 容易产生 IO 的地方还是挺多的, 比如各种临时文件错误日志访问日志缓存等而硬盘的传输速度可以影响到这些产生的 IO, 比如硬盘的转速硬盘的容量硬盘的输出带宽等网卡

3 这里以戴尔服务器举例, 戴尔服务器默认配置的网卡为 Broadcom 的, 这种网卡一般使用没问题, 但遇上 Nginx 在处理大量小包的情况下, 默认配置的网卡就会发生严重丢包的事情, 内核层面的丢包会造成大量的数据重传从而影响整个 Nginx 服务器的性能所以对于 Nginx 而言需要选择合适的网卡 3 操作系统层面 /etc/sysctl.conf 的配置很多时候大部分的运维都是从网上复制粘贴 sysctl.conf 的配置, 对于其中一些 value 的配置都是没有任何依据, 所以容易被出现的各种 TCP 状态而担心而这些抄来的配置也从根本上影响着 Nginx 的运行系统资源限制这里的资源限制主要指文件句柄数的限制, 文件句柄数的多少限制了 Nginx 可以支持的最大连接数, 不合理的配置会造成 Nginx 出现大量的错误 IRQ Balanc 关于 IRQ Balance 服务, 初衷是为了更好地利用 CPU 的资源来处理事务, 但很多场景下, 包括 Nginx 的应用, 这个服务并不能起到利好的作用, 反而会引起中断的不平衡造成 Nginx 性能下降系统开放多余的端口严格来说, 这种情况发生的几率还是比较低的一般没有做运维标准化的公司, 在服务器安装系统时, 默认就会开启很多的服务, 比如 sendmail postfix ntpd bind 等等, 这些服务一般监听在所有的 IP 上, 也就意味着 Nginx 部署在这种环境下, 一旦有恶意攻击者攻击非 Nginx 的端口, 就会造成整个服务器资源被耗尽 (DDoS 的典型症状 ), 从而让 Nginx 失去服务能力 4 Nginx 层面编译进业务不需要的模块有很多运维对于 Nginx 的安装大部分都是用 yum 或者 apt get 进行安装, 这种安装基本上都会把一些不需要的模块编译进去, 在 Nginx 提供高并发时多少还是要消耗一定的内存资源, 前面我们说了内存直接决定了 Nginx 能够承载多少连接的能力糟糕的配置很多人发挥不了 Nginx 的性能, 主要原因就是对 Nginx 的配置不熟悉, 对于 Nginx 的参数指令不了解, 所以各种各样的配置五花八门, 这里实在没法一一列举, 详情可以参看度娘, 一搜一大片缓存使用不合理

4 Nginx 的缓存, 本意是为了提升 Nginx 的处理能力, 降低上游服务器的压力, 而大部分运维也是从网上抄, 于是带来的结果就是缓存的不合理配置造成响应延时过高缓存清理麻烦等问题 5 上游服务器层面 Nginx 在大部分的应用场景要么是通过 http 协议来反向代理上游服务器, 要么是通过 fastcgi 协议来代理 php 应用, 这两类应用也是会对 Nginx 自身的性能带来影响的 PHP 应用当前一般都是使用 PHP FPM 来提供 fastcgi 协议的接入,PHP 的版本以及 PHP FPM 的配置都会造成 N ginx 反代 php fpm 时, 容易发生的错误 Java 应用一般用于 Java 应用都逃不过 Tomcat jetty resin, 如果出现容器本身配置不合理 JVM 不优化 Jav a 容器选择不合理, 将直接影响 Nginx 做反代时的并发能力 Nginx 优化项目 Nginx 的优化根据上述的性能影响因素来一一说明 1 网络层面在满足业务以及性价比的前提下, 越高的带宽意味着 Nginx 可以承载更多的连接和并发 ; 在条件允许的情况下使用多个 ISP 运营商线路来提供服务, 并使用策略路由解决多线路之间的请求响应 ; 在网络的部署架构中, 尽量避免防火墙作为 HTTP 请求第一个经过的设备, 建议由 Nginx 或者第一级的 4 层负载均衡来转发请求 ; 对于整个网站而言, 有条件要设计大二层的网络 ( 胖树结构 ), 这样有利于服务器的水平扩展 ; 对于使用 IDC 的用户, 建议选机房时使用 mtr 工具对目标机房进行 72 小的测试, 来检验机房的网络质量, 这里主要包括请求到达机房时有没有出现某一跳出现多个路由的情况某一跳是否延迟超级不稳定 (mtr 工具中最后一列表示标准方差, 简单认为就是这个值越大这个节点越不稳定 ), 通过这样选出网络质量相对较好的机房 ; 在设计网络时, 要考虑到交换机的收敛比, 尽可能做到 <=1, 才能做到数据的线速转发 2 服务器硬件层面 CPU

5 不管使用云主机还是物理机, 将 Nginx 独立并且把 Nginx 作为负载均衡服务器时, 越多的 CPU 也就意味着 Nginx 可以启用更多的 worker 来处理请求, 这里特别要说明下,CPU 的主频不需要作为参考指标, 主要是物理 CPU 的核心数以及是否支持 HT 技术内存越大的内存也就意味着 Nginx 理论上拥有的最大连接承载能力, 而且 Nginx 使用到缓存时, 还可以将通过 tmpfs 将缓存内容直接放在内存中, 从而提高 Nginx 的处理性能 ; 也可以使用 tmpfs 作为 Nginx 各种临时文件的存放地, 降低磁盘的 IO 硬盘用 SSD PCIe SSD 来替换 SAS 机械硬盘, 在 Nginx 并发较高的服务器上, 可以将访问日志及错误日志放在拥有更高 IOPS 的磁盘上, 从而保证 Nginx 的性能, 实际上, 我们大部分时候测试 Nginx 时, 是在测试 Nginx 服务器上磁盘的性能 ( 大家好好回味下 why) 网卡上面网络层说要更高的带宽, 这个带宽指运营商提供的服务带宽, 光有服务带宽还不够, 还需要服务器有对应的网卡来支持, 比如用到了 5G 的带宽, 那服务器网卡最少需要万兆的, 当然网卡的品牌也很重要对于千兆的环境, 建议使用英特尔 i350 的网卡, 对于需要使用万兆网卡的环境, 建议优先选择 Mellanox 的万兆网卡 ( 最便宜也要 6000 块钱一块, 土豪用 ), 资金有压力的公司可以选择英特尔 x 520 的网卡, 因为这些网卡除了小包的转发性能强劲外, 还有需要 offload 特性可以降低系统 kernel 的消耗, 提升 Nginx 的承载能力只不过在用这些好的网卡时, 一定要做中断绑定 ( 减少 CPU0 的中断请求, 让充分发挥网络多队列的优势 ) 3 操作系统层面 /etc/sysctl.conf net.ipv4.tcp_max_tw_buckets = 1000 net.ipv4.tcp_sack = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_rmem = net.ipv4.tcp_wmem = net.core.wmem_default = net.core.rmem_default =

6 net.core.rmem_max = net.core.wmem_max = net.ipv4.tcp_orphan_retries = 1 (TCP_FIN_WAIT1 TCP_FIN_WAIT2 TCP_LAST_ACK TCP_CLOSING) net.core.somaxconn = net.ipv4.tcp_max_orphans = net.ipv4.tcp_max_syn_backlog = net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_synack_retries = 1 net.ipv4.tcp_syn_retries = 1 net.ipv4.tcp_retries2 = 5 net.ipv4.tcp_tw_recycle = 0 net.ipv4.tcp_tw_reuse = 0 net.ipv4.ip_local_port_range = net.ipv4.tcp_slow_start_after_idle = 0 其中 net.core.somaxconn 这个配置在 CentOS 6 系列中, 这个参数的值可以大于 65535, 在 CentOS 7 中, 这个参数的最大值为 net.ipv4.tcp_timestamps net.ipv4.tcp_tw_recycle net.ipv4.tcp_tw_reuse 这三个参数一般建议都配置为 0, 高并发时 tw 连接想快速回收及复用还是呵呵吧 net.ipv4.tcp_slow_start_after_idle 这个参数是禁用 TCP 慢启动的, 当然如果使用 CentOS 6 的用户建议将版本升级到 6.5 以及 6.5 以后的版本, 这个参数配置才有意义, 低于 6.5 的版本, 需要做些特殊配置才可以其它注意事项

7 1 net.ipv4.tcp_mem 没事别瞎改, 系统自动计算, 别吃饱撑着! 2 fs.file max 没事别瞎改, 内核根据内存大小自动计算, 表示 kernel 可分配的最大文件句柄数, 这个参数的大小简单的来说约等于 cat /proc/meminfo grep MemTotal 的大小乘以 10%, 精确的计算可以在我博客查看 3 fs.nr_open 可以修改, 此为单个进程可分配的最大文件句柄数, 默认是为 1024* 以下三个参数在 Nginx 没有启用 SO_TCPKEEPALIVE 特性时, 根本不会生效, 且启用 SO_TCPKE EPALIVE 特性的参数, 不是 keepalive_timeout! net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_probes net.ipv4.tcp_keepalive_intvl HTTP Keep Alive 与 TCP Keepalive 是两个不同的概念, 简单说前者是复用一个 TCP 连接, 后者用于 TCP 连接的链路探活关于 HTTP Keep Alive 与 TCP Keepalive 我博客近期会发布一片文章, 通过 wireshark 抓包来详解 5 net.ipv4.tcp_max_orphans 不要设置过大, 一个孤儿连接要占用 64K 的不可交换内存, 网上动辄这个值配置个几百万, 吼吼, 为内存感到担忧 6 net.ipv4.tcp_max_tw_buckets 没事别设置几万几十万的, 这个参数是 TW 的连接超过这个设置时在 /var/log/messages 中打印警告信息, 同时释放 TW 连接, 可以设置小一点, 当系统中 TW 太多时,n et.ipv4.tcp_tw_recycle 和 net.ipv4.tcp_tw_reuse 两个参数并没有卵用, 所以 TW 连接过大的可以直接暴力的将 net.ipv4.tcp_max_tw_buckets 设置为 0, 并没有什么问题, 当然最终解决还是要依赖程序和对 Nginx 的配置以及重新编译内核, 减少 TW 连接的产生 7 rmem 和 wmem 可根据 netstat s grep socket 的结果来判断是否足够, 出现类似以下信息时就要考虑增加对应的大小了 packets pruned from receive queue because of socket buffer overrun packets collapsed in receive queue due to low socket buffer Nginx 层面 1 安装优化安装优化主要针对 Nginx 的编译安装, 这里包含两个部分, 一是针对编译器的编译参数优化, 二是通过 Nginx 的应用场景来定制化 Nginx 的编译选项以下通过 Nginx 最为静态资源服务器的案例来抛砖引

8 玉地说下 Nginx 安装的优化 : 首先要确定 Nginx 是针对哪类静态资源做服务, 例如提供 js css 以及 jpg png 等资源的访问, 还是针对 MP3 MP4 RMVB zip rar 等大文件的资源访问这两种静态资源的场景使用对 Nginx 的编译参数还是有很大影响的 js\css\jpg 等这类静态资源一般文件都是比较小的, 作为互联网公司一般文件的平均大小不会超过 4M, 所以一般编译时是不需要将 with threads 编译进去, 而后者这种文件动辄都会超过 10M 的静态资源, 一般就需要将 with threads 开启了, 以便使用 Nginx 的线程池来提升文件传输的性能其次, 作为静态资源服务器, 大部分的模块是使用不到的, 能使用到的模块有 ssl 模块 http v2 模块, 所以编译 Nginx 的参数就变成下面这样了 :./configure prefix=/opt/websuite/nginx \ conf path=/opt/config/nginx/nginx.conf \ modules path=/opt/websuite/nginx/modules \ error log path=/opt/logs/nginx/error.log \ http log path=/opt/logs/nginx/access.log \ pid path=/opt/run/nginx user=websuite \ group=websuite \ with file aio \ with http_ssl_module \ with http_v2_module \ with http_stub_status_module \ without http_ssi_module \ without http_charset_module \ without http_access_module \ without http_auth_basic_module \ without http_autoindex_module \ without http_geo_module \ without http_split_clients_module \

9 without http_proxy_module \ without http_fastcgi_module \ without http_uwsgi_module \ without http_scgi_module \ without http_memcached_module \ without http_empty_gif_module \ without http_browser_module \ without http_upstream_hash_module \ without http_upstream_ip_hash_module \ without http_upstream_least_conn_module \ without http_upstream_keepalive_module \ without http_upstream_zone_module \ http client body temp path=/opt/websuite/nginx/temp/client \ without mail_pop3_module \ without mail_imap_module \ without mail_smtp_module \ with google_perftools_module \ with pcre=/tmp/nginx/pcre 8.41 \ with pcre jit \ with openssl=/tmp/nginx/openssl 1.0.2j \ with openssl opt= threads shared no zlib no comp no ssl2 no ssl3 no ssl3 method 通过以上的编译参数编译生成的 Nginx 可执行文件是很小的, 启动时载入的动态链接库也最少, 在并发较高时, 单个 worker 占用的内存资源是很小的 2 Nginx 访问日志优化访问日志的优化主要是 3 个方面 :

10 增加 buffer 使用 map 过滤不必要的日志制定合适的 log_format 例如 : map $uri $expanded_name { ~^(.*\.(gif jpg jpeg png bmp swf js css)$) 0; default 1; } access_log /opt/logs/openresty/access. proxy buffer=1m if=$expanded_name 表示使用 proxy 作为的日志记录格式, 并且设置 buffer 为 1m, 当 buffer 中的日志超过 1m 时再写入日志文件, 同时请求中包含 map 中指定的文件将不记录到访问日志里 Proxy 相关参数优化 proxy_connect_timeout 30; proxy_send_timeout 30; proxy_read_timeout 60; proxy_buffer_size 64k; proxy_buffers 4 64k; proxy_busy_buffers_size 128k; proxy_next_upstream invalid_header http_500 http_503 http_403 http_502 http_504; proxy_next_upstream_timeout 1s; proxy_next_upstream_tries 1; 其中 proxy_buffer_size 的值可通过统计一天 accesslog 中的 $bytes_sent,$bytes_sent 的平均值即为 pr oxy_buffer_size 的值,$bytes_sent 的最大值则为 proxy_buffers 的大小例如, 平均值为 50K, 最大值为 230k, 则 proxy_buffer_size 就为 64k,proxy_buffers 就设置 4 64k 对于 next_upstream 的用法可参考

11 fastcgi 模块的优化与 proxy 模块的优化方法类似 3 合理利用 tmpfs 通过使用 tmpfs, 可将 Nginx 的临时目录及缓存目录放到内存中, 降低对磁盘 IO 的消耗 4 Nginx 主配置优化 worker_processes auto; worker_cpu_affinity auto; worker_rlimit_nofile ; pcre_jit on; events{ use epoll; worker_connections 8192; accept_mutex off; } 一般 worker_connections* worker_processes < worker_rlimit_nofile, 其中 worker_rlimit_nofile 不受 uli mit n 的限制, 如果没有配置此参数, 则以 ulimit n 的值为主 accept_mutex 网站流量小设置为 on 也没问题, 大流量的情况下要设置为 off, 在 nginx 版本中默认就关闭了 5 Nginx 默认服务器建议配置一个 default server, 例如 :

当你的 Nginx 要提供的服务很多时, 增加 default server 中的 backlog 加入 reuseport 可以让所有的 wor ker 都监听在 80 端口, 提高 Nginx 的并发性能,reuseport 与 accept_mutex 是互斥的另外如果要启用 SO_TCPKEEPALIVE 机制, 需要在 listen 指令中配置 so_keepalive=on 6

12 当你的 Nginx 要提供的服务很多时, 增加 default server 中的 backlog 加入 reuseport 可以让所有的 wor ker 都监听在 80 端口, 提高 Nginx 的并发性能,reuseport 与 accept_mutex 是互斥的另外如果要启用 SO_TCPKEEPALIVE 机制, 需要在 listen 指令中配置 so_keepalive=on 6 Nginx 负载均衡 Nginx 负载均衡环境中, 在 upstream 启用 keepalive 指令, 可用在 proxy 和 fastcgi 的场景里例如 : upstream netemu { server unix:/opt/run/php/pool1.sock; server unix:/opt/run/php/pool4.sock; keepalive 4; } 对于 proxy 模块需要增加指令 proxy_http_version 1.1; proxy_set_header Connection ; 另外上游服务器必须配置 keepalive timetout 的相关配置, 并且将这个超时时间可以设置长一点, 比如 10 分钟半小时都可以, 如果上游服务器关闭了 keepalive, 那么 Nginx 的配置指令里配置了 keepal ive NUM, 是没什么效果的对于 fastcgi 模块需要增加指令 fastcgi_keep_conn on; 当在 upstream 中使用负载均衡算法时, 算法指令要放在 keepalive 指令前 ;

13 通过这种方式, 可以显著降低 Nginx 与 upstream 中 server 的 timewait 连接,keepalive 的值不要设置过大, 因为这是针对每个 worker 的 Nginx 优化的题外话这个环节, 主要是通过 Nginx 的第三方模块来扩展 Nginx 的功能 Nginx 状态输出 nginx module vts 这个模块可以详细地输出 Nginx 的运行情况, 通过 json 格式的输出, 还可以纳入 Zabbix 监控中, 来监控不同的 vhost 以及不同的 upstream 的运行状态, 便于详细掌握 Nginx 的运行情况动态更新 Nginx Upstream ngx_dynamic_upstream nginx upsync module lua upstream nginx module 动态更新 nginx upstream 其实是为了实现上游服务器进行代码发布时, 让上游服务器能够平滑的上下架, 从而避免对用户抛出错误页面的其中 nginx upsync module 这个模块是最好用的, 配合良好的代码发布流程可以很好地实现上游服务器的上下架缓解 robots 压力 testcookie nginx module 相信很多做互联网公司的运维童鞋, 尤其是那些互联网金融, 还有提供各种优惠券的站点, 最头大的就是被别人恶意的刷短息接口刷优惠码等, 这个模块对于那些没有有 Lua 开发能力的公司而言, 是个福音分布式共享缓存 srcache nginx module+memc nginx module+memcached srcache nginx module+memc nginx module+couchbase srcache nginx module+redis2 nginx module+redis 这三种方案都是用于将缓存放入 memcache 或者 Redis 的, 从而让 Nginx 支持分布式缓存, 而且对于缓存存储不受 Nginx 本地存储的影响, 其中使用 CouchBase 的方案我正在测试中, 有结果会发布在博客上

14 Q&A Q1:Nginx 可以缓存动态内容吗? A1: 可以, 需要做一些条件判断, 简单说就是把 get 方法的缓存,post 方法的 bypass, 后续大家可以参考我博客里的动态页面缓存 Q2: 新版本支持 TCP 吗? A2: 支持, 但不建议使用 Nginx 来做四层负载均衡 Q3: 如果对数据的实时性要求不高, 能用 Nginx 把 jsp 页面和后台数据库的交互数据缓存? A3: 是的, 而且可以对缓存内容做控制, 根据页面时间的需要做配置 Q4: 我们业务有 websocket? 连接传数据, 这样哪个更合适? Q4: 如果这样, 一般建议使用 nginx 的一个模块来实现, 模块叫 nchan 来做 websocket 回放链接直播 : 原文来自微信公众号 :DBAplus 社群

PowerPoint 演示文稿

PowerPoint 演示文稿 Nginx 性能优化 1 目录 1 2 3 影响 Nginx 性能的因素 Nginx 的优化项目 Nginx 题外话影响 Nginx 性能的因素网络层面带宽小, 多个业务域名共享同一网络上行链路网络质量交换机收敛比网络部署架构服务器硬件层面网卡磁盘 CPU 内存操作系统层面 TCP/IP 协议栈 (/etc/sysctl.conf) System Limit(/etc/security/{limits.conf,limits.d)