Archive for category Nginx

深究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或者服务器的性能足够好可以根据具体情况不必做无谓的改动。

 

以上摘自疯人醉语

测试一下,有效果的话会更新

  • Share/Bookmark

Tags: , , , , , , , , , , , , , , ,

今天发现的一个502 bad gateway可能

在执行较长的PHP脚本时,如果正好来个

/usr/local/php/sbin/php-fpm reload

虽然说是平滑过渡,但也会造成502 bad gateway,无语了

以前以为只有/usr/local/php/sbin/php-fpm restart会造成这样

  • Share/Bookmark

Tags: , , ,

nginx rewrite 参数

正则表达式匹配,其中:

* ~ 为区分大小写匹配
* ~* 为不区分大小写匹配
* !~和!~*分别为区分大小写不匹配及不区分大小写不匹配

文件及目录匹配,其中:

* -f和!-f用来判断是否存在文件
* -d和!-d用来判断是否存在目录
* -e和!-e用来判断是否存在文件或目录
* -x和!-x用来判断文件是否可执行

flag标记有:

* last 相当于Apache里的[L]标记,表示完成rewrite
* break 终止匹配, 不再匹配后面的规则
* redirect 返回302临时重定向
* permanent 返回301永久重定向

一些可用的全局变量有,可以用做条件判断(待补全)

$args
$content_length
$content_type
$document_root
$document_uri
$host
$http_user_agent
$http_cookie
$limit_rate
$request_body_file
$request_method
$remote_addr
$remote_port
$remote_user
$request_filename
$request_uri
$query_string
$scheme
$server_protocol
$server_addr
$server_name
$server_port
$uri

结合QeePHP的例子

if (!-d $request_filename) {
rewrite ^/([a-z-A-Z]+)/([a-z-A-Z]+)/?(.*)$ /index.php?namespace=user&controller=$1&action=$2&$3 last;
rewrite ^/([a-z-A-Z]+)/?$ /index.php?namespace=user&controller=$1 last;
break;
}

  • Share/Bookmark

Tags: , , , , , , , , , , ,

wordpress多用户版服务器配置

nginx上,只要server_name 设置为 *.crazylemon.net 通配所有子域名

域名解析时,也只要设 *  A记录到服务器IP即可

不要一个个来,方便多了,为自己早上错误的想法寒一个。。。

  • Share/Bookmark

Tags: , , , , , ,

测试nginx配置文件的方法

/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf

-t 表示test

-c 指定目标文件

成功则显示

the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
configuration file /usr/local/nginx/conf/nginx.conf test is successful

 

nginx的几个命令参数

Nginx 安装后只有一个程序文件,本身并不提供各种管理程序,它是使用参数和系统信号机制对 Nginx 进程本身进行控制的。 Nginx 的参数包括有如下几个:

    -c <path_to_config>:使用指定的配置文件而不是 conf 目录下的 nginx.conf 。

    -t:测试配置文件是否正确,在运行时需要重新加载配置的时候,此命令非常重要,用来检测所修改的配置文件是否有语法错误。

    -v:显示 nginx 版本号。

    -V:显示 nginx 的版本号以及编译环境信息以及编译时的参数。

  • Share/Bookmark

Tags: , , , , , ,

nginx.conf – nginx配置文件说明

#用户和用户组
user www www;

#指令指定处理进程的数量。一般推荐为处理器的个数. 可以适当增加,以避免进程在堵塞在IO等待中。
worker_processes 8;

#错误日志
error_log logs/error.log;

#pid文件位置
pid logs/nginx.pid;

events {
#指定 nginx 处理进程的个数,其与总处理量的关系用公式表达如下:
#MaxClient = worker_processes * worker_connections
#因此这两个数的乘积若大于系统最大可用tcp/ip栈数是没有意义的.
worker_connections 1024;
}

