运维 - 后场思库

Nginx的proxy_pass配置转发路径问题

空心菜发表了文章 0 个评论 4349 次浏览 2015-07-31 01:28 来自相关话题

Nginx配置proxy_pass转发的/路径问题：在nginx中配置proxy_pass时，如果是按照^~匹配路径时,要注意proxy_pass后的url最后的/,当加上了/，相当于是绝对根路径，则nginx不会把location ...查看全部

Nginx配置proxy_pass转发的/路径问题：
在nginx中配置proxy_pass时，如果是按照^~匹配路径时,要注意proxy_pass后的url最后的/,当加上了/，相当于是绝对根路径，则nginx不会把location中匹配的路径部分代理走;如果没有/，则会把匹配的路径部分也给代理走。

location ^~ /proxy_api/ 

   { 

       proxy_cache api_cache; 

       proxy_set_header Host api.afewbug.com; 

       proxy_pass http://api.afewbug.com/; 

   }

如上面的配置，如果请求的url是http://your_domain/proxy_api/load.php 会被代理成http://api.afewbug.com/load.php
如果如下配置：

location ^~ /proxy_api/ 

   { 

       proxy_cache api_cache; 

       proxy_set_header Host api.afewbug.com; 

       proxy_pass http://api.afewbug.com; 

   }

则会被代理到http://api.afewbug.com/proxy_api/load.php

当然，我们可以用如下的rewrite来实现/的功能:

location ^~ /proxy_api/ 

   { 

       proxy_cache api_cache; 

       proxy_set_header Host api.afewbug.com; 

       rewrite /proxy_api/(.+)$ /$1 break; 

       proxy_pass http://api.afewbug.com; 

   }

configure: error: Please reinstall the libcurl distribution - easy.h should be in /include/curl/

贡献

空心菜回复了问题 2 人关注 1 个回复 5093 次浏览 2015-07-28 00:33 来自相关话题

"msg": "Aborting, target uses selinux but python bindings (libselinux-python) aren't installed!"

贡献

空心菜回复了问题 2 人关注 1 个回复 6572 次浏览 2015-07-26 23:56 来自相关话题

Can't find PHP headers in /usr/include/php

贡献

空心菜回复了问题 1 人关注 1 个回复 8813 次浏览 2021-04-11 19:35 来自相关话题

使用线程池NGINX提高9倍性能！

空心菜发表了文章 0 个评论 3448 次浏览 2015-07-26 00:49 来自相关话题

介绍众所周知，nginx使用异步,事件驱动的方法来处理连接。这种处理方式无需（像使用传统架构的服务器一样）为每个请求创建额外的专用进程或者线程，而是在一个工作进程中处理多个连接和请求。为此，NGINX工作在非阻塞的soc ...查看全部

介绍

众所周知，nginx使用异步,事件驱动的方法来处理连接。这种处理方式无需（像使用传统架构的服务器一样）为每个请求创建额外的专用进程或者线程，而是在一个工作进程中处理多个连接和请求。为此，NGINX工作在非阻塞的socket模式下，并使用了epool和 kqueue这样有效的方法。

因为满负载进程的数量很少（通常每核CPU只有一个）而且恒定，所以任务切换只消耗很少的内存，而且不会浪费CPU周期。通过NGINX本身的实例，这种方法的优点已经为众人所知。NGINX可以非常好地处理百万级规模的并发请求。

 每个进程都消耗额外的内存，而且每次进程间的切换都会消耗CPU周期并丢弃CPU高速缓存中的数据。

但是，异步、事件驱动方法仍然存在问题。或者，我喜欢将这一问题称为"恶魔"，这个恶魔的名字叫阻塞（blocking）。不幸的是，很多第三方模块使用了阻塞调用，然而用户（有时甚至是模块的开发者）并不知道阻塞的缺点。阻塞操作可以毁掉NGINX的性能，我们必须不惜一切代价避免使用阻塞。

即使在当前官方的NGINX代码中，依然无法在全部场景中避免使用阻塞，NGINX1.7.11中实现的线程池机制解决了这个问题。我们将在后面讲述这个线程池是什么以及该如何使用。现在，让我们先和我们的"恶魔"进行一次面对面的碰撞。

问题

首先，为了更好地理解这一问题，我们用几句话说明下NGINX是如何工作的。

通常情况下，NGINX是一个事件处理器，即一个接收来自内核的所有连接事件的信息，然后向操作系统发出做什么指令的控制器。实际上，NGINX干了编排操作系统的全部脏活累活，而操作系统做的是读取和发送字节这样的日常工作。所以，对于NGINX来说，快速和及时的响应是非常重要的。

