nginx服务器带宽如何配置
❶ nginx在做负载均衡时如何配置
1、下面的架构就是我们今天的演示结构,后端有两台服务器,分别是node1和node2,前端是一台web服务器,然后在web服务器上做负载均衡,将前端的访问流量导到后端的两个节点服务器上。三个服务器的IP地址分别是:web:192.168.1.210node1:192.168.1.211node2:192.168.1.212
2、按照这样的架构,在后端的node1和node2节点上分配配置好需要访问的网站,然后为了方便测试,我们将两个网站的主页分别改成下面的内容。便于区分访问的节点。
3、后端两个节点配置好以后,我们再来配置web服务器里的负载均衡配置,首先使用默认配置,先打开/etc/nginx/nginx.conf配置文件,在http区块里添加upstream块内容,及配置了两个后端服务器,后端负载均衡集群的名称是backend,记下这个名称。
4、然后再打开/etc/nginx/conf.d/default.conf这个配置文件,在server区块里,把location里面的内容改成图中所示内容。即将所有访问192.168.1.210的流量代理到后端的backend集群里。
5、配置文件配置好以后,使用nginx-t命令测试一下配置文件,保证配置文件是ok状态,然后执行nginx命令启动nginx服务器。
6、启动后在浏览器上输入前端web服务器的ip地址192.168.1.210,然后可以看到第一次是node1响应的,然后刷新一下以后,又变成了node2响应的。就这样实现了负载均衡的效果。由两个服务器分别响应,是因为默认的负载均衡算法是轮询算法,即两个节点轮流来。
7、然后我们还可以尝试一下加权轮询算法,即给不同的节点配置不同的权重,权重高一点的服务器,响应的多一些,权重第一点的响应少一些。加权轮询算法配置,在后端服务器后面加上权重码指唤值weight即可。配置好以后,执行nginx-t命令检测配置文件,确认无误后,执行nginx-sreload命令重新加载配置文件。
8、通过加权轮询的方式,我们无法通过手动一次次点击,最后来统计次数。但是我们可以使用自动化工具来统计。使用的工具是一款叫做httpd-tools的软件,安装好以后,提供了一个ab命令
9、然后我们来执行ab命令进行测试,常用的格式是:ab-n1000-c50http://localhost这个命令是在210服务器上执行的。表示一共执行1000次访问,每次发送50个请求。
10、然后我们登录到后端的node1服务器上,打开nginx的访问日志,从中可以看到ab命令测试的访问信息里,访问来源都是ApacheBench,因此可以通过可以来源来统计nginx响应的次数。命令是:grepApacheBenchaccess.log|wcnode1和node2节点上的统计结果分别是714和286,如下面图中所逗羡示,虽然没有达到5:2的迟凯权重比例,但是也非常接近了。说明这个配置生效了。
❷ [code.nginx] Nginx服务器高级配置
这里提及的参数是和IPv4网络有关的linux内核参数。我们可以将这些内核参数的值追加到Linux系统的/etc/sysctl.conf文件中,然后使用如下命令使修改生效:
这些常用的参数包括以下这些。
** 1. net.core.netdev_max_backlog参数 **
net.core.netdev_max_backlog,表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许发送到队列的数据包的最大数目。一般默认值为128(可能不同的Linux系统该数值也不同)。Nginx服务器中定义的NGX_LISTEN_BACKLOG默认为511.我们可以将它调整一下:
** 2.net.core.somaxconn参数 **
该参数用于调节系统同时发起的TCP连接数,一般默认值为128。在客户端存在高并发请求的情况下,在默认值较小,可能导致链接超时或者重传问题,我们可以根据实际需要结合并发请求数来调节此值。
** 3.net.ipv4.tcp_max_orphans参数 **
该参数用于设定系统中最多允许存在多少TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字,没有与用户文件句柄关联的TCP套接字将立即被复位,同时给出警告信息。这个限制只是为了防止简单的DoS(Denial of Service,拒绝服务)攻击。一般在系统内存比较充足的情况下,可以增大这个参数的赋值:
** 4.net.ipv4.tcp_max_syn_backlog参数 **
该参数用于记录尚未收到客户端确认信息的连接请求的最大值。对于拥有128MB内存的系统而言,此参数的默认值是1024,对小内存的系统则是128。一般在系统内存比较充足的情况下,可以增加这个参数的赋值:
** 5.net.ipv4.tcp_timestamps参数 **
该参数用于设置时间戳,这可以避免序列号的卷绕。在一个1Gb/s的链路上,遇到以前用过的序列号的概率很大。当此值赋值为0时,禁用对于TCP时间戳的支持。在默认情况下,TCP协议会让内核接受这种“异常”的数据包。针对Nginx服务器来说,建议将其关闭:
** 6.net.ipv4.tcp_synack_retries参数 **
该参数用于设置内核放弃TCP连接之前向客户端发送SYN+ACK包的数量。为了建立对端的连接服务,服务器和客户端需要进行三次握手,第二次握手期间,内核需要发送SYN并附带一个回应前一个SYN的ACK,这个参数主要影响这个进程,一般赋值为1,即内核放弃连接之前发送一次SYN+ACK包,可以设置其为:
** 7.net.ipv4.tcp_syn_retries参数 **
该参数的作用和上一个参数类似,设置内核放弃建立连接之前发送SYN包的数量,它的赋值和上个参数一样即可:
在Nginx配置文件中,有这样两个指令:worker_processes和worker_cpu_affinity,它们可以针对多核CPU进行配置优化。
** 1.worker_processes指令 **
worker_processes指令用来设置Nginx服务的进程数。官方文档建议此指令一般设置为1即可,赋值太多会影响系统的IO效率,降低Nginx服务器的性能。为了让多核CPU能够很好的并行处理任务,我们可以将worker_processes指令的赋值适当的增大一些,最好是赋值为机器CPU的倍数。当然,这个值并不是越大越好,Nginx进程太多可能增加主进程调度负担,也可能影响系统的IO效率。针对双核CPU,建议设置为2或
4。如果是四核CPU,设置为:
设置好worker_processes指令之后,就很有必要设置worker_cpu_affinity指令。
** 2. worker_cpu_affinity指令 **
worker_cpu_affinity指令用来为每个进程分配CPU的工作内核。这个指令用来为每个进程分配CPU的工作内核。这个指令的设置方法有些麻烦。
如下图所示:
worker_cpu_affinity指令的值是由几组二进制值表示的。其中,每一组代表一个进程,每组中的每一位表示该进程使用CPU的情况,1表示使用,0表示不使用。注意,二进制位排列顺序和CPU的顺序是相反的。建议将不同的进程平均分配到不同的CPU运行内核上。
如果设置的Nginx服务的进程数为4,CPU为4核,因此会有四组值,并且每组有四位,所以,此指令的设置为:
四组二进制数值分别对应4个进程,第一个进程对应0001,表示使用第一个CPU内核。第二个进程对应0010,表示使用第二个CPU内核,以此类推。
如果将worker_processes指令的值赋值为8,即赋值为CPU内核个数的两倍,则worker_cpu_affinity指令的设置可以是:
如果一台机器的CPU是八核CPU,并且worker_processes指令的值赋值为8,那么worker_cpu_affinity指令的设置可以是:
** 1.keepalive_timeout指令 **
该指令用于设置Nginx服务器与客户端保持连接的超时时间。
这个指令支持两个选项,中间用空格隔开。第一个选项指定客户端连接保持活动的超时时间,在这个时间之后,服务器会关闭此连接。第二个选项可选,其指定了使用Keep-Alive消息头保持活动的有效时间,如果不设置它,Nginx服务器不会向客户端发送Keep-Alive消息头以保持与客户端某些浏览器(如Mozilla、Konqueror等)的连接,超过设置的时间后,客户端就可以关闭连接,而不需要服务器关闭了。你可以根据自己的实际情况设置此值,建议从服务器的访问数量、处理速度以及网络状态方面考虑。下面是此指令的设置示例:
该设置表示Nginx服务器与客户端连接保持活动的时间是60s,60s后服务器与客户端断开连接。使用Keep-Alive消息头保持与客户端某些浏览器(如Mozilla、Konqueror等)的连接时间为50s,50s后浏览器主动与服务器断开连接。
** 2.send_timeout指令 **
该指令用于设置Nginx服务器响应客户端的超时时间,这个超时时间仅针对两个客户端和服务器之间建立连接后,某次活动之间的时间。如果这个时间后客户端没有任何活动,Nginx服务器将会关闭连接。此指令的设置需要考虑服务器访问数量和网络状况等方面。下面是此指令的设置示例:
该设置表示Nginx服务器与客户端建立连接后,某次会话中服务器等待客户端响应超时10s,就会自动关闭连接。
** 3.client_header_buffer_size指令 **
该指令用于设置Nginx服务器允许的客户端请求头部的缓冲区大小,默认为1KB。此指令的赋值可以根据系统分页大小来设置。分页大小可以用以下命令取得:
有过Nginx服务器工作经验的可能遇到Nginx服务器返回400错误的情况。查找Nginx服务器的400错误原因比较困难,因为此错误并不是每次都会出现,出现错误的时候,通常在浏览器和日志里也看不到任何有关提示信息。根据实际的经验来看,有很大一部分情况是客户端的请求头部过大造成的。请求头部过大,通常是客户单cookie中写入了较大的值引起的。于是适当增大此指令的赋值,允许Nginx服务器接收较大的请求头部,可以改善服务器对客户端的支持能力。一般将此指令赋值为4KB大小,即:
** 4.multi_accept指令 **
该指令用于配置Nginx服务器是否尽可能多的接收客户端的网络连接请求,默认值为off。
本节涉及的指令与Nginx服务器的事件驱动模型密切相关。
其中,number为设置的最大数量。结合worker_processes指令,我们可以计算出Nginx服务器允许同时连接的客户端最大数量Client = worker_processes * worker_connections / 2;
在使用Nginx服务器的过程中,笔者曾经遇到过无法访问Nginx服务器的情况,查看日志发现一直在报如下错误:
根据报错信息,推测可能是Nginx服务器的最大访问连接数设置小了。此指令设置的就是Nginx服务器能接受的最大访问量,其中包括前端用户连接也包括其他连接,这个值在理论上等于此指令的值与它允许开启的工作进程最大数的乘积。此指令一般设置为65535:
此指令的赋值与linux操作系统中进程可以打开的文件句柄数量有关系。按照以上设置修改此项赋值以后,Nginx服务器报以下错误:
究其原因,Linux系统中有一个系统指令open file resource limit,它设置了进程可以打开的文件句柄数量。worker_connections指令的赋值当然不能超过open file resource limit的赋值。可以使用以下命令查看在你的Linux系统中open file resource limit的赋值。
可以通过一下命令将open file resource limit指令的值设为2390251:
这样,Nginx的worker_connections指令赋值为65535就没问题了。
其中,limit为Linux平台事件信号队列的长度上限值。
该指令主要影响事件驱动模型中rfsig模型可以保存的最大信号数。Nginx服务器的每一个工作进程有自己的事件信号队列用于暂存客户端请求发生信号,如果超过长度上线,Nginx服务器自动转用poll模型处理未处理器的客户端请求。为了保证Nginx服务器对客户端请求的高效处理,请大家根据实际的客户端并发请求数量和服务器运行环境的处理能力设定该值。设置示例为:
其中,number为要设置的数量,默认值均为32。
其中,number为要设置的数量,默认值均为512.
使用kequeue_changes方式,可以设置与内核之间传递事件的数量。
其中,number为要设置的数量,默认值均为512。
7.rtsig_signo指令
该指令用于设置rtsig模式使用的两个信号中的第一个,第二个信号是在第一个信号的编号上加1,语法为:
默认的第一个信号设置为SIGRTMIN+10。
提示
在Linux中可以使用一下命令查看系统支持的SIGRTMIN有哪些。
8.rtsig_overflow_* 指令
该指令代表三个具体的指令,分别为rtsig_overflow_events指令、rtsig_overflow_test指令和rtsig_overflow_threshold指令。这些指令用来控制当rtsig模式中信号队列溢出时Nginx服务器的处理方式,语法结构为:
其中,number是要设定的值。
rtsig_overflow_events指令指定队列溢出时使用poll库处理的事件数,默认值为16。
rtsig_overflow_test指令设定poll库处理完第几件事件后将清空rtsig模型使用的信号队列,默认值为32。
rtsig_overflow_threshold指令指定rtsig模式使用的信号队列中的事件超过多少时就需要清空队列了。
❸ nginx怎么计算带宽body
req_status_zone
语法: req_status_zone name string size
默认值: None
配置块: http
定义请求状态ZONE,请求按照string分组来排列,例如:
req_status_zone server_url $server_name$uri 256k;
域名+uri将会形成一条数据,可以看到所有url的带宽,流量,访问数
req_status
语法: req_status zone1[ zone2]
❹ 如何给局域网中的服务器分配带宽
普通用户请求下载服务器上的大文件不会有大问题,下载带宽通常在几十M左右,因此一顷绝明个请求对服务器的带宽压力不大。
但当服务器作为雀告CDN回源时就千万要注意了,CDN的机房带宽通常可以达到数百M甚至上G,而IDC机房的带宽费用往往是根据峰值带宽来计算。
因此如果CDN回源大文件时不对服务器带宽做限制,将会出现瞬间极大峰值,造成不必要的经济损失。
解决问题的核心在于限制服务器上行带宽。
我们通过对nginx增加带宽限制尝试解决这个问题。
nginx里有2个配置项
limit_rate <size> 限制单个请求带宽峰值,512, 1k, 10m
limit_rate_after <size> 当下载超过一定大小后开始限制,100m, 100k
进行宏悉如此配置后,我们用curl进行测试,发现当文件下载超过一定大小后,下载速率就会降到limit_rate设定的带宽值。
总结:如果网站有大文件资源时,一定要注意下载速率的配置,特别是在做CDN回源时尤其必须对速率进行配置。即便不做CDN回源,在某些特殊场景下也有可能出现高带宽下载,因此要特别注意