#HTTP 请求设置
http {
#载入mime类型
include mime.types;
#默认类型
default_type application/octet-stream;

#日志的格式
log_format main ‘$remote_addr – $remote_user [$time_local] “$request” ‘
‘$status $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent” “$http_x_forwarded_for”‘;

#访问日志
access_log logs/access.log main;

#sendfile 指令指定 nginx 是否调用 sendfile 函数(zero copy 方式)来输出文件,
#对于普通应用,必须设为 on。
#如果用来进行下载等应用磁盘IO重负载应用,可设置为 off,以平衡磁盘与网络IO处理速度,降低系统 uptime。
sendfile on;

tcp_nopush on;

#keepalive_timeout 0;
keepalive_timeout 65;

#gzip on;

#服务器设置
server {
#监听端口
listen 80;

#WEB服务主机名
server_name localhost;

#charset utf-8;

#访问日志
access_log logs/localhost.access.log main;

#请求规则 默认请求
location / {
#WEB根目录
root /home/www/www;
#默认索引文件名
index index.html index.htm index.php;
}

#页面不存在处理
error_page 404 /404.html;

#服务器错误定向
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /home/www/www;
}
#PHP 脚本请求全部转发到 FastCGI处理. 使用FastCGI默认配置.
location ~ \.php$ {
root /home/www/www;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/www/www$fastcgi_script_name;
include fastcgi_params;
}

#禁止访问 .htxxx 文件
location ~ /\.ht {
deny all;
}
}
}

  • Share/Bookmark

Tags: , , , , , , , , , , , , , , , , , ,

osCommerce 在 nginx 上的 rewrite 规则

location / {
 if (!-e $request_filename)
 {
rewrite “^(.*)-p-(.*).html” /product_info.php?products_id=$2%1;
rewrite “^(.*)-p-(.*).html” /product_info.php?products_id=$2&% last;
rewrite “^(.*)-c-(.*).html” /index.php?cPath=$2&% last;
rewrite “^(.*)-m-(.*).html” /index.php?manufacturers_id=$2&% last;
rewrite “^(.*)-pi-(.*).html” /popup_image.php?pID=$2&% last;
rewrite “^(.*)-t-(.*).html” /articles.php?tPath=$2&% last;
rewrite “^(.*)-au-(.*).html” /articles.php?authors_id=$2&% last;
rewrite “^(.*)-a-(.*).html” /article_info.php?articles_id=$2&% last;
rewrite “^(.*)-pr-(.*).html” /product_reviews.php?products_id=$2&% last;
rewrite “^(.*)-pri-(.*).html” /product_reviews_info.php?products_id=$2&% last;
rewrite “^(.*)-i-(.*).html” /information.php?info_id=$2&% last;
rewrite “^(.*)-pm-([0-9]+).html” /info_pages.php?pages_id=$2&% last;
rewrite “^(.*)-links-(.*).html” /links.php?lPath=$2&% last;
rewrite “^(.*)-n-(.*).html” /newsdesk_info.php?newsdesk_id=$2&% last;
rewrite “^(.*)-nc-(.*).html” /newsdesk_index.php?newsPath=$2&% last;
rewrite “^(.*)-nri-(.*).html” /newsdesk_reviews_info.php?newsdesk_id=$2&% last;
rewrite “^(.*)-nra-(.*).html” /newsdesk_reviews_article.php?newsdesk_id=$2&% last;
rewrite “^(.*)-f-(.*).html” /faqdesk_info.php?faqdesk_id=$2&% last;
rewrite “^(.*)-fc-(.*).html” /faqdesk_index.php?faqPath=$2&% last;
rewrite “^(.*)-fri-(.*).html” /faqdesk_reviews_info.php?faqdesk_id=$2&% last;
rewrite “^(.*)-fra-(.*).html” /faqdesk_reviews_article.php?faqdesk_id=$2&% last;
 }
}

相应的apache为:

RewriteRule ^(.*)-p-(.*).html$ product_info.php?products_id=$2%1
RewriteRule ^(.*)-p-(.*).html$ product_info.php?products_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-c-(.*).html$ index.php?cPath=$2&%{QUERY_STRING}
RewriteRule ^(.*)-m-(.*).html$ index.php?manufacturers_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-pi-(.*).html$ popup_image.php?pID=$2&%{QUERY_STRING}
RewriteRule ^(.*)-t-(.*).html$ articles.php?tPath=$2&%{QUERY_STRING}
RewriteRule ^(.*)-au-(.*).html$ articles.php?authors_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-a-(.*).html$ article_info.php?articles_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-pr-(.*).html$ product_reviews.php?products_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-pri-(.*).html$ product_reviews_info.php?products_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-i-(.*).html$ information.php?info_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-pm-([0-9]+).html$ info_pages.php?pages_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-links-(.*).html$ links.php?lPath=$2&%{QUERY_STRING}
RewriteRule ^(.*)-n-(.*).html$ newsdesk_info.php?newsdesk_id=$2&%{QUERY_STRING}

