寻觅生命中的那一片浅草......

文章属于类别 Nginx

一个简单的nginx加多个fastcgi的负载均衡配置过程

一台服务器(xeon 3210 ,4G内存),采用nginx+php(fpm)+xcache+mysql 的架构,运行一个纯动态的php+mysql的网站,经过不懈的优化,在160万pv下运行的很稳定,负载很平稳。但随着访问量的增长,cpu终于还是在 250万pv的时候被大量的php-cgi进程给吃光了。由于网站的特性导致不能使用varnish等cache server。为了解决cpu不够用的问题,又不能把网站停掉,临时决定把一台闲置的服务器用上,做了个简单的负载均衡。把过程写下来备忘。
服务器A(在用的服务器):内网地址 192.168.0.1 运行 nginx mysql php(fpm) xcache
服务器B:内网地址 192.168.0.2 运行 php(fpm) xcache

一。修改服务器B上的php(fpm)的访问权限
默认情况下 php(fpm)监听在 127.0.0.1:9000 并且只允许来自 127.0.0.1的连接。为了能让内网其它机器访问,需要修改服务器B上的 php-fpm.conf中的两行配置。修改后的这两行如下:
<value name=”listen_address”>192.168.0.2:9000</value>
<value name=”allowed_clients”>192.168.0.2</value>
然后重启服务器B上的php-fpm

二。修改服务器A上的mysql访问权限
原来mysql只允许localhost连接的。为了让内网其它机器能够访问,需要修改mysql权限表中的相应用户的host字段,把localhost改成 %
这里还有一个问题,默认的时候mysql启动时是不使用 skip-name-resolve选项的,这样的话,从服务器B上的连接会比较慢,因为mysql会对 192.168.0.2这个ip做dns反向查询,导致大量的从服务器B上的连接处于 login状态…..解决这个问题有两个办法,一是加入 skip-name-resolve参数重启mysql,二是在 /etc/hosts中加入一句 192.168.0.2 server2

三。把程序文件copy一份到服务器B,程序放置的路径,权限等要一致

四。接下来配置最关键的nginx.conf
很简单
原来对php的请求是直接交给 127.0.0.1:9000处理,现在要定义两台
先在http段中加入下面一段
upstream fastcgi {
server 127.0.0.1:9000 weight=1;
server 192.168.0.2:9000 weight=2;
}
然后把原来的 fastcgi_pass 127.0.0.1:9000;
改为 fastcgi_pass fastcgi;
重启nginx,看看服务器B的状态,cpu的使用率马上就上来了,而服务器A的cpu使用率和负载都下降了不少。

做这样的负载均衡,不需要什么复杂的配置,不影响原站点的访问。速度快,工作量少。还是有些可取之处的。

转载自:http://www.admin99.net/read.php/365.htm

有关nginx upstream的几种分配方式

nginx的upstream目前支持4种方式的分配

1、轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。
2、weight
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。
3、ip_hash
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。

4、fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
5、url_hash(第三方)
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。

转载自:http://www.admin99.net/read.php/366.htm

深究Nginx502 bad gateway, 504 Gateway Time-out的彻底解决

我的VPS是256M的内存,CPU是四核心的,所以更多的我会在乎内存。而在我调试服务器的时候通常会遇到Nginx502 bad gateway和504 Gateway Time-out的错误。分析nginx.conf我发现server和fastcgi的buffers过多,导致fastcgi请求的数量过大,php-fpm无法及时处理而出错。循此思路我们可以再总体buffers不变的情况下减少请求数量,具体的ningx.conf改动细节如下:

server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 1 128k; 4 32k
client_max_body_size 8m;

sendfile on;
tcp_nopush     on;

keepalive_timeout 60;

tcp_nodelay on;

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 128k;
fastcgi_buffers 2 256k;8 128
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;

gzip on;
gzip_min_length  1k;
gzip_buffers     1 64k; 4 16
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types       text/plain application/x-javascript text/css application/xml;
gzip_vary on;

另外,php-fpm的默认静态处理方式会使得php-cgi的进程长期占用内存而无法释放,这也是导致nginx出错的原因之一,因此可以将php-fpm的处理方式改成apache模式。