事件可以是超时、socket读写就绪的通知，或者发生错误的通知。NGINX接收大量的事件，然后一个接一个地处理它们，并执行必要的操作。因此，所有的处理过程是通过一个线程中的队列，在一个简单循环中完成的。NGINX从队列中取出一个事件并对其做出响应，比如读写socket。在多数情况下，这种方式是非常快的（也许只需要几个CPU周期，将一些数据复制到内存中），NGINX可以在一瞬间处理掉队列中的所有事件。

但是，如果NGINX要处理的操作是一些又长又重的操作，又会发生什么呢？整个事件处理循环将会卡住，等待这个操作执行完毕。

因此，所谓“阻塞操作”是指任何导致事件处理循环显著停止一段时间的操作。操作可以由于各种原因成为阻塞操作。例如，NGINX可能因长时间、CPU密集型处理，或者可能等待访问某个资源（比如硬盘，或者一个互斥体，亦或要从处于同步方式的数据库获得相应的库函数调用等）而繁忙。关键是在处理这样的操作期间，工作进程无法做其他事情或者处理其他事件，即使有更多的可用系统资源可以被队列中的一些事件所利用。

我们来打个比方，一个商店的营业员要接待他面前排起的一长队顾客。队伍中的第一位顾客想要的某件商品不在店里而在仓库中。这位营业员跑去仓库把东西拿来。现在整个队伍必须为这样的配货方式等待数个小时，队伍中的每个人都很不爽。你可以想见人们的反应吧？队伍中每个人的等待时间都要增加这些时间，除非他们要买的东西就在店里。

在NGINX中会发生几乎同样的情况，比如当读取一个文件的时候，如果该文件没有缓存在内存中，就要从磁盘上读取。从磁盘（特别是旋转式的磁盘）读取是很慢的,而当队列中等待的其他请求可能不需要访问磁盘时，它们也得被迫等待。导致的结果是，延迟增加并且系统资源没有得到充分利用。

一些操作系统为读写文件提供了异步接口，NGINX可以使用这样的接口（见AIO指令）。FreeBSD就是个很好的例子。不幸的是，我们不能在Linux上得到相同的福利。虽然Linux为读取文件提供了一种异步接口，但是存在明显的缺点。其中之一是要求文件访问和缓冲要对齐，但NGINX很好地处理了这个问题。但是，另一个缺点更糟糕。异步接口要求文件描述符中要设置O_DIRECT标记，就是说任何对文件的访问都将绕过内存中的缓存，这增加了磁盘的负载。在很多场景中，这都绝对不是最佳选择。

为了有针对性地解决这一问题，在NGINX 1.7.11中引入了线程池。默认情况下，NGINX+还没有包含线程池，但是如果你想试试的话，可以联系销售，NGINX+ R6是一个已经启用了线程池的构建版本。

下面，让我们走进线程池，看看它是什么以及如何工作的。

线程池

让我们回到那个可怜的，要从大老远的仓库去配货的售货员那儿。这回，他已经变聪明了（或者也许是在一群愤怒的顾客教训了一番之后，他才变得聪明的？），雇用了一个配货服务团队。现在，当任何人要买的东西在大老远的仓库时，他不再亲自去仓库了，只需要将订单丢给配货服务，他们将处理订单，同时，我们的售货员依然可以继续为其他顾客服务。因此，只有那些要买仓库里东西的顾客需要等待配货，其他顾客可以得到即时服务。

对NGINX而言，线程池执行的就是配货服务的功能。它由一个任务队列和一组处理这个队列的线程组成。
当工作进程需要执行一个潜在的长操作时，工作进程不再自己执行这个操作，而是将任务放到线程池队列中，任何空闲的线程都可以从队列中获取并执行这个任务。

那么，这就像我们有了另外一个队列。是这样的，但是在这个场景中，队列受限于特殊的资源。磁盘的读取速度不能比磁盘产生数据的速度快。不管怎么说，至少现在磁盘不再延误其他事件，只有访问文件的请求需要等待。

"从磁盘读取"这个操作通常是阻塞操作最常见的示例，但是实际上，NGINX中实现的线程池可用于处理任何不适合在主循环中执行的任务。

目前，卸载到线程池中执行的两个基本操作是大多数操作系统中的read()系统调用和Linux中的sendfile()。接下来，我们将对线程池进行测试（test）和基准测试（benchmark），在未来的版本中，如果有明显的优势，我们可能会卸载其他操作到线程池中。