RewriteRule ^(.*)-nc-(.*).html$ newsdesk_index.php?newsPath=$2&%{QUERY_STRING}
RewriteRule ^(.*)-nri-(.*).html$ newsdesk_reviews_info.php?newsdesk_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-nra-(.*).html$ newsdesk_reviews_article.php?newsdesk_id=$2&%{QUERY_STRING}

RewriteRule ^(.*)-f-(.*).html$ faqdesk_info.php?faqdesk_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-fc-(.*).html$ faqdesk_index.php?faqPath=$2&%{QUERY_STRING}
RewriteRule ^(.*)-fri-(.*).html$ faqdesk_reviews_info.php?faqdesk_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-fra-(.*).html$ faqdesk_reviews_article.php?faqdesk_id=$2&%{QUERY_STRING}

  • Share/Bookmark

Tags: , , , , , , , , , ,

bind() for address ‘127.0.0.1:9000′ failed: Address already in use

今天一台服务器又当了,因为php-fpm.log又写满2G,这个log文件一直在狂写,不知道什么原因,有空得查一下

服务器  502 Bad Gateway

删了php-fpm.log,重启php-fpm

/usr/local/php/sbin/php-fpm restart

没用,报错:

Shutting down php_fpm /usr/local/php/sbin/php-fpm: line 69: kill: (5899) – No such process

原来已经没有这个进程

/usr/local/php/sbin/php-fpm start

虽然提示:Starting php_fpm  done

但还是没启动成功,依然是502 Bad Gateway

查看日志文件:

 [NOTICE] fpm_unix_init_main(), line 284: getrlimit(nofile): max:51200, cur:51200
 [ERROR] fpm_sockets_new_listening_socket(), line 221: bind() for address ‘127.0.0.1:9000′ failed: Address already in use (98)

 原来127.0.0.1:9000端口被占用了

输入命令:netstat -ntlp,查看端口占用情况:

tcp        0      0 127.0.0.1:9000              0.0.0.0:*                   LISTEN      19447/php-cgi

原来还有个php-cgi进程在跑

输入:killall php-cgi  杀掉所有 php-cgi 进程

然后启动 php-fpm :

/usr/local/php/sbin/php-fpm start

OK,成功了

  • Share/Bookmark

Tags: , , , , , , , , , ,

nginx详解

Nginx 概述
 

HTTP基础功能:  

处理静态文件,索引文件以及自动索引; 
反向代理加速(无缓存),简单的负载均衡和容错; 
FastCGI,简单的负载均衡和容错; 
模块化的结构。过滤器包括gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI过滤器中,到同一个 proxy 或者 FastCGI 的多个子请求并发处理; 
SSL 和 TLS SNI 支持;  
 

IMAP/POP3 代理服务功能:  

使用外部 HTTP 认证服务器重定向用户到 IMAP/POP3 后端; 
使用外部 HTTP 认证服务器认证用户后连接重定向到内部的 SMTP 后端; 
认证方法:  
POP3: POP3 USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5; 
IMAP: IMAP LOGIN; 
SMTP: AUTH LOGIN PLAIN CRAM-MD5; 
SSL 支持; 
在 IMAP 和 POP3 模式下的 STARTTLS 和 STLS 支持;  
支持的操作系统:  

FreeBSD 3.x, 4.x, 5.x, 6.x i386; FreeBSD 5.x, 6.x amd64; 
Linux 2.2, 2.4, 2.6 i386; Linux 2.6 amd64; 
Solaris 8 i386; Solaris 9 i386 and sun4u; Solaris 10 i386;
MacOS X (10.4) PPC;
结构与扩展:

一个主进程和多个工作进程。工作进程是单线程的,且不需要特殊授权即可运行;
kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select, 以及 poll 支持;
kqueue支持的不同功能包括 EV_CLEAR, EV_DISABLE (临时禁止事件), NOTE_LOWAT, EV_EOF, 有效数据的数目,错误代码;
sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+), 和 sendfilev (Solaris 8 7/01+) 支持;
输入过滤 (FreeBSD 4.1+) 以及 TCP_DEFER_ACCEPT (Linux 2.4+) 支持;
10,000 非活动的 HTTP keep-alive 连接仅需要 2.5M 内存。
最小化的数据拷贝操作;
其他HTTP功能:

