nginx文档翻译篇之介绍篇

sky

控制nginx
nginx可以通过信号来进行控制。nginx的主进程ID号默认写入/usr/local/nginx/logs/nginx.pid文件，文件名可能在配置阶段、或者在nginx.conf中使用pid指令进行修改。主进程支持以下信号：

• TERM, INT        立即关闭
• QUIT        正常关闭
• HUP        修改配置，保持变更的时区（仅对于FreeBSD和Linux），以新的配置启动新的工作进程，并正常关闭旧的工作进程。
• USR1        重新打开日志文件
• USR2        更新可执行文件
• WINCH        正常关闭工作进程
  

单独的工作进程也能被信号控制，尽管它不是必须的。支持的信号有：

• TERM, INT        立即关闭
• QUIT        正常关闭
• USR1        重新打开日志文件
• WINCH        因调试异常中止 (需要启用debug_points)
  

修改配置文件

为了使nginx重新读取配置文件，要发送HUP信号给主进程。主进程接受到HUP信号后，首先检验语法正确性，然后试着应用新的配置，即打开日志文件和新的监听套接字。如果应用失败，它会回滚到先前的配置。如果应用成功，它会启动新的工作进程，并发送消息给旧的工作进程要求它们正常关闭。旧的工作进程关闭监听的套接字并继续为旧的客户端服务。所有客户端被新的工作进程服务以后，旧的工作进程被关闭。
举个例子，假设nginx在FreeBSD 4.x下运行，执行以下命令：

ps axw -o pid,ppid,user,%cpu,vsz,wchan,command | egrep '(nginx|PID)'

生成以下输出：

PID PPID USER %CPU VSZ WCHAN COMMAND33126 1 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx33127 33126 nobody 0.0 1380 kqread nginx: worker process (nginx)33128 33126 nobody 0.0 1364 kqread nginx: worker process (nginx)33129 33126 nobody 0.0 1364 kqread nginx: worker process (nginx)

编号为33129的旧工作进程仍然继续工作，一段时间后退出：

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 1368 kqread nginx: worker process (nginx)33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)

滚动日志文件

为了滚动日志文件，它们首先需要被重命名，之后将USR1信号发送到主进程。主进程将会重新打开当前已打开的所有日志文件，并标示它们未授权的用户身份（工作进程运行的权限）。在重新打开成功后，主进程关闭所有打开的文件，发送消息给工作进程要求它们重新打开文件。工作进程立即打开新的文件并关闭旧的文件。因此，旧的文件几乎能立即响应post处理，例如压缩。

动态更新可执行文件

为了更新服务器可执行文件，首先需要用新的可执行文件来替代旧的，之后要发送USR2信号给主进程。主进程首先重命名它的进程ID文件到新的文件以.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/nginx36265 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)

在这之后所有的工作进程（新的和旧的）继续接受请求。如果WINCH信号发送到第一个主进程，它将发送消息给它的工作进程，请求它们正常关闭，接着它们将开始退出：

按 Ctrl+C 复制代码
按 Ctrl+C 复制代码

当在Linux下使用“rtsig”方法时，在旧的主进程被发送WINCH信号后，新的进程可能不会接受连接。如果是这样，USR1信号需要同步发送给新的主进程，知道新的进程开始接受连接。

一段时间后，只有新的工作进程将会处理请求：

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/nginx36265 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信号强制它们退出。）当新的主进程退出，旧的主进程可以自动启动新的工作进程。
  

如果新的主进程退出，旧的主进程将会取消进程ID文件的.oldbin后缀。
如果更新成功，应该发送QUIT信号给旧的主进程，只保留新的进程：

PID PPID USER %CPU VSZ WCHAN COMMAND36264 1 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx36265 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支持各种连接处理方法。对于每种特定的方法需要有平台的支持，在支持几种方法的平台下nginx会自动选用最有效的方法。然而，如有需要，可以使用use指令显性指定连接处理方法。
以下的连接处理方法为nginx所支持的：

• select —— 标准方法。在缺少更多高效方法的平台下这个模块是被自动编译的。--with-select_module以及--without-select_module配置参数可以被用来强制启用或禁用对这个模块进行编译。
• poll —— 标准方法。在缺少更多高效方法的平台下这个模块是被自动编译的。--with-poll_module和--without-poll_module配置参数可以被用来强制启用或禁用对这个模块进行编译。
• kqueue —— 用在FreeBSD 4.1+，OpenBSD 2.9+,NetBSD 2.0以及Mac OS X下的高效模块。
• epoll —— 用在Linux 2.6+下的高效模块。
  

一些老的分发版像SuSE 8.2提供添加epoll支持到2.4内核的补丁。

• rtsig —— 实时信号，用在Linux 2.2.19+的高效模块。默认，系统提供的事件队列限制在1024个信号。在负载服务器上可能有必要通过修改/proc/sys/kernel/rtsig-max内核参数来提高这个限制。然而，在Linux 2.66-mm2里这个参数不存在，现在所有进程有它自己的事件队列。每个队列的大小通过RLIMIT_SIGPENDING来指定，并可以通过worker_rlimit_sigpending来改变。
  

队列溢出时，nginx取消队列并回到利用poll连接请求方法直到情况正常为止。

• /dev/poll —— 用在Solaris 77 11/99+,HP/UX 11.22+(eventport),IRIX 6.5.15+以及Tru64 UNIX 5.1A+下的高效模块。
• eventport —— 事件端口，用在Solaris 10下的高效方法。
  

