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

每月存档 九月, 2009

一个简单的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

Cacti无法登陆故障解决一例

Cacti0.87b,今天发现不能登陆。

具体表现为:

用户名/密码输入正确、数据库的user_log表中正确记录了登录信息,并且result为1(验证成功),但是页面始终停留在index.php,不能进入

查资料得知,这个现象大多时候是因为php的session异常。

经检查发现,在这台机器上,由于另一服务的日志突然暴增,导致/分区的磁盘容量用尽,session无地方可写。删除异常的日志文件后,问题得到了解决。

另:

cacti的密码是MD5加密的,可以在登录mysql后,用这种方式重置密码

UPDATE user_auth SET password=MD5(“yourpassword”) WHERE username=’admin’

session.save_handler = files

session.save_path = “/tmp”

转载自:http://www.dbalife.com/archives/146.html

使用tcmalloc后的MySQL服务器变稳定了

之前,一直困恼很久的MySQL的问题因为有了tcmalloc后得以解决。

问题是:网站访问量不高,高峰时并发数在300-400之间。CPU比较高,在30-80%之间波动得厉害,使用top

命令可以看到是mysql进程导致,同时用iostat和sar查看iowait值很高在20-30之间。

但是系统还可以稳定运行,然后周期性的出现swap分区占用率攀升,直接导致应用程序无法连接数据库。不知道

这是不是mysql的swap颠簸的问题。没 解决办法的时候只好经常监控内存的使用情况,碰到swap开始攀升的时候

重启MySQL服务。一般这个周期在一个星期左右。

后来在网上搜到了tcmalloc,说是这个东西可以让MySQL在高并发下性能也很稳定,同时也说了MySQL这个问题是

因为malloc内存分配函数的bug,这个bug会使高并发的MySQL性能急剧下降。

决定试试。

系统是64位的RedHat Enterprise Linux 5.0 。在64位系统下需要安装另外一个包libunwind。然后下载tcmalloc包,

按默认方式编译和安装成功后在 mysqld_safe 中加入

LD_PRELOAD=”/usr/local/lib/libtcmalloc.so”

重启MySQL。没有办法可以验证tcmalloc是否起效,只能再继续监控系统的运行状况。

经过一个多礼拜了,你可以看看下面一个抓自mrtg的图:

上面两个图中,第一个是CPU的图,第二个是内存的图。可以看出从换上tcmalloc后,CPU占用率下降非常明显,

原来一直维持在30%左右,现在只 占不到10%。而内存方面,原来物理内存一直占用100%,swap占用率波动

得很厉害,下降点一般是重启MySQL后导致的,而换上tcmalloc 后,内存维持在80-90%之间,而swap占用率

就非常稳定,可以按零计。

而且已经持续了一个多礼拜了。可以说效果相当相当的明显,非常令人满意。再也不用老去盯着mrtg看了。

当然这是我的机器上现实的情况,不知道其他系统怎样。

libunwind: http://www.nongnu.org/libunwind/
tcmalloc: http://goog-perftools.sourceforge.net/doc/tcmalloc.html

详细的安装步骤

#tar zxvf libunwind-0.98.6.tar.gz
#cd libunwind-0.98.6
#./configure
#make
#make install

#tar zxvf google-perftools-0.94.1.tar.gz
#cd google*
#./configure
#make
#make install

打开 mysqld_safe 脚本 (默认在/usr/bin/mysqld_safe)
在此脚本文件开始加入
LD_PRELOAD=”/usr/local/lib/libtcmalloc.so”

#service mysql restart

/usr/sbin/lsof -n | grep tcmalloc

转载自:http://www.javayou.com/diary/18368

2009年九月
« 8月   10月 »
 123456
78910111213
14151617181920
21222324252627
282930