基于IP 和名称的虚拟主机服务;
Memcached 的 GET 接口;
支持 keep-alive 和管道连接;
灵活简单的配置;
重新配置和在线升级而无须中断客户的工作进程;
可定制的访问日志,日志写入缓存,以及快捷的日志回卷;
4xx-5xx 错误代码重定向;
基于 PCRE 的 rewrite 重写模块;
基于客户端 IP 地址和 HTTP 基本认证的访问控制;
PUT, DELETE, 和 MKCOL 方法;
支持 FLV (Flash 视频);
带宽限制;
实验特性:

内嵌的 perl
通过 aio_read()/aio_write() 的套接字工作的实验模块,仅在 FreeBSD 下。
对线程的实验化支持,FreeBSD 4.x 的实现基于 rfork()
为什么选择Nginx
 

Nginx 是一个高性能的 Web 和反向代理服务器, 它具有有很多非常优越的特性:

作为 Web 服务器:相比 Apache,Nginx 使用更少的资源,支持更多的并发连接,体现更高的效率,这点使 Nginx 尤其受到虚拟主机提供商的欢迎。能够支持高达 50,000 个并发连接数的响应,感谢 Nginx 为我们选择了 epoll and kqueue 作为开发模型.
作为负载均衡服务器:Nginx 既可以在内部直接支持 Rails 和 PHP,也可以支持作为 HTTP代理服务器 对外进行服务。Nginx 用 C 编写, 不论是系统资源开销还是 CPU 使用效率都比 Perlbal 要好的多。
作为邮件代理服务器: Nginx 同时也是一个非常优秀的邮件代理服务器(最早开发这个产品的目的之一也是作为邮件代理服务器),Last.fm 描述了成功并且美妙的使用经验。
Nginx 安装非常的简单,配置文件 非常简洁(还能够支持perl语法),Bugs非常少的服务器: Nginx 启动特别容易,并且几乎可以做到7*24不间断运行,即使运行数个月也不需要重新启动。你还能够在 不间断服务的情况下进行软件版本的升级。
安装Nginx
 

预先编译好的安装包

Nginx在一些Linux发行版和BSD的各个变种版本的安装包仓库中都会有,通过各个系统自带的软件包管理方法即可安装。需要注意的是,很多预先编译好的安装包都比较陈旧,大多数情况下还是推荐直接从源码编译。

 

官方源代码下载

点击下载源代码

 

使用源代码进行构建

Nginx 使用 Unix 下常用的 ‘./configure && make && make install’ 过程来编译安装。

configure 脚本确定系统所具有一些特性,特别是 nginx 用来处理连接的方法。然后,它创建 Makefile 文件。

configure 支持下面的选项:

–prefix=<path> – Nginx安装路径。如果没有指定,默认为 /usr/local/nginx。

–sbin-path=<path> – Nginx可执行文件安装路径。只能安装时指定,如果没有指定,默认为<prefix>/sbin/nginx。

–conf-path=<path> – 在没有给定-c选项下默认的nginx.conf的路径。如果没有指定,默认为<prefix>/conf/nginx.conf。

–pid-path=<path> – 在nginx.conf中没有指定pid指令的情况下,默认的nginx.pid的路径。如果没有指定,默认为 <prefix>/logs/nginx.pid。

–lock-path=<path> – nginx.lock文件的路径。

–error-log-path=<path> – 在nginx.conf中没有指定error_log指令的情况下,默认的错误日志的路径。如果没有指定,默认为 <prefix>/logs/error.log。

–http-log-path=<path> – 在nginx.conf中没有指定access_log指令的情况下,默认的访问日志的路径。如果没有指定,默认为 <prefix>/logs/access.log。

–user=<user> – 在nginx.conf中没有指定user指令的情况下,默认的nginx使用的用户。如果没有指定,默认为 nobody。

–group=<group> – 在nginx.conf中没有指定user指令的情况下,默认的nginx使用的组。如果没有指定,默认为 nobody。