基准测试

现在让我们从理论过度到实践。我们将进行一次模拟基准测试（synthetic benchmark），模拟在阻塞操作和非阻塞操作的最差混合条件下，使用线程池的效果。

另外，我们需要一个内存肯定放不下的数据集。在一台48GB内存的机器上，我们已经产生了每文件大小为4MB的随机数据，总共256GB，然后配置NGINX，版本为1.9.0。
配置很简单，如下所示：

worker_processes 16;



events {

    accept_mutex off;

}



http {

    include mime.types;

    default_type application/octet-stream;



    access_log off;

    sendfile on;

    sendfile_max_chunk 512k;



    server {

        listen 8000;



        location / {

            root /storage;

        }

    }

}

如上所示，为了达到更好的性能，我们调整了几个参数：禁用了logging和accept_mutex，同时，启用了sendfile并设置了sendfile_max_chunk的大小。最后一个指令可以减少阻塞调用sendfile()所花费的最长时间，因为NGINX不会尝试一次将整个文件发送出去，而是每次发送大小为512KB的块数据。

这台测试服务器有2个Intel Xeon E5645处理器（共计：12核、24超线程）和10-Gbps的网络接口。磁盘子系统是由4块西部数据WD1003FBYX 磁盘组成的RAID10阵列。所有这些硬件由Ubuntu服务器14.04.1 LTS供电。

  客户端有2台服务器，它们的规格相同。在其中一台上，在wrk中使用Lua脚本创建了负载程序。脚本使用200个并行连接向服务器请求文件，每个请求都可能未命中缓存而从磁盘阻塞读取。我们将这种负载称作随机负载。

  在另一台客户端机器上，我们将运行wrk的另一个副本，使用50个并行连接多次请求同一个文件。因为这个文件将被频繁地访问，所以它会一直驻留在内存中。在正常情况下，NGINX能够非常快速地服务这些请求，但是如果工作进程被其他请求阻塞的话，性能将会下降。我们将这种负载称作恒定负载。

  性能将由服务器上ifstat监测的吞吐率（throughput）和从第二台客户端获取的wrk结果来度量。

  现在,第一次运行没有线程池将不会我们非常激动人心的结果:

% ifstat -bi eth2

eth2

Kbps in  Kbps out

5531.24  1.03e+06

4855.23  812922.7

5994.66  1.07e+06

5476.27  981529.3

6353.62  1.12e+06

5166.17  892770.3

5522.81  978540.8

6208.10  985466.7

6370.79  1.12e+06

6123.33  1.07e+06

如上所示，使用这种配置，服务器产生的总流量约为1Gbps。从下面所示的top输出，我们可以看到，工作进程的大部分时间花在阻塞I/O上（它们处于top的D状态）：

top - 10:40:47 up 11 days,  1:32,  1 user,  load average: 49.61, 45.77 62.89

Tasks: 375 total,  2 running, 373 sleeping,  0 stopped,  0 zombie

%Cpu(s):  0.0 us,  0.3 sy,  0.0 ni, 67.7 id, 31.9 wa,  0.0 hi,  0.0 si,  0.0 st

KiB Mem:  49453440 total, 49149308 used,   304132 free,    98780 buffers

KiB Swap: 10474236 total,    20124 used, 10454112 free, 46903412 cached Mem



  PID USER     PR  NI    VIRT    RES     SHR S  %CPU %MEM    TIME+ COMMAND

 4639 vbart    20   0   47180  28152     496 D   0.7  0.1  0:00.17 nginx

 4632 vbart    20   0   47180  28196     536 D   0.3  0.1  0:00.11 nginx

 4633 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.11 nginx

 4635 vbart    20   0   47180  28136     480 D   0.3  0.1  0:00.12 nginx

 4636 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.14 nginx

 4637 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.10 nginx

 4638 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.12 nginx

 4640 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.13 nginx

 4641 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.13 nginx

 4642 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.11 nginx

 4643 vbart    20   0   47180  28276     536 D   0.3  0.1  0:00.29 nginx

 4644 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.11 nginx

 4645 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.17 nginx

 4646 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.12 nginx

 4647 vbart    20   0   47180  28208     532 D   0.3  0.1  0:00.17 nginx

 4631 vbart    20   0   47180    756     252 S   0.0  0.1  0:00.00 nginx

 4634 vbart    20   0   47180  28208     536 D   0.0  0.1  0:00.11 nginx

 4648 vbart    20   0   25232   1956    1160 R   0.0  0.0  0:00.08 top