<value name=”style”>apache-like</value>

从更改完毕到现在的测试表明上述方式的效果还是很明显的,并没有发现一次Nginx502 bad gateway或504 Gateway Time-out错误。当然,如果你的VPS或者服务器的性能足够好可以根据具体情况不必做无谓的改动。

转载自:http://www.thismail.org/bbs/thread-3321-1-1.html

Nginx配置nginx.conf解释

#user nobody;

worker_processes 10;多少进程

error_log logs/error.log info;记录什么级别的错误日志

pid        logs/nginx.pid; 进程文件

events {
worker_connections 10000; 最大连接就是进程*这个
}

http {
include       mime.types;
default_type application/octet-stream;
log_format   main ‘$remote_addr – $remote_user [$time_local] $status ‘ 这里是日志
‘”$request” $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent” “$http_x_forwarded_for”‘;

access_log logs/access.log main;
client_header_timeout 3m; 客户端连接上来以后3秒还不发送请求 就断开
client_body_timeout    3m;    同上
send_timeout           3m;
sendfile                on;
tcp_nopush              on;
tcp_nodelay             on;

gzip on;
gzip_min_length 1100; 小于这个就不压了
gzip_buffers     4 8k;
gzip_types       text/* application/x-javascript; 压缩的类型
#output_buffers   1 32k;
output_buffers   1 512k;
gzip_comp_level 9;
postpone_output 1460;

upstream mysvr{#这里定义负载均衡服务器
server 127.0.0.1:8080 weight=1;
}

server {
listen       80;
server_name localhost;

#server_name 192.168.0.253;#写成本机ip就可以

charset utf-8;字符集

access_log logs/host.access.log main;日志

下面一段用于设置nginx的proxy_store:

To be clear proxy_store is not a cache, it’s rather mirror on demand.

To be clear proxy_store is not a cache, it’s rather mirror on demand. 因为没有过期头(expire的概念)

location ~* \.(jpg|gif|png|css|swf|html|htm)$ {

root /var/html/$host;远端被缓存的文件都会被放到这里

proxy_store on;
proxy_set_header Host $host;
proxy_temp_path /web/html/tmp;缓存的tmp目录
proxy_set_header Accept-Encoding ”;
proxy_store_access user:rw group:rw all:rw;权限
if ( !-f $request_filename ) {
proxy_pass http://mysvr;这样只有不存在才回去后端拉
}
}

#      location ~ \ * {
location / {
proxy_pass http://mysvr;
proxy_redirect off;
proxy_store off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 30;
proxy_send_timeout 30;
proxy_read_timeout 30;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;

}
}

location / {
proxy_pass         http://mysvr;   #前面定义的upstream
#        proxy_redirect     off;

proxy_set_header   Host             $host;
proxy_set_header   X-Real-IP        $remote_addr;
#proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;     重写http头,没写会导致访问不了

client_max_body_size       10m; #客户端发送的body,在上传附件的时候可能比较大
client_body_buffer_size    128k;

proxy_connect_timeout      90;
proxy_send_timeout         90;
proxy_read_timeout         90;
#        proxy_send_lowat           12000;
proxy_buffer_size          4k;
proxy_buffers              4 32k;
proxy_busy_buffers_size    64k;
proxy_temp_file_write_size 64k;

}
location ~ \.(gif|js|css)$ { #图片,css本地解析
root    /usr/local/tomcat6.bak/webapps/ROOT;
expires 24h;#过期时间
}
location ~ .*\.(js|jpg|JPG|jpeg|JPEG|css|bmp|gif|GIF)$
{
access_log off;#图片和css不记录日志

}

location /status {
stub_status            on;
access_log      logs/access-status-ip.log;
auth_basic      “status”;
#auth_basic_user_file conf/user;     设置管理员查看连接情况目录
allow   192.168.0.87;
#         allow   10.1.1.0/16;
deny    all;

}
error_page   500 502 503 504 /50x.html;
location = /50x.html {
root   html;
}
}

}

参考文章:

http://wiki.codemongers.com/NginxFullExample2 威客

http://www.chinaunix.net/jh/13/1319835.html         chinaunix

NginxStatus 显示的内容意思如下:

* active connections – 当前 Nginx 正处理的活动连接数。
* server accepts handled requests — 总共处理了 14553819 个连接 ,

成功创建 14553819 次握手 ( 证明中间没有失败的 ), 总共处理了 19239266 个请求 ( 平均每次握手处理了 1.3 个数据请求 )。
* reading — nginx 读取到客户端的 Header 信息数。
* writing — nginx 返回给客户端的 Header 信息数。
* waiting — 开启 keep-alive 的情况下,这个值等于 active – (reading + writing),

意思就是 Nginx 已经处理完正在等候下一次请求指令的驻留连接。
* 另外转剑心的关于解析泛域名 说不定哪天用上:
* ++++++++++++++++++++++++++++++++++++++++++++++
*
nginx支持泛域名解析的方法
*
http://bbs.bsdlover.cn/thread-2194-1-1.html
要使用Nginx下的泛域名支持,必须在编译 Nginx的时候加上
–with-http_sub_module
freebsd下ports安装的时候有提示的,选上即可。

方法我google了半天,网上的好多我照做都是不行的,例如这个:
listen    80;
server_name  www.yourdomain.com *.yourdomain.com;
这个会提示:
# nginx -t
2009/01/04 13:22:56 [emerg] 63944#0: conflicting parameter “*.bsdlover.cn” in www.conf:14
2009/01/04 13:22:56 [emerg] 63944#0: the configuration file nginx.conf test failed

还有些文章里面说的是:
server_name   .yourdomain.com;
这个也是不行的,经过我的实验,正确的做法是:
listen    80;
server_name   _;
这样就可以了,留个笔记,呵呵
* ++++++++++++++++++++++++++++++++++++++
* 二级目录自动加 /
* if (-d $request_filename){
rewrite ^/(.*)([^/])$ http://$host/$1$2/ permanent;
}
*

*

——————————————————————————————————————

nginx的日志管理:

——————————————————————————————————————

Nginx 支持下表中的信号:

信号名 作用描述
TERM, INT 快速关闭程序,中止当前正在处理的请求
QUIT 处理完当前请求后,关闭程序
HUP 重新加载配置,并开启新的工作进程,关闭就的进程,此操作不会中断请求
USR1 重新打开日志文件,用于切换日志,例如每天生成一个新的日志文件
USR2 平滑升级可执行程序
WINCH 从容关闭工作进程

用logrotate来管理;cat /etc/logrotate.d/nginx:

/usr/local/nginx/logs/*.log {
daily每天滚动
rotate 7保留7份
nocompress不压缩
postrotate在执行完滚动后:
if [ -f /usr/local/nginx/logs/nginx.pid ]; then
kill -USR1 `cat /usr/local/nginx/logs/nginx.pid`
fi
endscript
}

生效:logrotate -f 这个文件

PHP程序页面打开空白

已经遇到过两次了,打开一片空白,没有任何提示。

1次是Discuz!首页打开时一片空白,但UCenter又可以打开,登录进后台stat index.php,发现文件的修改日期有问题,被修改日期是6月16日,论坛改版做好后,很久没有修改过这些文件了。估计是被人入侵了!网上有说是编码问题。难道别人把我文件的编码修改了?查看了下备份目录,刚好在6月13日有个备份,把它解压缩出来,覆盖掉原来的,一切恢复正常。

2次是朋友的一个很简单的站,打开是一个空白页面,对比过配置文件,发现跟其他站点的配置一样,怀疑会不会是程序不能在二级目录下运行,就把该主机的根目录设置为那二级目录,结果打开还是不行,又改回来,查看了Nginx的日志,没有错。最后去程序官方,重新下载了一个,直接在服务器上解压缩,再访问,一切正常。注意啊!估计是从Windows传文件上去时,文件出现的问题。无论是SFTP还是FTP,都记得要用binary(二进制)方式上传。这样是最保险的!

2024年五月
« 5月    
 12345
6789101112
13141516171819
20212223242526
2728293031