–builddir=DIR – 指定编译的目录

–with-rtsig_module – 启用 rtsig 模块

–with-select_module –without-select_module – Whether or not to enable the select module. This module is enabled by default if a more suitable method such as kqueue, epoll, rtsig or /dev/poll is not discovered by configure.

//允许或不允许开启SELECT模式,如果 configure 没有找到更合适的模式,比如:kqueue(sun os),epoll (linux kenel 2.6+), rtsig(实时信号)或者/dev/poll(一种类似select的模式,底层实现与SELECT基本相 同,都是采用轮训方法) SELECT模式将是默认安装模式

–with-poll_module –without-poll_module – Whether or not to enable the poll module. This module is enabled by default if a more suitable method such as kqueue, epoll, rtsig or /dev/poll is not discovered by configure.

–with-http_ssl_module – Enable ngx_http_ssl_module. Enables SSL support and the ability to handle HTTPS requests. Requires OpenSSL. On Debian, this is libssl-dev.

//开启HTTP SSL模块,使NGINX可以支持HTTPS请求。这个模块需要已经安装了OPENSSL,在DEBIAN上是libssl

–with-http_realip_module – 启用 ngx_http_realip_module

–with-http_addition_module – 启用 ngx_http_addition_module

–with-http_sub_module – 启用 ngx_http_sub_module

–with-http_dav_module – 启用 ngx_http_dav_module

–with-http_flv_module – 启用 ngx_http_flv_module

–with-http_stub_status_module – 启用 “server status” 页

–without-http_charset_module – 禁用 ngx_http_charset_module

–without-http_gzip_module – 禁用 ngx_http_gzip_module. 如果启用,需要 zlib 。

–without-http_ssi_module – 禁用 ngx_http_ssi_module

–without-http_userid_module – 禁用 ngx_http_userid_module

–without-http_access_module – 禁用 ngx_http_access_module

–without-http_auth_basic_module – 禁用 ngx_http_auth_basic_module

–without-http_autoindex_module – 禁用 ngx_http_autoindex_module

–without-http_geo_module – 禁用 ngx_http_geo_module

–without-http_map_module – 禁用 ngx_http_map_module

–without-http_referer_module – 禁用 ngx_http_referer_module

–without-http_rewrite_module – 禁用 ngx_http_rewrite_module. 如果启用需要 PCRE 。

–without-http_proxy_module – 禁用 ngx_http_proxy_module

–without-http_fastcgi_module – 禁用 ngx_http_fastcgi_module

–without-http_memcached_module – 禁用 ngx_http_memcached_module

–without-http_limit_zone_module – 禁用 ngx_http_limit_zone_module

–without-http_empty_gif_module – 禁用 ngx_http_empty_gif_module

–without-http_browser_module – 禁用 ngx_http_browser_module

–without-http_upstream_ip_hash_module – 禁用 ngx_http_upstream_ip_hash_module

–with-http_perl_module – 启用 ngx_http_perl_module

–with-perl_modules_path=PATH – 指定 perl 模块的路径

–with-perl=PATH – 指定 perl 执行文件的路径

–http-log-path=PATH – Set path to the http access log

–http-client-body-temp-path=PATH – Set path to the http client request body temporary files

–http-proxy-temp-path=PATH – Set path to the http proxy temporary files

–http-fastcgi-temp-path=PATH – Set path to the http fastcgi temporary files

–without-http – 禁用 HTTP server

–with-mail – 启用 IMAP4/POP3/SMTP 代理模块

–with-mail_ssl_module – 启用 ngx_mail_ssl_module

–with-cc=PATH – 指定 C 编译器的路径

–with-cpp=PATH – 指定 C 预处理器的路径

–with-cc-opt=OPTIONS – Additional parameters which will be added to the variable CFLAGS. With the use of the system library PCRE in FreeBSD, it is necessary to indicate –with-cc-opt=”-I /usr/local/include”. If we are using select() and it is necessary to increase the number of file descriptors, then this also can be assigned here: –with-cc-opt=”-D FD_SETSIZE=2048″.

–with-ld-opt=OPTIONS – Additional parameters passed to the linker. With the use of the system library PCRE in FreeBSD, it is necessary to indicate –with-ld-opt=”-L /usr/local/lib”.