25921 vbart    20   0  121956   2232    1056 S   0.0  0.0  0:01.97 sshd

25923 vbart    20   0   40304   4160    2208 S   0.0  0.0  0:00.53 zsh

在这种情况下，吞吐率受限于磁盘子系统，而CPU在大部分时间里是空闲的。从wrk获得的结果也非常低：

Running 1m test @ http://192.0.2.1:8000/1/1/1

  12 threads and 50 connections

  Thread Stats   Avg    Stdev     Max  +/- Stdev

    Latency     7.42s  5.31s   24.41s   74.73%

    Req/Sec     0.15    0.36     1.00    84.62%

  488 requests in 1.01m, 2.01GB read

Requests/sec:      8.08

Transfer/sec:     34.07MB

请记住，文件是从内存送达的！第一个客户端的200个连接创建的随机负载，使服务器端的全部的工作进程忙于从磁盘读取文件，因此产生了过大的延迟，并且无法在合理的时间内处理我们的请求。
现在，我们的线程池要登场了。为此，我们只需在location块中添加aio threads指令：

location / {

    root /storage;

    aio threads;

}

接着，执行NGINX reload重新加载配置。
然后，我们重复上述的测试：

% ifstat -bi eth2

eth2

Kbps in  Kbps out

60915.19  9.51e+06

59978.89  9.51e+06

60122.38  9.51e+06

61179.06  9.51e+06

61798.40  9.51e+06

57072.97  9.50e+06

56072.61  9.51e+06

61279.63  9.51e+06

61243.54  9.51e+06

59632.50  9.50e+06

现在，我们的服务器产生的流量是9.5Gbps，相比之下，没有使用线程池时只有约1Gbps！

理论上还可以产生更多的流量，但是这已经达到了机器的最大网络吞吐能力，所以在这次NGINX的测试中，NGINX受限于网络接口。工作进程的大部分时间只是休眠和等待新的事件（它们处于top的S状态）：

top - 10:43:17 up 11 days,  1:35,  1 user,  load average: 172.71, 93.84, 77.90

Tasks: 376 total,  1 running, 375 sleeping,  0 stopped,  0 zombie

%Cpu(s):  0.2 us,  1.2 sy,  0.0 ni, 34.8 id, 61.5 wa,  0.0 hi,  2.3 si,  0.0 st

KiB Mem:  49453440 total, 49096836 used,   356604 free,    97236 buffers

KiB Swap: 10474236 total,    22860 used, 10451376 free, 46836580 cached Mem



  PID USER     PR  NI    VIRT    RES     SHR S  %CPU %MEM    TIME+ COMMAND

 4654 vbart    20   0  309708  28844     596 S   9.0  0.1  0:08.65 nginx

 4660 vbart    20   0  309748  28920     596 S   6.6  0.1  0:14.82 nginx

 4658 vbart    20   0  309452  28424     520 S   4.3  0.1  0:01.40 nginx

 4663 vbart    20   0  309452  28476     572 S   4.3  0.1  0:01.32 nginx

 4667 vbart    20   0  309584  28712     588 S   3.7  0.1  0:05.19 nginx

 4656 vbart    20   0  309452  28476     572 S   3.3  0.1  0:01.84 nginx

 4664 vbart    20   0  309452  28428     524 S   3.3  0.1  0:01.29 nginx

 4652 vbart    20   0  309452  28476     572 S   3.0  0.1  0:01.46 nginx

 4662 vbart    20   0  309552  28700     596 S   2.7  0.1  0:05.92 nginx

 4661 vbart    20   0  309464  28636     596 S   2.3  0.1  0:01.59 nginx

 4653 vbart    20   0  309452  28476     572 S   1.7  0.1  0:01.70 nginx

 4666 vbart    20   0  309452  28428     524 S   1.3  0.1  0:01.63 nginx

 4657 vbart    20   0  309584  28696     592 S   1.0  0.1  0:00.64 nginx

 4655 vbart    20   0  30958   28476     572 S   0.7  0.1  0:02.81 nginx

 4659 vbart    20   0  309452  28468     564 S   0.3  0.1  0:01.20 nginx

 4665 vbart    20   0  309452  28476     572 S   0.3  0.1  0:00.71 nginx

 5180 vbart    20   0   25232   1952    1156 R   0.0  0.0  0:00.45 top

 4651 vbart    20   0   20032    752     252 S   0.0  0.0  0:00.00 nginx

