nginx 静态文件处理能力很强。
静态文件的读取，会损耗IO资源。
要吧考虑把静态文件转移到linux内存中，每次从内存读取资源，效果应该会好很多。
缺点就是：系统重启时，内存文件会自动消失。
不过可以做个shell，在系统重启时，把静态文件拷贝到内存中。
下面开始介绍具体的配置例子。
站点路径：/home/wwwroot/res
站点所对应文件原始存储路径：/opt/web/res
拷贝内存initwebres脚本：
vim /root/.bin/initwebres.sh
代码如下：
#!/bin/bash
res_path="/opt/web/res"
mem_path="/dev/shm/res"
lk_path="/home/wwwroot/res"
if [ ! -d "$mem_path" ]; then
cp -r "$res_path" "$mem_path"
fi
if [ ! -L "$lk_path" ]; then
ln -s "$mem_path" "$lk_path"
fi
配置脚本自启动。假设bash路径/bin/bash，然后在/etc/rc.local末尾添加：
说明：
更新网站静态文件时，切记要更新内存/dev/shm/中的相应文件哦！
注意，/dev/shm默认为内存大小的一半。
有兴趣的朋友，可以在本地配置一个虚拟站点，用上面的方法测试下，看看用linux内存加速静态文件的效果如何？！
比如，doucument_root下没有test.php，访问此文件时通过抓包可以看到返回的内容。
Date: Fri, 21 Dec 2012 08:15:28 GMT
Content-Type: text/html
Proxy-Connection: close
Server: nginx/1.2.5
X-Powered-By: PHP/5.4.7
Via: 1.1 c3300 (NetCache NetApp/6.0.7)
Content-Length: 16
File not found.
不希望用户看到这个默认的404错误信息，想自定义404错误。
先来了解下这种404错误是如何产生的，以及显示自定义的404错误页的方法。
一、错误的路径被发送到php-fpm进程
出现这类错误，大多是后端fastcgi进程收到错误路径(SCRIPT_FILENAME)，而后端fastcgi收到错误路径的原因大都是配置错误。
常见的nginx.conf的配置：
server {
listen [::]:80;
server_name example.com www.example.com;
access_log /var/www/logs/example.com.access.log;
location / {
root /var/www/example.com;
index index.html index.htm index.pl;
}
location /images {
autoindex on;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/example.com$fastcgi_script_name;
include fastcgi_params;
}
}
以上配置的问题分析：
root指令被放到了location / 块。如果root指令被定义在location块中那么该root指令只能对其所在的location生效。其它locaiont中没有root指令，像location /images块不会匹配任何请求，需要在每个请求中重复配置root指令来解决这个问题。因此我们需要把root指令放在server块，这样各个location就会继承父server块定义的$document_root，如果某个location需要定义一个不同的$document_root，则可以在location单独定义一个root指令。
问题2，fastCGI参数SCRIPT_FILENAME 是写死的。如果修改了root指令的值或者移动文件到别的目录，php-fpm会返回“No input file specified”错误，因为SCRIPT_FILENAME在配置中是写死的并没有随着$doucument_root变化而变化。
可以修改SCRIPT_FILENAME配置如下：
因此，不要忘记在server块中配置root指令，不然$document_root的值为空，只会传$fastcgi_script_name到php-fpm，就会导致“No input file specified”错误。
二、请求的文件物理上不存在
当nginx收到一个不在的.php文件的请求时，因为nginx只会检查$uri是否是.php结尾，不会对文件是否存在进行判断，.php结尾的请求nginx会直接发给php-fpm处理。php-fpm处理时找不到文件就会返回“No input file specified”带着“404 Not Found”头。
解决办法：
在nginx拦截不存在的文件，请求并返回自定义404错误
使用 try_files 捕捉不存在的urls并返回错误。
try_files $uri =404;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME ....
...................................
...................................
}
上面的配置会检查.php文件是否存在，如果不存在，会返回404页面。
就介绍这些吧，有关nginx 404错误的内容，建议大家熟练掌握，结合404自定义错误页，实现友好的错误提示吧。
第一步，重命名日志文件，不用担心重命名后nginx找不到日志文件而丢失日志。
未重新打开原名字的日志文件前，nginx还是会向你重命名的文件写日志，linux是靠文件描述符而不是文件名定位文件。
第二步，向nginx主进程发送USR1信号。
nginx主进程接到信号后会从配置文件中读取日志文件名称，重新打开日志文件(以配置文件中的日志名称命名)，并以工作进程的用户作为日志文件的所有者。
重新打开日志文件后，nginx主进程会关闭重名的日志文件并通知工作进程使用新打开的日志文件。
工作进程立刻打开新的日志文件并关闭重名名的日志文件。
然后你就可以处理旧的日志文件了。
nginx日志按日期自动切割脚本。
#nginx日志切割脚本
#author: http://www.
#!/bin/bash
#设置日志文件存放目录
logs_path="/usr/local/nginx/logs/"
#设置pid文件
pid_path="/usr/local/nginx/nginx.pid"
#重命名日志文件
mv ${logs_path}access.log ${logs_path}access_$(date -d "yesterday" +"%Y%m%d").log
#向nginx主进程发信号重新打开日志
kill -USR1 `cat ${pid_path}`
保存以上脚本nginx_log.sh。
crontab 设置作业
每天的0点0分把nginx日志重命名为日期格式，并重新生成今天的新日志文件。