–with-cpu-opt=CPU – 为特定的 CPU 编译,有效的值包括:pentium, pentiumpro, pentium3, pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64

–without-pcre – 禁止 PCRE 库的使用。同时也会禁止 HTTP rewrite 模块。在 “location” 配置指令中的正则表达式也需要 PCRE 。

–with-pcre=DIR – 指定 PCRE 库的源代码的路径。

–with-pcre-opt=OPTIONS – Set additional options for PCRE building.

–with-md5=DIR – Set path to md5 library sources.

–with-md5-opt=OPTIONS – Set additional options for md5 building.

–with-md5-asm – Use md5 assembler sources.

–with-sha1=DIR – Set path to sha1 library sources.

–with-sha1-opt=OPTIONS – Set additional options for sha1 building.

–with-sha1-asm – Use sha1 assembler sources.

–with-zlib=DIR – Set path to zlib library sources.

–with-zlib-opt=OPTIONS – Set additional options for zlib building.

–with-zlib-asm=CPU – Use zlib assembler sources optimized for specified CPU, valid values are: pentium, pentiumpro

–with-openssl=DIR – Set path to OpenSSL library sources

–with-openssl-opt=OPTIONS – Set additional options for OpenSSL building

–with-debug – 启用调试日志

–add-module=PATH – Add in a third-party module found in directory PATH

在不同版本间,选项可能会有些许变化,请总是使用 ./configure –help 命令来检查一下当前的选项列表。

示例 (最好能在同一行):

 

    ./configure \        –sbin-path=/usr/local/nginx/nginx \        –conf-path=/usr/local/nginx/nginx.conf \        –pid-path=/usr/local/nginx/nginx.pid \        –with-http_ssl_module \        –with-pcre=../pcre-4.4 \        –with-zlib=../zlib-1.1.3
 

Ubuntu/debian 上的示例,需要预先安装 libgcrypt11-dev, libpcre3-dev 和 libssl-dev (选择 –with-md5 或 –with-sha1 中的一个, 但不能都选; 在 debian 和 ubuntu 上, 它们应该都指向 /usr/lib)

 

     ./configure –with-openssl=/usr/lib/ssl/ –with-md5=/usr/lib
 

Ubuntu Edgy 的一个 0.5.2 版本的 .deb 包可以在这里下载: nginx_0.5.2-1_i386.deb.

(注: 根据 October 2006 message 的消息,md5 在一个现在不再使用的 http 缓存模块中用到,而 sha1 用在一个未完成的 mysql 库模块,所以它们当前都不是必须的)

 

运行和控制 Nginx – 命令行参数和信号
不像许多其他软件系统,Nginx 仅有数个命令行参数,完全通过配置文件来配置(想象一下)。

选项
示例
使用信号加载新的配置
平滑升级到新的二进制代码
 

 

选项

-c </path/to/config> 为 Nginx 指定一个配置文件,来代替缺省的。

-t 不运行,而仅仅测试配置文件。nginx 将检查配置文件的语法的正确性,并尝试打开配置文件中所引用到的文件。

-v 显示 nginx 的版本。

-V 显示 nginx 的版本,编译器版本和配置参数。

 

示例

 

/usr/bin/nginx -t -c ~/mynginx.conf
 

 

通过系统的信号控制 Nginx

可以使用信号系统来控制主进程。默认,nginx 将其主进程的 pid 写入到 /usr/local/nginx/logs/nginx.pid 文件中。通过传递参数给 ./configure 或使用 pid 指令,来改变该文件的位置。

主进程可以处理以下的信号:

TERM, INT 快速关闭
QUIT 从容关闭
HUP 重载配置
用新的配置开始新的工作进程
从容关闭旧的工作进程
USR1 重新打开日志文件
USR2 平滑升级可执行程序。
WINCH 从容关闭工作进程

 

尽管你不必自己操作工作进程,但是,它们也支持一些信号:

TERM, INT 快速关闭
QUIT 从容关闭
USR1 重新打开日志文件

 

 

使用信号加载新的配置

Nginx 支持几个信号,能在它运行时控制其操作。其中最普通的是 15 ,用来中止运行的进程:

 

# ps aux | egrep ‘(PID|nginx)’USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMANDroot      2213  0.0  0.0   6784  2036 ?        Ss   03:01   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
# kill -15 2213
 

