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

文章带标签 Nginx

Nginx下perl(fastcgi)配置

wget http://www.cpan.org/modules/by-module/FCGI/FCGI-0.67.tar.gz
tar xzf FCGI-0.67.tar.gz
cd FCGI-0.67
perl Makefile.PL
make
make install

wget http://www.cpan.org/modules/by-module/FCGI/FCGI-ProcManager-0.18.tar.gz
tar zxf FCGI-ProcManager-0.18.tar.gz
cd FCGI-ProcManager-0.18
perl Makefile.PL
make && make install

配置Perl的FastCGI脚本(从网上找到的,未找到原始出处):
#vi /etc/init.d/perl-fast

****************************************

#!/usr/bin/perl -w

use FCGI;

use Socket;

use FCGI::ProcManager;

sub shutdown { FCGI::CloseSocket($socket); exit; }

sub restart { FCGI::CloseSocket($socket); &main; }

use sigtrap ‘handler’, \&shutdown, ‘normal-signals’;

use sigtrap ‘handler’, \&restart, ‘HUP’;

require ‘syscall.ph’;

use POSIX qw(setsid);

#export FCGI_SOCKET_PATH=”/tmp/perl-fastcgi.sock”

#export FCGI_NPROCESSES=4

#&daemonize; we don’t daemonize when running under runsv

#this keeps the program alive or something after exec’ing perl scripts

END() { }

BEGIN() { }

{

no warnings;

*CORE::GLOBAL::exit = sub { die “fakeexit\nrc=” . shift() . “\n”; };

};

eval q{exit};

if ($@) {

exit unless $@ =~ /^fakeexit/;

}

&main;

sub daemonize() {

chdir ‘/’ or die “Can’t chdir to /: $!”;

defined( my $pid = fork ) or die “Can’t fork: $!”;

exit if $pid;

setsid() or die “Can’t start a new session: $!”;

umask 0;

}

sub main {

#…. IP sockets

#$socket = FCGI::OpenSocket( “127.0.0.1:8999”, 10 );

#…. UNIX sockets

#$socket = FCGI::OpenSocket( “/temp/perl-fastcgi.sock”, 10 );

#foreach $item (keys %ENV) { delete $ENV{$item}; }

#..fastcgi……..

my $n_processes = $ENV{FCGI_NPROCESSES} || 4;

$proc_manager = FCGI::ProcManager->new( {n_processes => $n_processes} );

#..unix socket

$socket = FCGI::OpenSocket( “$ENV{FCGI_SOCKET_PATH}”, 10 );

#..Socket..

chmod 0777, $ENV{FCGI_SOCKET_PATH};

; #use UNIX sockets – user running this script must have w access to the ‘nginx’ folder!!

$request =

FCGI::Request( \*STDIN, \*STDOUT, \*STDERR, \%req_params, $socket,

&FCGI::FAIL_ACCEPT_ON_INTR );

$proc_manager->pm_manage();

if ($request) { request_loop() }

FCGI::CloseSocket($socket);

}