25921 vbart    20   0  121956   2176    1000 S   0.0  0.0  0:01.98 sshd

25923 vbart    20   0   40304   3840    2208 S   0.0  0.0  0:00.54 zsh

如上所示，基准测试中还有大量的CPU资源剩余。
wrk的结果如下：

Running 1m test @ http://192.0.2.1:8000/1/1/1

  12 threads and 50 connections

  Thread Stats   Avg      Stdev     Max  +/- Stdev

    Latency   226.32ms  392.76ms   1.72s   93.48%

    Req/Sec    20.02     10.84    59.00    65.91%

  15045 requests in 1.00m, 58.86GB read

Requests/sec:    250.57

Transfer/sec:      0.98GB

服务器处理4MB文件的平均时间从7.42秒降到226.32毫秒（减少了33倍），每秒请求处理数提升了31倍（250 vs 8）！

对此，我们的解释是请求不再因为工作进程被阻塞在读文件，而滞留在事件队列中，等待处理，它们可以被空闲的进程处理掉。只要磁盘子系统能做到最好，就能服务好第一个客户端上的随机负载，NGINX可以使用剩余的CPU资源和网络容量，从内存中读取，以服务于上述的第二个客户端的请求。

仍然没有灵丹妙药

在抛出我们对阻塞操作的担忧并给出一些令人振奋的结果后，可能大部分人已经打算在你的服务器上配置线程池了。先别着急。

实际上，最幸运的情况是，读取和发送文件操作不去处理缓慢的硬盘驱动器。如果我们有足够多的内存来存储数据集，那么操作系统将会足够聪明地在被称作“页面缓存”的地方，缓存频繁使用的文件。

"页面缓存"的效果很好，可以让NGINX在几乎所有常见的用例中展示优异的性能。从页面缓存中读取比较快，没有人会说这种操作是“阻塞”。而另一方面，卸载任务到一个线程池是有一定开销的。

因此，如果内存有合理的大小并且待处理的数据集不是很大的话，那么无需使用线程池，NGINX已经工作在最优化的方式下。

卸载读操作到线程池是一种适用于非常特殊任务的技术。只有当经常请求的内容的大小，不适合操作系统的虚拟机缓存时，这种技术才是最有用的。至于可能适用的场景，比如，基于NGINX的高负载流媒体服务器。这正是我们已经模拟的基准测试的场景。

我们如果可以改进卸载读操作到线程池，将会非常有意义。我们只需要知道所需的文件数据是否在内存中，只有不在内存中时，读操作才应该卸载到一个单独的线程中。

再回到售货员那个比喻的场景中，这回，售货员不知道要买的商品是否在店里，他必须要么总是将所有的订单提交给配货服务，要么总是亲自处理它们。

人艰不拆，操作系统缺少这样的功能。第一次尝试是在2010年，人们试图将这一功能添加到Linux作为fincore()系统调用，但是没有成功。后来还有一些尝试，是使用RWF_NONBLOCK标记作为preadv2()系统调用来实现这一功能（详情见LWN.net上的非阻塞缓冲文件读取操作和异步缓冲读操作）。但所有这些补丁的命运目前还不明朗。悲催的是，这些补丁尚没有被内核接受的主要原因，貌似是因为旷日持久的撕逼大战（bikeshedding）。

另一方面，FreeBSD的用户完全不必担心。FreeBSD已经具备足够好的异步读取文件接口，我们应该用这个接口而不是线程池。

配置线程池

所以，如果你确信在你的场景中使用线程池可以带来好处，那么现在是时候深入了解线程池的配置了。

线程池的配置非常简单、灵活。首先，获取NGINX 1.7.11或更高版本的源代码，使用--with-threads配置参数编译。在最简单的场景中，配置看起来很朴实。我们只需要在http、 server，或者location上下文中包含aio threads指令即可：

# in the 'http', 'server', or 'location' context

aio threads;

这是线程池的最简配置。实际上的精简版本示例如下：

# in the 'main' context

thread_pool default threads=32 max_queue=65536;

 

# in the 'http', 'server', or 'location' context

aio threads=default;

这里定义了一个名为"default"，包含32个线程，任务队列最多支持65536个请求的线程池。如果任务队列过载，NGINX将输出如下错误日志并拒绝请求：

thread pool "NAME" queue overflow: N tasks waiting