而最有趣的是能平滑改变 nginx 配置的选项(请注意,在重载前,要先测试一下配置文件):

 

# nginx -t -c /etc/nginx/nginx.conf2006/09/16 13:07:10 [info] 15686#0: the configuration file /etc/nginx/nginx.conf syntax is ok2006/09/16 13:07:10 [info] 15686#0: the configuration file /etc/nginx/nginx.conf was tested successfully
# ps aux | egrep ‘(PID|nginx)’
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      2213  0.0  0.0   6784  2036 ?        Ss   03:01   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
# kill -HUP 2213
 

当 nginx 接收到 HUP 信号,它会尝试先解析配置文件(如果指定配置文件,就使用指定的,否则使用默认的),成功的话,就应用新的配置文件(例如:重新打开日志文件或监听的套接 字)。之后,nginx 运行新的工作进程并从容关闭旧的工作进程。通知工作进程关闭监听套接字但是继续为当前连接的客户提供服务。所有客户端的服务完成后,旧的工作进程被关闭。 如果新的配置文件应用失败,nginx 将继续使用旧的配置进行工作。

 

平滑升级到新的二进制代码

你可以在不中断服务的情况下 – 新的请求也不会丢失,使用新的 nginx 可执行程序替换旧的(当升级新版本或添加/删除服务器模块时)。

首先,使用新的可执行程序替换旧的(最好做好备份),然后,发送 USR2 (kill -USR2 pid)信号给主进程。主进程将重命名它的 .pid 文件为 .oldbin (比如:/usr/local/nginx/logs/nginx.pid.oldbin),然后执行新的可执行程序,依次启动新的主进程和新的工作进程:

 

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx33134 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
33135 33126 nobody   0.0  1380 kqread nginx: worker process (nginx)
33136 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
 

在这时,两个 nginx 实例会同时运行,一起处理输入的请求。要逐步停止旧的实例,你必须发送 WINCH 信号给旧的主进程,然后,它的工作进程就将开始从容关闭:

 

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx33135 33126 nobody   0.0  1380 kqread nginx: worker process is shutting down (nginx)
36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
 

一段时间后,旧的工作进程处理了所有已连接的请求后退出,就仅由新的工作进程来处理输入的请求了:

 

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
 

这时,因为旧的服务器还尚未关闭它监听的套接字,所以,通过下面的几步,你仍可以恢复旧的服务器:

发送 HUP 信号给旧的主进程 – 它将在不重载配置文件的情况下启动它的工作进程
发送 QUIT 信号给新的主进程,要求其从容关闭其工作进程
发送 TERM 信号给新的主进程,迫使其退出
如果因为某些原因新的工作进程不能退出,向其发送 KILL 信号
新的主进程退出后,旧的主进程会由移除 .oldbin 前缀,恢复为它的 .pid 文件,这样,一切就都恢复到升级之前了。

如果尝试升级成功,而你也希望保留新的服务器时,发送 QUIT 信号给旧的主进程使其退出而只留下新的服务器运行:

 

      PID  PPID USER    %CPU   VSZ WCHAN  COMMAND    36264     1 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx    36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
    36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
    36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
 

Nginx 配置优化
hash表

Ngnix使用hash表来协助完成请求的快速处理。

考虑到保存键及其值的hash表存储单元的大小不至于超出设定参数(hash bucket size), 在启动和每次重新配置时,Nginx为hash表选择尽可能小的尺寸。

直到hash表超过参数(hash max size)的大小才重新进行选择. 对于大多数hash表都有指令来修改这些参数。例如,保存服务器名字的hash表是由指令 server_names_hash_max_size 和 server_names_hash_bucket_size所 控制的。参数hash bucket size总是等于hash表的大小,并且是一路处理器缓存大小的倍数。在减少了在内存中的存取次数后,使在处理器中加速查找hash表键值成为可能。如果 hash bucket size等于一路处理器缓存的大小,那么在查找键的时候,最坏的情况下在内存中查找的次数为2。第一次是确定存储单元的地址,第二次是在存储单元中查找键 值。因此,如果Nginx给出需要增大 hash max size 或 hash bucket size的提示,那么首要的是增大前一个参数的大小.

 

事件模型