sub request_loop {

while ( $request->Accept() >= 0 ) {

$proc_manager->pm_pre_dispatch();

#processing any STDIN input from WebServer (for CGI-POST actions)

$stdin_passthrough = ”;

{ no warnings; $req_len = 0 + $req_params{‘CONTENT_LENGTH’}; };

if ( ( $req_params{‘REQUEST_METHOD’} eq ‘POST’ ) && ( $req_len != 0 ) )

{

my $bytes_read = 0;

while ( $bytes_read < $req_len ) {

my $data = ”;

my $bytes = read( STDIN, $data, ( $req_len – $bytes_read ) );

last if ( $bytes == 0 || !defined($bytes) );

$stdin_passthrough .= $data;

$bytes_read += $bytes;

}

}

#running the cgi app

if (

( -x $req_params{SCRIPT_FILENAME} ) && #can I execute this?

( -s $req_params{SCRIPT_FILENAME} ) && #Is this file empty?

( -r $req_params{SCRIPT_FILENAME} ) #can I read this file?

)

{

pipe( CHILD_RD, PARENT_WR );

pipe( PARENT_ERR, CHILD_ERR );

my $pid = open( CHILD_O, “-|” );

unless ( defined($pid) ) {

print(“Content-type: text/plain\r\n\r\n”);

print

“Error: CGI app returned no output – Executing $req_params{SCRIPT_FILENAME} failed !\n”;

next;

}

$oldfh = select(PARENT_ERR);

$| = 1;

select(CHILD_O);

$| = 1;

select($oldfh);

if ( $pid > 0 ) {

close(CHILD_RD);

close(CHILD_ERR);

print PARENT_WR $stdin_passthrough;

close(PARENT_WR);

$rin = $rout = $ein = $eout = ”;

vec( $rin, fileno(CHILD_O), 1 ) = 1;

vec( $rin, fileno(PARENT_ERR), 1 ) = 1;

$ein = $rin;

$nfound = 0;

while ( $nfound =

select( $rout = $rin, undef, $ein = $eout, 10 ) )

{

die “$!” unless $nfound != -1;

$r1 = vec( $rout, fileno(PARENT_ERR), 1 ) == 1;

$r2 = vec( $rout, fileno(CHILD_O), 1 ) == 1;

$e1 = vec( $eout, fileno(PARENT_ERR), 1 ) == 1;

$e2 = vec( $eout, fileno(CHILD_O), 1 ) == 1;

if ($r1) {

while ( $bytes = read( PARENT_ERR, $errbytes, 4096 ) ) {

print STDERR $errbytes;

}

if ($!) {

$err = $!;

die $!;

vec( $rin, fileno(PARENT_ERR), 1 ) = 0

unless ( $err == EINTR or $err == EAGAIN );

}

}

if ($r2) {

while ( $bytes = read( CHILD_O, $s, 4096 ) ) {

print $s;

}

if ( !defined($bytes) ) {

$err = $!;

die $!;

vec( $rin, fileno(CHILD_O), 1 ) = 0

unless ( $err == EINTR or $err == EAGAIN );

}

}

last if ( $e1 || $e2 );

}

close CHILD_RD;

close PARENT_ERR;

waitpid( $pid, 0 );

} else {

foreach $key ( keys %req_params ) {

$ENV{$key} = $req_params{$key};

}

# cd to the script’s local directory

if ( $req_params{SCRIPT_FILENAME} =~ /^(.*)\/[^\/]+$/ ) {

chdir $1;

}

close(PARENT_WR);

#close(PARENT_ERR);

close(STDIN);

close(STDERR);

#fcntl(CHILD_RD, F_DUPFD, 0);

syscall( &SYS_dup2, fileno(CHILD_RD), 0 );

syscall( &SYS_dup2, fileno(CHILD_ERR), 2 );

#open(STDIN, “<&CHILD_RD”);

exec( $req_params{SCRIPT_FILENAME} );

die(“exec failed”);

}

} else {

print(“Content-type: text/plain\r\n\r\n”);

print

“Error: No such CGI app – $req_params{SCRIPT_FILENAME} may not exist or is not executable by this process.\n”;

}

}

}

****************************************************************************

#chmod +x  /etc/init.d/perl-fast

#vi /etc/profile

添加以下内容

export FCGI_SOCKET_PATH=”/tmp/perl-fastcgi.sock”

export FCGI_NPROCESSES=4

#source /etc/profile

#/etc/init.d/perl-fast&

为Nginx添加FastCGI的Perl支持
server {

listen       80;

server_name  mail.test5.com;

charset gb2312;

access_log  logs/access.log  main;

location / {

root   /share/htdocs;

index  index.php index.html;

}

location ~* .*\.pl$ {

root  /share/htdocs;

include perl.conf;

}

}

#vi perl.conf

————————————————————–

fastcgi_pass  unix:/tmp/perl-fastcgi.sock;

fastcgi_index openwebmail.pl;

fastcgi_param SCRIPT_FILENAME  $document_root$fastcgi_script_name;

fastcgi_param QUERY_STRING     $query_string;

fastcgi_param REQUEST_METHOD   $request_method;

fastcgi_param CONTENT_TYPE     $content_type;