错误输出意味着线程处理作业的速度有可能低于任务入队的速度了。你可以尝试增加队列的最大值，但是如果这无济于事，那么这说明你的系统没有能力处理如此多的请求了。

正如你已经注意到的，你可以使用thread_pool指令，配置线程的数量、队列的最大值，以及线程池的名称。最后要说明的是，可以配置多个独立的线程池，将它们置于不同的配置文件中，用做不同的目的：

# in the 'main' context

thread_pool one threads=128 max_queue=0;

thread_pool two threads=32;



http {

    server {

        location /one {

            aio threads=one;

        }



        location /two {

            aio threads=two;

        }



    }

    …

}

如果没有指定max_queue参数的值，默认使用的值是65536。如上所示，可以设置max_queue为0。在这种情况下，线程池将使用配置中全部数量的线程，尽可能地同时处理多个任务；队列中不会有等待的任务。

现在，假设我们有一台服务器，挂了3块硬盘，我们希望把该服务器用作“缓存代理”，缓存后端服务器的全部响应信息。预期的缓存数据量远大于可用的内存。它实际上是我们个人CDN的一个缓存节点。毫无疑问，在这种情况下，最重要的事情是发挥硬盘的最大性能。

我们的选择之一是配置一个RAID阵列。这种方法毁誉参半，现在，有了NGINX，我们可以有其他的选择：

# 我们假设每块硬盘挂载在相应的目录中：/mnt/disk1、/mnt/disk2、/mnt/disk3



proxy_cache_path /mnt/disk1 levels=1:2 keys_zone=cache_1:256m max_size=1024G

                 use_temp_path=off;

proxy_cache_path /mnt/disk2 levels=1:2 keys_zone=cache_2:256m max_size=1024G

                 use_temp_path=off;

proxy_cache_path /mnt/disk3 levels=1:2 keys_zone=cache_3:256m max_size=1024G

                 use_temp_path=off;



thread_pool pool_1 threads=16;

thread_pool pool_2 threads=16;

thread_pool pool_3 threads=16;



split_clients $request_uri $disk {

    33.3%     1;

    33.3%     2;

    *         3;

}



location / {

    proxy_pass http://backend;

    proxy_cache_key $request_uri;

    proxy_cache cache_$disk;

    aio threads=pool_$disk;

    sendfile on;

}

在这份配置中，使用了3个独立的缓存，每个缓存专用一块硬盘，另外，3个独立的线程池也各自专用一块硬盘。

缓存之间（其结果就是磁盘之间）的负载均衡使用split_clients模块，split_clients非常适用于这个任务。

在 proxy_cache_path指令中设置use_temp_path=off，表示NGINX会将临时文件保存在缓存数据的同一目录中。这是为了避免在更新缓存时，磁盘之间互相复制响应数据。

这些调优将带给我们磁盘子系统的最大性能，因为NGINX通过单独的线程池并行且独立地与每块磁盘交互。每块磁盘由16个独立线程和读取和发送文件专用任务队列提供服务。

我敢打赌，你的客户喜欢这种量身定制的方法。请确保你的磁盘也持有同样的观点。

这个示例很好地证明了NGINX可以为硬件专门调优的灵活性。这就像你给NGINX下了一道命令，让机器和数据用最佳姿势来搞基。而且，通过NGINX在用户空间中细粒度的调优，我们可以确保软件、操作系统和硬件工作在最优模式下，尽可能有效地利用系统资源。

结论

综上所述，线程池是一个伟大的功能，将NGINX推向了新的性能水平，除掉了一个众所周知的长期危害——阻塞——尤其是当我们真正面对大量内容的时候。

甚至，还有更多的惊喜。正如前面提到的，这个全新的接口，有可能没有任何性能损失地卸载任何长期阻塞操作。NGINX在拥有大量的新模块和新功能方面，开辟了一方新天地。许多流行的库仍然没有提供异步非阻塞接口，此前，这使得它们无法与NGINX兼容。我们可以花大量的时间和资源，去开发我们自己的无阻塞原型库，但这么做始终都是值得的吗？现在，有了线程池，我们可以相对容易地使用这些库，而不会影响这些模块的性能。
原英文地址：Thread Pools in NGINX Boost Performance 9x!

logstash一个坑

空心菜发起了问题 1 人关注 0 个回复 5238 次浏览 2015-07-23 21:54 来自相关话题

探底df和du命令统计磁盘使用结果不一致

OpenSkill 发表了文章 2 个评论 3763 次浏览 2015-07-23 01:42 来自相关话题