设置hashes
为了快速处理静态数据集例如服务器名称、map指令的值、MIME类型、请求头字符串的名，nginx使用hash表。在启动和每次重新配置过程中nginx选择最小可能的hash表大小例如桶大小可以保存键和相同大小的hash值而不超过配置参数（hash桶大小）。hash表的大小以桶来表示。继续校准直到表大小超过hash最大值参数。大多数hash有对应的指令可以用来改变这些参数，例如，对于服务器名称，它们是server_names_hash_max_size和server_names_hash_bucket_size。

hash桶大小参数指定的大小是处理器cache大小的倍数。在现代处理器中这会减少内存访问次数，从而加快hash键的查找。如果hash桶大小同处理器cache大小相等，那么在最坏的情况下对键的查找中访存次数为2次——第一次计算桶地址，第二次在桶中查询键。因此，如果nginx发出增加hash最大值或hash桶大小的消息，那第一个参数将会被首先增加。

调试日志
要启用调试日志，nginx需要在编译时配置为支持调试：

./configure --with-debug...

接着使用error_log指令设置调试级别：

error_log /path/to/log debug;

Windows下的nginx二进制版本通常被编译为支持调试日志，因此只需要设置调试级别就可以了。

重新定义日志而没有指定调试级别将会禁用调试日志。在下面的例子中，在server级别上重新定义日志会禁用这个服务器的调试日志。

error_log /path/to/log debug;http {server {error_log /path/to/log;...

为了防止这个，可以注释掉重定义日志的那行，或者添加调试级别的说明：

error_log /path/to/log debug;http {server {error_log /path/to/log debug;...

也可以仅为selected_client_addresses启用调试日志：

error_log /path/to/log;events {debug_connection 192.168.1.1;debug_connection 192.168.10.0/24;}

配置文件计量单元
大小可以指定为bytes、kilobytes(后缀为k和K)或者megabytes(后缀为m和M)，例如：“1024”、“8k”或“1M”。
时间间隔可以指定为毫秒、秒、分、时、天等等，使用以下后缀：

• ms        毫秒
• s        秒
• m        分
• h        时
• d        天
• w        周
• M        月，30天
• y        年，365天
  

计量单位可以合并为单个数值，以从大到小的顺序指定，可以选择用空格分割，例如：“1h 30m”也可以指定为“90m”或者“5400s”。没有后缀的值表示秒。推荐使用后缀指定。
一些时间间隔仅可以用秒来指定。

Windows版nginx
Windows版的nginx使用原生的Win32 API(不是采用Cygwin模拟层)。现在只有select()连接处理方法被使用，因此高性能和可扩展性是不被期望的。因为这以及一些其他可知的事情，Windows版本的nginx被认为是beta版。在Windows下nginx的beta版，它几乎提供了UNIX版nginx的所有相同功能，除了XSLT过滤、图像过滤、GeoIP模块和内置的Perl语言。
安装windows下的nginx，下载最新开发版本（1.3.15），因为nginx开发分支包含所有已知的修正。然后解压分发版，进入nginx-1.3.15目录，运行nginx。以下是驱动器C:根目录下的例子：

cd c:\unzip nginx-1.3.15.zipcd nginx-1.3.15start nginx

运行tasklist命令行组件来查看nginx进程：

C:\nginx-1.3.15>tasklist /fi "imagename eq nginx.exe"Image Name           PID Session Name     Session#    Mem Usage=============== ======== ============== ========== ============nginx.exe            652 Console                 0      2 780 Knginx.exe           1332 Console                 0      3 112 K

其中之一为主进程，另外一个是工作进程。如果nginx无法启动，在错误日志文件logs\error.log里查看原因。如果日志文件已经被创建，错误原因在Windows事件日志里查看。如果显示的是错误页面而不是期望的页面，也可以在logs\error.log文件里查看原因。

Windows下nginx使用它运行时的目录作为配置中相对路径的前缀。对于上面的例子，前缀为C:\nginx-1.3.15\。配置文件中路径的指定必须采用UNIX风格，即使用斜杠：

access_log logs/site.log;root C:/web/html;

Windows下nginx以标准控制台程序运行（不是服务），而且可以通过以下命令管理：

• nginx -s stop 立即关闭
• nginx -s quit 正常关闭
• nginx -s reload 修改配置，用新的配置启动新的工作进程，正常关闭旧的工作进程
• nginx -s reopen 重新打开日志文件
  

已知问题

• 尽管可以启动多个工作进程，但是实际只有其中一个工作。
• 一个工作进程可以同时处理不多于1024个连接。
• 需要共享内存支持的cache模块和其他模块在Windows Vista以及更高版本下无法工作，因为在这些Windows版本中启用了地址空间布局随机化。
  

未来可能的改进

• 以服务运行
• 使用I/O完成端口作为连接处理方法
• 在单个工作进程里使用多个工作线程
  

posir

脱了衣服我是禽兽，穿上衣服我是衣冠禽兽!

cxwpf200

所有的男人生来平等，结婚的除外。

快乐的老鼠

读书读到抽筋处，文思方能如尿崩!

ibaobei

如果有一双眼睛陪我一同哭泣，就值得我为生命受苦。

mm111222

我的id是假冒的，大家不要相信我是骗子。

my11502207

学习了，谢谢分享、、、