fastcgi_param CONTENT_LENGTH   $content_length;

fastcgi_param GATEWAY_INTERFACE  CGI/1.1;

fastcgi_param SERVER_SOFTWARE    nginx;

fastcgi_param SCRIPT_NAME        $fastcgi_script_name;

fastcgi_param REQUEST_URI        $request_uri;

fastcgi_param DOCUMENT_URI       $document_uri;

fastcgi_param DOCUMENT_ROOT      $document_root;

fastcgi_param SERVER_PROTOCOL    $server_protocol;

fastcgi_param REMOTE_ADDR        $remote_addr;

fastcgi_param REMOTE_PORT        $remote_port;

fastcgi_param SERVER_ADDR        $server_addr;

fastcgi_param SERVER_PORT        $server_port;

fastcgi_param SERVER_NAME        $server_name;

fastcgi_read_timeout 60;

——————————————————————–
重启nginx

#Kill -HUP `cat /var/run/nginx.pid`

参考:http://blog.chinaunix.net/u/14353/showart_1668580.html

nginx缓存cache的5种方案

http://server.jzxue.com/fuwuqijiqunyuanquan/200907/04-2316.html
貌似从来没有写过nginx的缓存功能,都是只看不分享,这是不好之习惯啊。

1、传统缓存之一(404)

这个办法是把nginx的404错误定向到后端,然后用proxy_store把后端返回的页面保存。

配置:

location / {
root /home/html/;#主目录
expires 1d;#网页的过期时间
error_page 404 =200 /fetch$request_uri;#404定向到/fetch目录下
}

location /fetch/ {#404定向到这里
internal;#指明这个目录不能在外部直接访问到
expires 1d;#网页的过期时间
alias /home/html/;#虚拟目录文件系统地址要和locaion /一致,proxy_store会将文件保存到这目录下
proxy_pass http://www.sudone.com/;#后端upstream地址,/fetch同时是一个代理
proxy_set_header Accept-Encoding ”;#让后端不要返回压缩(gzip或deflate)的内容,保存压缩后的内容会引发乱子。
proxy_store on;#指定nginx将代理返回的文件保存
proxy_temp_path /home/tmp;#临时目录,这个目录要和/home/html在同一个硬盘分区内
}

使用的时候还有要注意是nginx要有权限往/home/tmp和/home/html下有写入文件的权限,在linux下nginx一般会配置成nobody用户运行,这样这两个目录就要chown nobody,设成nobody用户专用,当然也可以chmod 777,不过所有有经验的系统管理员都会建议不要随便使用777。

2、传统缓存之二(!-e)

原理和404跳转基本一致,但更简洁一些:

location / {
root /home/html/;
proxy_store on;
proxy_set_header Accept-Encoding ”;
proxy_temp_path /home/tmp;
if ( !-f $request_filename )
{
proxy_pass http://www.sudone.com/;
}
}

可以看到这个配置比404节约了不少代码,它是用!-f来判断请求的文件在文件系统上存不存在,不存在就proxy_pass到后端,返回同样是用proxy_store保存。

两种传统缓存都有着基本一样的优点和缺点:
缺点1:不支持带参数的动态链接,比如read.php?id=1,因为nginx只保存文件 名,所以这个链接只在文件系统下保存为read.php,这样用户访问read.php?id=2时会返回不正确的结果。同时不支持 http://www.sudone.com/这种形式的首页和二级目录http://www.sudone.com/download/,因为 nginx非常老实,会将这样的请求照链接写入文件系统,而这个链接显然是一个目录,所以保存失败。这些情况都需要写rewrite才能正确保存。
缺点2:nginx内部没有缓存过期和清理的任何机制,这些缓存的文件会永久性地保存在机器上,如果要缓存的东西非常多,那就会撑暴整个硬盘空间。为此可以使用一个shell脚本定期清理,同时可以撰写php等动态程序来做实时更新。
缺点3:只能缓存200状态码,因此后端返回301/302/404等状态码都不会缓存,假如恰好有一个访问量很大的伪静态链接被删除,那就会不停穿透导致后端承载不小压力。
缺点4:nginx不会自动选择内存或硬盘作为存储介质,一切由配置决定,当然在当前的操作系统里都会有操作系统级的文件缓存机制,所以存在硬盘上也不需要过分担心大并发读取造成的io性能问题。