现象：最近有一台主机，磁盘不断告警，提示磁盘空间使用大于95%,告警邮件如下图然后我就登陆服务器查看，然后df -h 和du -csh统 ...查看全部

现象：

最近有一台主机，磁盘不断告警，提示磁盘空间使用大于95%,告警邮件如下图

然后我就登陆服务器查看，然后df -h 和du -csh统计结果如下所示：

[root@JAVA_HOST1 /]# df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/vda1        20G   18G  873M  96% /

tmpfs           1.9G     0  1.9G   0% /dev/shm

/dev/vdb        197G  105G   83G  57% /data

[root@JAVA_HOST1 /]# du -csh ./*

6.6M	./bin

41M	    ./boot

4.0K	./boot_ucloud

105G	./data

156K	./dev

26M	    ./etc

4.0K	./home

130M	./lib

21M	    ./lib64

16K	    ./lost+found

4.0K	./media

4.0K	./mnt

24K	    ./opt

du: 无法访问"./proc/3741/task/3741/fd/4": 没有那个文件或目录

du: 无法访问"./proc/3741/task/3741/fdinfo/4": 没有那个文件或目录

du: 无法访问"./proc/3741/fd/4": 没有那个文件或目录

du: 无法访问"./proc/3741/fdinfo/4": 没有那个文件或目录

0	    ./proc

168K	./root

16M	    ./sbin

4.0K	./selinux

4.0K	./srv

513M	./swapfile

0	    ./sys

13M	    ./tmp

982M	./usr

378M	./var

107G	总用量

从du命令统计的结果可以看出，除掉/data分区的105G使用量，/分区的使用大小应该为2G，但是df查看却使用了18G，这明显不正常，那下面让我们来看看到底是为什么？

浅谈原理

du的工作原理
du命令会对待统计文件逐个调用fstat这个系统调用，获取文件大小。它的数据是基于文件获取的，所以有很大的灵活性，不一定非要针对一个分区，可以跨越多个分区操作。如果针对的目录中文件很多，du速度就会很慢了。

df的工作原理
df命令使用的事statfs这个系统调用，直接读取分区的超级块信息获取分区使用情况。它的数据是基于分区元数据的，所以只能针对整个分区。由于df直接读取超级块，所以运行速度不受文件多少影响，所以比较快速。

实验模拟说明

创建并删除文件
创建文件前的磁盘容量情况：

# df -h

文件系统                容量  已用   可用  已用%  挂载点

/dev/sda1              12G  5.7G  5.5G  51%   /

tmpfs                  506M     0  506M   0% /dev/shm

创建文件：

# dd if=/dev/zero of=test.iso bs=1024k count=1000

1000+0 records in

1000+0 records out

1048576000 bytes (1.0 GB) copied, 14.3055 seconds, 73.3 MB/s

现在的磁盘情况：

文件系统                容量  已用   可用   已用%  挂载点

/dev/sda1              12G  6.7G   4.6G  60%   /

tmpfs                  506M     0  506M   0%  /dev/shm

模拟某个进程正在使用该文件：

# tail -f /tmp/test.iso

删除该文件
打开另一个终端，登陆到系统中。查看是否有进程正在使用上面创建的文件：

# lsof |grep test.iso

tail      2175      root    3r      REG        8,1 1048576000     752972 /tmp/test.iso

把该文件删掉，并确认：

# rm /tmp/test.iso

rm：是否删除 一般文件 “/tmp/test.iso”? y

# ls /tmp/test.iso

ls: /tmp/test.iso: 没有那个文件或目录

查看是否还有进程在使用（注意结尾的标记）：

# lsof |grep test.iso

tail      2175      root    3r      REG        8,1 1048576000     752972 /tmp/test.iso (deleted)

查看磁盘使用情况：

# df -h

文件系统                容量  已用  可用   已用%  挂载点

/dev/sda1              12G  6.7G  4.6G  60%   /

tmpfs                 506M     0  506M   0%   /dev/shm

# cat /proc/diskstats |grep sda1

   8    1 sda1 54385 5184 1626626 130090 20434 635997 5251448 5345733 0 111685 5475829

可见，虽然从ls 已经无法找到该文件，但因为tail 进程仍在使用该文件，故实际上内核并没有把这文件所占用的空间释放出来（df 结果和删除文件之前是一样的）。

停止tail进程：
回到第一终端，用Ctrl+C 终止tail 进程，查看结果：

# df -h

文件系统              容量  已用 可用 已用% 挂载点

/dev/sda1              12G  5.7G  5.5G  51% /