Nginx支持如下处理连接的方法(I/O复用方法),这些方法可以通过use指令指定。

select – 标准方法。 如果当前平台没有更有效的方法,它是编译时默认的方法。你可以使用配置参数 –with-select_module 和 –without-select_module 来启用或禁用这个模块。
poll – 标准方法。 如果当前平台没有更有效的方法,它是编译时默认的方法。你可以使用配置参数 –with-poll_module 和 –without-poll_module 来启用或禁用这个模块。
kqueue – 高效的方法,使用于 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用双处理器的MacOS X系统使用kqueue可能会造成内核崩溃。
epoll – 高效的方法,使用于Linux内核2.6版本及以后的系统。在某些发行版本中,如SuSE 8.2, 有让2.4版本的内核支持epoll的补丁。
rtsig – 可执行的实时信号,使用于Linux内核版本2.2.19以后的系统。默认情况下整个系统中不能出现大于1024个POSIX实时(排队)信号。这种情况对于高负载的服务器来说是低效的;所以有必要通过调节内核参数 /proc/sys/kernel/rtsig-max 来增加队列的大小。可是从Linux内核版本2.6.6-mm2开始, 这个参数就不再使用了,并且对于每个进程有一个独立的信号队列,这个队列的大小可以用 RLIMIT_SIGPENDING 参数调节。当这个队列过于拥塞,nginx就放弃它并且开始使用 poll 方法来处理连接直到恢复正常。
/dev/poll – 高效的方法,使用于 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+.
eventport – 高效的方法,使用于 Solaris 10. 为了防止出现内核崩溃的问题, 有必要安装 这个 安全补丁。
 

参考:Nginx 中文站:http://www.nginx.cn/NginxChsFeatureRequests

  • Share/Bookmark

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Nginx的WordPress配置

WordPress是一个非常流行的Blog系统,它可以利用Apache的mod_rewrite来实现URL的静态化。安装好的WordPress在配置了持久链接之后,会在网站的根目录下(如果可写)生成一个.htaccess文件,这个文件可以指示Apache如何进行URL重写(如果服务器配置为允许使用htaccess的指令的话),它的内容如下:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

这个文件的意思就是,如果当请求的文件不存在,那么把请求内部重定向到/index.php。WordPress会自己分析请求的URL,来判断显示哪个页面。

在上次配置了Nginx+PHP之后,由于Nginx不支持Apache的.htaccess文件,要实现持久连接静态化,我们必须手工配置Nginx的文件。首先找到Nginx的配置文件,默认编译后的配置文件在/usr/local/nginx/conf/nginx.conf;Ubuntu通过包安装的配置文件位于/etc/nginx/nginx.conf,也可以编辑vhost的配置文件,放在了/etc/nginx/sites-available下。

以下是基本的配置(centos 下的范例):

   location / {
        index index.html index.php;
        if (-f $request_filename/index.html){
            rewrite (.*) $1/index.html break;
        }
        if (-f $request_filename/index.php){
            rewrite (.*) $1/index.php;
        }
        if (!-f $request_filename){
            rewrite (.*) /index.php;
        }
    }
    location ~ .*\.php$ {
        include /etc/nginx/fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
    }

还可以有很多种不同配置方式,例如不改写所有包含wp-的url等。此配置考虑了目录下的索引文件index.html和index.php。-f指令表示测试文件是否存在(不考虑文件和目录的区别),!-f则表示不存在。注意在重写url到index.html后面有个break,而重写到index.php后没有break。因为html文件不需要任何额外工作可以直接发送到客户端,所以重写规则在这里终止,下面就直接让nginx发送文件。而.php文件需要进一步发送到fastcgi进程来运行,Nginx会继续判断该文件符合第二个部分location ~ .*\.php$的规则,并进行FastCGI的转发。

大家可以将以上内容保存为wordpress.conf,然后在自己的vhost配置,即server节中应用该配置文件,例如(以下为 centos 进行的配置):

server {
        listen   80;
        server_name  www.crazylemon.net crazylemon.net;

        root /var/www/crazylemon.net;

        include /etc/nginx/wordpress.conf;
}

接下来让Nginx重新载入配置文件,便可使用WordPress的持久链接了。

  • Share/Bookmark

Tags: , , , , , , , , , , , , , , , , , ,