nginx传统缓存的缺点也是它和squid等缓存软件的不同之特色,所以也可看作其优点。在生产应用中它常常用作和squid的搭档,squid 对于带?的链接往往无法阻挡,而nginx能将其访问拦住,例如:http://sudone.com/?http://sudone.com/在 squid上会被当做两个链接,所以会造成两次穿透;而nginx只会保存一次,无论链接变成http://sudone.com/?1还是http: //sudone.com/?123,均不能透过nginx缓存,从而有效地保护了后端主机。

nginx会非常老实地将链接形式保存到文件系统中,这样对于一个链接,可以很方便地查阅它在缓存机器上的缓存状态和内容,也可以很方便地和别的文件管理器如rsync等配合使用,它完完全全就是一个文件系统结构。

这两种传统缓存都可以在linux下将文件保存到/dev/shm里,一般我也是这么做的,这样可以利用系统内存来做缓存,利用内存的话,清理过期 内容速度就会快得多。使用/dev/shm/时除了要把tmp目录也指向到/dev/shm这个分区外,如果有大量小文件和目录,还要修改一下这个内存分 区的inode数量和最大容量:

mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm

上面的命令在一台有3G内存的机器上使用,因为/dev/shm默认最大内存是系统内存的一半就是1500M,这条命令将其调大成2500M,同时 shm系统inode数量默认情况下可能是不够用的,但有趣的是它可以随意调节,这里调节为480000保守了点,但也基本够用了。

3、基于memcached的缓存

nginx对memcached有所支持,但是功能并不是特别之强,性能上还是非常之优秀。

location /mem/ {
if ( $uri ~ “^/mem/([0-9A-Za-z_]*)$” )
{
set $memcached_key “$1”;
memcached_pass     192.168.1.2:11211;
}
expires 70;
}

这个配置会将http://sudone.com/mem/abc指明到memcached的abc这个key去取数据。

nginx目前没有写入memcached的任何机制,所以要往memcached里写入数据得用后台的动态语言完成,可以利用404定向到后端去写入数据。

4、基于第三方插件ncache

ncache是新浪兄弟开发的一个不错的项目,它利用nginx和memcached实现了一部分类似squid缓存的功能,我并没有使用这个插件的经验,可以参考:

http://code.google.com/p/ncache/

5、nginx新开发的proxy_cache功能

从nginx-0.7.44版开始,nginx支持了类似squid较为正规的cache功能,目前还处于开发阶段,支持相当有限,这个缓存是把链接用md5编码hash后保存,所以它可以支持任意链接,同时也支持404/301/302这样的非200状态。

配置:

首先配置一个cache空间:

proxy_cache_path /path/to/cache levels=1:2 keys_zone=NAME:10m inactive=5m max_size=2m clean_time=1m;

注意这个配置是在server标签外,levels指定该缓存空间有两层hash目录,第一层目录是1个字母,第二层为2个字母,保存的文件名就会 类似/path/to/cache/c/29/b7f54b2df7773722d382f4809d65029c;keys_zone为这个空间起个名 字,10m指空间大小为10MB;inactive的5m指缓存默认时长5分钟;max_size的2m是指单个文件超过2m的就不缓 存;clean_time指定一分钟清理一次缓存。

location / {
proxy_pass http://www.sudone.com/;

proxy_cache NAME;#使用NAME这个keys_zone

proxy_cache_valid 200 302 1h;#200和302状态码保存1小时
proxy_cache_valid 301 1d;#301状态码保存一天
proxy_cache_valid any 1m;#其它的保存一分钟
}

ps:支持cache的0.7.44到0.7.51这几个版本的稳定性均有问题,访问有些链接会出现错误,所以这几个版本最好不要在生产环境中使 用。nginx-0.7下目前所知较为稳定的版本是0.7.39。稳定版0.6.36版也是近期更新,如果在配置里没有使用到0.7的一些新标签新功能, 也可以使用0.6.36版。

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

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