tmpfs                 506M     0  506M   0% /dev/shm

# cat /proc/diskstats |grep sda1

   8    1 sda1 54473 5184 1627402 130617 20453 636042 5251960 5345756 0 112226 5476379

至此，文件所占用的空间已完全释放。
实验结果：

1、若有进程在占用某个文件，而其他进程把这文件删掉，只会删除其在磁盘中的标记，而不会释放其占用的磁盘空间；直到所有访问该文件的进程退出为止；

2、df 是从内核中获取磁盘占用情况数据的，而du是统计当前磁盘文件大小的结果，由于磁盘标记已被删掉，因此du 不会计算上述被删除文件的空间，导致df 与 du的结果不一致。

解决问题

1、把占用文件的相关进程关闭
通过下面的命令得到这些已被删除，但未释放空间的文件和进程信息，然后删除

# lsof |grep deleted

找到这些进程后，在安全的情况下把其kill，空间自会马上释放。

# lsof |grep deleted |awk '{print $2}'|xargs -n1 -t kill -9

2、以清空的方式替代删除
归根到底，产生问题的原因是，访问该文件的文件指针（句柄），在rm 动作后，因为进程仍在访问，因此，仍处在文件里面（中间或结尾处）。所以，如果用清空的方式，把文件指针重置，该文件所占用的空间也会马上释放出来。

# echo > /tmp/test.iso

# df -h

文件系统              容量     已用 可用  已用% 挂载点

/dev/sda1              12G  5.7G  5.5G  51% /

tmpfs                 506M     0  506M   0% /dev/shm

# tail -f /tmp/test.iso

tail: /tmp/test.iso: file truncated

所以，对于常发生类似问题的文件，如：日志记录文件等。以改名、清空、删除的顺序操作可避免该问题发生。

教育意义

当出现du和df差距很大的情况时，考虑是否是有删除文件未完成造成的，方法是lsof命令，然后停止相关进程即可。
(2)可以使用清空文件的方式来代替删除文件，方式是:echo > test.iso。
(3)对于经常发生删除问题的日志文件，以改名、清空、删除的顺序操作。
(4)除了rm外，有些命令会间接的删除文件，如gzip命令完成后会删除原来的文件，为了避免删除问题，压缩前先确认没有进程打开该文件。[/code]

文件空洞

  文件读写时，如果先文件指针偏移很大一段，然后写入1byte；这样这个文件实际占用1byte空间，但是stat查看文件大小，或者读写时，都会发现文件很大；所有没有写内容的都返回0，且不占用空间，这样的文件叫 'sparse file'，即文件空洞

  容易发生在一个进程在写一个文件，这是人工进行清空文件操作，就会产生。

pip install greenlet 报错

贡献

OpenSkill 回复了问题 2 人关注 1 个回复 4699 次浏览 2015-07-21 15:52 来自相关话题

Centos安装pip和elasticsearch模块基本使用

OpenSkill 发表了文章 2 个评论 4538 次浏览 2015-07-20 23:21 来自相关话题

CentOS安装python包管理安装工具pip的方法如下： # wget --no-check-certificate https://github.com/pypa/pip/archive/1.5.5.tar.gz # ...查看全部

CentOS安装python包管理安装工具pip的方法如下：

# wget --no-check-certificate https://github.com/pypa/pip/archive/1.5.5.tar.gz

# mv 1.5.5 1.5.5.tar.gz

# tar zxf 1.5.5.tar.gz

# cd pip-1.5.5/

# python setup.py install

验证:

# pip -V

pip 1.5.5 from /usr/lib/python2.6/site-packages/pip-1.5.5-py2.6.egg (python 2.6)

安装elasticsearch模块如下：

# pip install elasticsearch

使用示例如下：

>>> from datetime import datetime

[quote]>> from elasticsearch import Elasticsearch[/quote]



# 默认情况下我们连接 localhost:9200

[quote]>> es = Elasticsearch()[/quote]



# datetimes 将序列化

[quote]>> es.index(index="my-index", doc_type="test-type", id=42, body={"any": "data", "timestamp": datetime.now()})

{u'_id': u'42', u'_index': u'my-index', u'_type': u'test-type', u'_version': 1, u'ok': True}[/quote]



# 但不是反序列化

[quote]>> es.get(index="my-index", doc_type="test-type", id=42)['_source']

{u'any': u'data', u'timestamp': u'2013-05-12T19:45:31.804229'}

[/quote]

通知设置新通知

运维