使用线程池NGINX提高9倍性能！
介绍
众所周知，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;如上所示，为了达到更好的性能，我们调整了几个参数：禁用了logging和accept_mutex，同时，启用了sendfile并设置了sendfile_max_chunk的大小。最后一个指令可以减少阻塞调用sendfile()所花费的最长时间，因为NGINX不会尝试一次将整个文件发送出去，而是每次发送大小为512KB的块数据。
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;
}
}
}
这台测试服务器有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如上所示，使用这种配置，服务器产生的总流量约为1Gbps。从下面所示的top输出，我们可以看到，工作进程的大部分时间花在阻塞I/O上（它们处于top的D状态）：
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
top - 10:40:47 up 11 days, 1:32, 1 user, load average: 49.61, 45.77 62.89在这种情况下，吞吐率受限于磁盘子系统，而CPU在大部分时间里是空闲的。从wrk获得的结果也非常低：
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
Running 1m test @ http://192.0.2.1:8000/1/1/1请记住，文件是从内存送达的！第一个客户端的200个连接创建的随机负载，使服务器端的全部的工作进程忙于从磁盘读取文件，因此产生了过大的延迟，并且无法在合理的时间内处理我们的请求。
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
现在，我们的线程池要登场了。为此，我们只需在location块中添加aio threads指令：
location / {
root /storage;
aio threads;
} 接着，执行NGINX reload重新加载配置。然后，我们重复上述的测试：
% ifstat -bi eth2现在，我们的服务器产生的流量是9.5Gbps，相比之下，没有使用线程池时只有约1Gbps！
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
理论上还可以产生更多的流量，但是这已经达到了机器的最大网络吞吐能力，所以在这次NGINX的测试中，NGINX受限于网络接口。工作进程的大部分时间只是休眠和等待新的事件（它们处于top的S状态）：
top - 10:43:17 up 11 days, 1:35, 1 user, load average: 172.71, 93.84, 77.90如上所示，基准测试中还有大量的CPU资源剩余。
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
wrk的结果如下：
Running 1m test @ http://192.0.2.1:8000/1/1/1服务器处理4MB文件的平均时间从7.42秒降到226.32毫秒（减少了33倍），每秒请求处理数提升了31倍（250 vs 8）！
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
对此，我们的解释是请求不再因为工作进程被阻塞在读文件，而滞留在事件队列中，等待处理，它们可以被空闲的进程处理掉。只要磁盘子系统能做到最好，就能服务好第一个客户端上的随机负载，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这里定义了一个名为"default"，包含32个线程，任务队列最多支持65536个请求的线程池。如果任务队列过载，NGINX将输出如下错误日志并拒绝请求：
thread_pool default threads=32 max_queue=65536;
# in the 'http', 'server', or 'location' context
aio threads=default;
thread pool "NAME" queue overflow: N tasks waiting错误输出意味着线程处理作业的速度有可能低于任务入队的速度了。你可以尝试增加队列的最大值，但是如果这无济于事，那么这说明你的系统没有能力处理如此多的请求了。
正如你已经注意到的，你可以使用thread_pool指令，配置线程的数量、队列的最大值，以及线程池的名称。最后要说明的是，可以配置多个独立的线程池，将它们置于不同的配置文件中，用做不同的目的：
# in the 'main' context如果没有指定max_queue参数的值，默认使用的值是65536。如上所示，可以设置max_queue为0。在这种情况下，线程池将使用配置中全部数量的线程，尽可能地同时处理多个任务；队列中不会有等待的任务。
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;
}
}
…
}
现在，假设我们有一台服务器，挂了3块硬盘，我们希望把该服务器用作“缓存代理”，缓存后端服务器的全部响应信息。预期的缓存数据量远大于可用的内存。它实际上是我们个人CDN的一个缓存节点。毫无疑问，在这种情况下，最重要的事情是发挥硬盘的最大性能。
我们的选择之一是配置一个RAID阵列。这种方法毁誉参半，现在，有了NGINX，我们可以有其他的选择：
# 我们假设每块硬盘挂载在相应的目录中：/mnt/disk1、/mnt/disk2、/mnt/disk3在这份配置中，使用了3个独立的缓存，每个缓存专用一块硬盘，另外，3个独立的线程池也各自专用一块硬盘。
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;
}
缓存之间（其结果就是磁盘之间）的负载均衡使用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! 收起阅读 »
探底df和du命令统计磁盘使用结果不一致
现象：
最近有一台主机，磁盘不断告警，提示磁盘空间使用大于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 ./*从du命令统计的结果可以看出，除掉/data分区的105G使用量，/分区的使用大小应该为2G，但是df查看却使用了18G，这明显不正常，那下面让我们来看看到底是为什么？
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的工作原理
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可见，虽然从ls 已经无法找到该文件，但因为tail 进程仍在使用该文件，故实际上内核并没有把这文件所占用的空间释放出来（df 结果和删除文件之前是一样的）。
文件系统 容量 已用 可用 已用% 挂载点
/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
停止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'，即文件空洞收起阅读 »
容易发生在一个进程在写一个文件，这是人工进行清空文件操作，就会产生。
Centos安装pip和elasticsearch模块基本使用
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] 收起阅读 »
[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'}
Linux系统安装后的基础优化-基于CentOS（5.8/6.4）
在运维工作中，我们发现Linux系统安装之后并不能立即投入生产环境使用，往往需要先经过我们运维人员的优化才行。
下面我就为大家简单讲解几点关于Linux系统安装后的基础优化操作。
注意：本次优化都是基于CentOS（5.8/6.4）。关于5.8和6.4两者优化时的小区别，我会在文中提及的。
优化条目：
修改ip地址、网关、主机名、DNS等
关闭selinux，清空iptables
添加普通用户并进行sudo授权管理
更新yum源及必要软件安装
定时自动更新服务器时间
精简开机自启动服务
定时自动清理/var/spool/clientmqueue/目录垃圾文件，防止inode节点被占满
变更默认的ssh服务端口，禁止root用户远程连接
锁定关键文件系统
调整文件描述符大小
调整字符集，使其支持中文
去除系统及内核版本登录前的屏幕显示
内核参数优化
1、修改ip地址、网关、主机名、DNS等
[root@localhost ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0 #网卡名字
BOOTPROTO=static #静态IP地址获取状态 如：DHCP表示自动获取IP地址
IPADDR=192.168.1.113 #IP地址
NETMASK=255.255.255.0 #子网掩码
ONBOOT=yes #引导时是否激活
GATEWAY=192.168.1.1
[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.1.113
NETMASK=255.255.255.0
ONBOOT=yes
GATEWAY=192.168.1.1
[root@localhost ~]# vi /etc/sysconfig/network
HOSTNAME=c64 #修改主机名，重启生效
GATEWAY=192.168.1.1 #修改默认网关,如果上面eth0里面不配置网关的话，默认就使用这里的网关了。
[root@localhost ~]# cat /etc/sysconfig/network
HOSTNAME=c64
GATEWAY=192.168.1.1
我们也可以用 hostname c64 来临时修改主机名，重新登录生效
[root@localhost ~]# vi /etc/resolv.conf #修改DNS信息
nameserver 114.114.114.114
nameserver 8.8.8.8
[root@localhost ~]# cat /etc/resolv.conf #查看修改后的DNS信息
nameserver 114.114.114.114
nameserver 202.106.0.20
[root@localhost ~]# service network restart #重启网卡，生效
重启网卡，也可以用下面的命令
[root@localhost ~]# /etc/init.d/network restart
2、关闭selinux，清空iptables
关闭selinux
[root@c64 ~]# sed –i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config #修改配置文件则永久生效，但是必须要重启系统。
[root@c64 ~]# grep SELINUX=disabled /etc/selinux/config
SELINUX=disabled #查看更改后的结果
[root@c64 ~]# setenforce 0 #临时生效命令
[root@c64 ~]# getenforce #查看selinux当前状态
Permissive
清空iptables
[root@c64 ~]# iptables –F #清理防火墙规则
[root@c64 ~]# iptables –L #查看防火墙规则
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@c64 ~]#/etc/init.d/iptables save #保存防火墙配置信息
[root@c64 ~]#service iptables off #开机不自动启动
3、添加普通用户并进行sudo授权管理
[root@c64 ~]# useradd sunsky
[root@c64 ~]# echo "123456"|passwd --stdin sunsky && history –c
[root@c64 ~]# visudo
在root ALL=(ALL) ALL 此行下，添加如下内容
sunsky ALL=(ALL) ALL
4、更新yum源及必要软件安装
yum安装软件，默认获取rpm包的途径从国外官方源，改成国内的源。
国内较快的两个站点：搜狐镜像站点 、网易镜像站点
法1：自己配置好安装源配置文件，然后上传到linux。
法2：使用镜像站点配置好的yum安装源配置文件
[root@c64 ~]# cd /etc/yum.repos.d/
[root@c64 yum.repos.d]# /bin/mv CentOS-Base.repo CentOS-Base.repo.bak
[root@c64 yum.repos.d]# wget http://mirrors.163.com/.help/CentOS6-Base-163.repo
接下来执行如下命令，检测yum是否正常
[root@c64 yum.repos.d]# yum clean all #清空yum缓存
[root@c64 yum.repos.d]# yum makecache #建立yum缓存
然后使用如下命令将系统更新到最新
[root@c64 yum.repos.d]# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY* #导入签名KEY到RPM
[root@c64 yum.repos.d]# yum upgrade -y #更新系统内核到最新
接下来就要安装几个必要的软件了
[root@c64 yum.repos.d]# yum install lrzsz ntpdate sysstat -y
lrzsz是一个上传下载的软件
ntpdate是用来与远程时间服务器进行时间更新的软件
sysstat是用来检测系统性能及效率的工具
5、定时自动更新服务器时间
提示：CentOS 6.4的时间同步命令路径不一样, 6是/usr/sbin/ntpdate, 5是/sbin/ntpdate
扩展：在机器数量少时，以上定时任务同步时间就可以了。如果机器数量大时，可以在网内另外部署一台时间同步服务器NTP Server。此处仅提及，不做部署。
时间同步服务器架构图：
6、精简开机自启动服务
刚装完操作系统可以只保留crond，network，syslog，sshd这四个服务。（Centos6.4为rsyslog）
[root@c64 ~]# for sun in `chkconfig --list|grep 3:on|awk '{print $1}'`;do chkconfig --level 3 $sun off;done
[root@c64 ~]# for sun in crond rsyslog sshd network;do chkconfig --level 3 $sun on;done
[root@c64 ~]# chkconfig --list|grep 3:on
crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
7、定时自动清理/var/spool/clientmqueue/目录垃圾文件，防止inode节点被占满
本优化点，在6.4上可以忽略不需要操作即可！
[root@c64 ~]# mkdir /server/scripts -p
[root@c64 ~]# vi /server/scripts/spool_clean.sh
#!/bin/sh
find /var/spool/clientmqueue/ -type f -mtime +30|xargs rm -f
然后将其加入到crontab定时任务中
[root@c64 ~]# echo '/30 * /bin/sh /server/scripts/spool_clean.sh >/dev/null 2>&1' >>/var/spool/cron/root
8、变更默认的ssh服务端口，禁止root用户远程连接
[root@c64 ~]# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
[root@c64 ~]# vim /etc/ssh/sshd_config
Port 52113 #ssh连接默认的端口
PermitRootLogin no #root用户黑客都知道，禁止它远程登录
PermitEmptyPasswords no #禁止空密码登录
UseDNS no #不使用DNS
[root@c64 ~]# /etc/init.d/sshd reload #从新加载配置
[root@c64 ~]# netstat -lnt #查看端口信息
[root@c64 ~]# lsof -i tcp:52113
9、锁定关键文件系统
[root@c64 ~]# chattr +i /etc/passwd
[root@c64 ~]# chattr +i /etc/inittab
[root@c64 ~]# chattr +i /etc/group
[root@c64 ~]# chattr +i /etc/shadow
[root@c64 ~]# chattr +i /etc/gshadow
使用chattr命令后，为了安全我们需要将其改名
[root@c64 ~]# /bin/mv /usr/bin/chattr /usr/bin/任意名称
10、调整文件描述符大小
[root@localhost ~]# ulimit –n #查看文件描述符大小
1024
[root@localhost ~]# echo '* - nofile 65535' >> /etc/security/limits.conf
配置完成后，重新登录即可查看。
提示：也可以把ulimit -SHn 65535命令加入到/etc/rc.local，然后每次重启生效
[root@c64 ~]# cat >>/etc/rc.local<<EOF
#open files
ulimit -HSn 65535
#stack size
ulimit -s 65535
EOF
扩展：文件描述符
文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于Unix、Linux这样的操作系统。
习惯上，标准输入（standard input）的文件描述符是 0，标准输出（standard output）是 1，标准错误（standard error）是 2。尽管这种习惯并非Unix内核的特性，但是因为一些 shell 和很多应用程序都使用这种习惯，因此，如果内核不遵循这种习惯的话，很多应用程序将不能使用。
11、调整字符集，使其支持中文
sed -i 's#LANG="en_US.UTF-8"#LANG="zh_CN.GB18030"#' /etc/sysconfig/i18n
source /etc/sysconfig/i18n
扩展：什么是字符集？
简单的说就是一套文字符号及其编码。常用的字符集有：
GBK 定长双字节不是国际标准，支持系统不少
UTF-8 非定长 1-4字节广泛支持，MYSQL也使用UTF-8
12、去除系统及内核版本登录前的屏幕显示
[root@c64 ~]# >/etc/redhat-release
[root@c64 ~]# >/etc/issue
13、内核参数优化
说明：本优化适合apache，nginx，squid多种等web应用，特殊的业务也可能需要略作调整。
[root@c64 ~]# vi /etc/sysctl.conf
#by sun in 20131001
net.ipv4.tcp_fin_timeout = 2
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_keepalive_time =600
net.ipv4.ip_local_port_range = 4000 65000
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_max_tw_buckets = 36000
net.ipv4.route.gc_timeout = 100
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1
net.core.somaxconn = 16384
net.core.netdev_max_backlog = 16384
net.ipv4.tcp_max_orphans = 16384
#一下参数是对iptables防火墙的优化，防火墙不开会有提示，可以忽略不理。
net.ipv4.ip_conntrack_max = 25000000
net.ipv4.netfilter.ip_conntrack_max = 25000000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 180
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
[root@localhost ~]# sysctl –p #使配置文件生效
提示：由于CentOS6.X系统中的模块名不是ip_conntrack，而是nf_conntrack，所以在/etc/sysctl.conf优化时，需要把net.ipv4.netfilter.ip_conntrack_max 这种老的参数，改成net.netfilter.nf_conntrack_max这样才可以。
即对防火墙的优化，在5.8上是:
net.ipv4.ip_conntrack_max = 25000000
net.ipv4.netfilter.ip_conntrack_max = 25000000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 180
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
在6.4上是
net.nf_conntrack_max = 25000000
net.netfilter.nf_conntrack_max = 25000000
net.netfilter.nf_conntrack_tcp_timeout_established = 180
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
- 5.8版本:
这个错误可能是你的防火墙没有开启或者自动处理可载入的模块ip_conntrack没有自动载入，解决办法有二，一是开启防火墙，二是自动处理开载入的模块ip_conntrackerror: "net.ipv4.ip_conntrack_max" is an unknown key
error: "net.ipv4.netfilter.ip_conntrack_max" is an unknown key
error: "net.ipv4.netfilter.ip_conntrack_tcp_timeout_established" is an unknown key
error: "net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait" is an unknown key
error: "net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait" is an unknown key
error: "net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait" is an unknown key
modprobe ip_conntrack
echo "modprobe ip_conntrack" >> /etc/rc.local
- 6.4版本上
这个错误可能是你的防火墙没有开启或者自动处理可载入的模块ip_conntrack没有自动载入，解决办法有二，一是开启防火墙，二是自动处理开载入的模块ip_conntrackerror: "net.nf_conntrack_max" is an unknown key
error: "net.netfilter.nf_conntrack_max" is an unknown key
error: "net.netfilter.nf_conntrack_tcp_timeout_established" is an unknown key
error: "net.netfilter.nf_conntrack_tcp_timeout_time_wait" is an unknown key
error: "net.netfilter.nf_conntrack_tcp_timeout_close_wait" is an unknown key
error: "net.netfilter.nf_conntrack_tcp_timeout_fin_wait" is an unknown key
modprobe nf_conntrack
echo "modprobe nf_conntrack" >> /etc/rc.local
- 6.4版本上
这个错误是由于自动处理可载入的模块bridge没有自动载入，解决办法是自动处理开载入的模块ip_conntrackerror: "net.bridge.bridge-nf-call-ip6tables" is an unknown key
error: "net.bridge.bridge-nf-call-iptables" is an unknown key
error: "net.bridge.bridge-nf-call-arptables" is an unknown key
modprobe bridge
echo "modprobe bridge" >> /etc/rc.local
PV、UV、IP概念
PV是网站分析的一个术语，用以衡量网站用户访问的网页的数量。对于广告主，PV值可预期它可以带来多少广告收入。一般来说，PV与来访者的数量成正比，但是PV并不直接决定页面的真实来访者数量，如同一个来访者通过不断的刷新页面，也可以制造出非常高的PV。
1、什么是PV
PV（page view） 即页面浏览量或点击量，是衡量一个网站或网页用户访问量。具体的说，PV值就是所有访问者在24小时（0点到24点）内看了某个网站多少个页面或某个网页多少次。PV是指页面刷新的次数，每一次页面刷新，就算做一次PV流量。
度量方法就是从浏览器发出一个对网络服务器的请求（Request），网络服务器接到这个请求后，会将该请求对应的一个网页（Page）发送给浏览器，从而产生了一个PV。那么在这里只要是这个请求发送给了浏览器，无论这个页面是否完全打开（下载完成），那么都是应当计为1个PV。
2、什么是UV
UV（unique visitor）即独立访客数，指访问某个站点或点击某个网页的不同IP地址的人数。在同一天内，UV只记录第一次进入网站的具有独立IP的访问者，在同一天内再次访问该网站则不计数。UV提供了一定时间内不同观众数量的统计指标，而没有反应出网站的全面活动。通过IP和cookie是判断UV值的两种方式： 用Cookie分析UV值
当客户端第一次访问某个网站服务器的时候，网站服务器会给这个客户端的电脑发出一个Cookie，通常放在这个客户端电脑的C盘当中。在这个Cookie中会分配一个独一无二的编号，这其中会记录一些访问服务器的信息，如访问时间，访问了哪些页面等等。当你下次再访问这个服务器的时候，服务器就可以直接从你的电脑中找到上一次放进去的Cookie文件，并且对其进行一些更新，但那个独一无二的编号是不会变的。
3、IP即独立IP数
IP可以理解为独立IP的访问用户，指1天内使用不同IP地址的用户访问网站的数量，同一IP无论访问了几个页面，独立IP数均为1。但是假如说两台机器访问而使用的是同一个IP，那么只能算是一个IP的访问。
IP和UV之间的数据不会有太大的差异，通常UV量和比IP量高出一点，每个UV相对于每个IP更准确地对应一个实际的浏览者。
4、三者直接的关系
IP和PV之间的关系：
PV是和IP的数量是成正比的，因为页面被刷新一次那么PV就会被记录一次，所以IP越多，说明网站的PV数据也就随之增多。但是需要注意的是PV并不是网站的页面的访问者数量，而是网站被访问的页面数量。因为一个访问者可以多次刷新页面，增加PV数量。
IP和UV之间的关系：
在记录网站流量统计数据时，站长们有时候发现这样一种情况：有时候网站的IP数据大于UV数据，有时候UV的数据也会大于IP数据。
为什么会出现这种现象呢?我们可以用一个例子来说明。比如，用同一个IP去访问我们的SEO网站，但是一个是用的台式的电脑，一个是用的笔记本，那么网站流量统计工具显示的数据就会是2个UV，1个IP。
这时UV的数据就会大于IP的数据。但是，再比如，只是用一个台式电脑访问我们的SEO网站，但是一会拨一个号换一个IP，那么这时候网站流量统计工具显示的数据的UV就为1，但是IP的数据就会高于UV的数据。因此，IP和UV之间的数据并不一定存在比例关系，两者之间的数据也不是此消彼长的关系。SEO童鞋们千万不要弄混淆了。
IP和PV之间的关系：
那么IP和PV的关系如何呢?如果一个IP刷新了网站1000次，网站的PV就为1000，所以从这点看二者之间没有多大关系。但是，我们可以通过IP和PV之间的数据差异，来更加深入的理解网站的流量数据。如果IP和PV的数据悬殊很大，比如，我们在查看网站流量数据时发现网站的PV是1000,IP为100，那么说明这个站点平均一个IP访问了网站内容10次，说明网站内容还是比较受欢迎的，所以访客才愿意在网站中停留那么久的时间，并浏览了那么多的网站页面内容。
但是如果IP和PV的数据很接近，比如，网站的IP为100，PV为110，说明一个IP也就访问了网站内容大约1次，就说明网站内容的可读性太差，客户点击进去之后就离开了，没有有过多的停留。如果网站流量统计这样的数据过多的话，站长就需要对网站内容进行深入思考了，以便更好的提高网站的流量。
以上内容总结：
①UV大于IP :
这种情况就是在网吧、学校、公司等，公用相同IP的场所中不同的用户，或者多种不同浏览器访问您网站，那么UV数会大于IP数。
②UV小于IP :
收起阅读 »
在家庭中大多数电脑使用ADSL拨号上网，所以同一个用户在家里不同时间访问您网站时，IP可能会不同，因为它会根据时间变动IP，即动态的IP地址，但是实际访客数唯一，便会出现UV数小于IP数。
Web服务器Tengine内核参数优化
内核参数的优化，主要是在Linux系统中针对Tengine应用而进行的系统内核参数优化，以下是我的优化例子：
net.ipv4.tcp_max_tw_buckets = 6000参数选项的含义介绍：
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse =1
net.ipv4.tcp_syncookies = 1
net.core.somaxconn = 262144
net.core.netdev_max_backlog = 262144
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_max_tw_buckets 选项用来设定timewait的数量，默认是180 000，这里设置为6000收起阅读 »
net.ipv4.ip_local_port_range 选项用来设定允许系统打开的端口范围
net.ipv4.tcp_tw_recycle 选项用于设置启用timewait的快速回收
net.ipv4.tcp_tw_reuse 选项用于设置开启重用，允许将TIME-WAIT sockets重新用于新的TCP连接
net.ipv4.tcp_syncookies 选项用于设置开启SYN Cookies，当出现SYN等待队列溢出时，启用cookies进行处理
net.core.somaxconn 选项的默认值是128，这个参数用于调节系统同时发起的tcp连接数，在高并发的请求中，默认的值可能会导致链接超时或者重传，因此，需要结合并发请求数来调节此值
net.core.netdev_max_backlog 选项表示当每个网络接口数据包的速率比内核处理这些包的速率快时，允许发送到队列的数据包的最大数目
net.ipv4.tcp_max_orphans 选项用于设定系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，孤立连接将立即被复位炳打印出警告信息。这个限制只是为了防止简单的DOS攻击。不能过分依靠这个限制甚至人为减小这个值，更多的情况下应该增加这个值
net.ipv4.tcp_max_syn_backlog 选项用于记录那些尚未收到客户端确认信息的连接请求的最大值。对于有128MB内存的系统而言，此参数的默认值是1024，对小内存的系统则是128
net.ipv4.tcp_synack_retries 参数的值决定了内核放弃连接之前发送SYN+ACK包的数量
net.ipv4.tcp_syn_retries 选项表示在内核放弃建立连接之前发送SYN包的数量。如果发送端要求关闭套接字，net.ipv4.tcp_fin_timeout选项决定了套接字保持在FIN-WAIT-2状态的时间。接收端可以出错并永远不关闭连接，甚至以外宕机
net.ipv4.tcp_fin_timeout 的默认值是60秒。需要注意的是，即使一个负载很小的Web服务器，也会出现因为大量的死套接字而产生内存溢出的风险。FIN-WAIT-2的危险比FIN-WAIT-1要小，因为它最多只能消耗1.5KB的内存，但是其生存期长些
net.ipv4.tcp_keepalive_time 选项表示当keeplive启用的时候，TCP发送keepalive消息的频度。默认值是2（单位是小时）
高并发linux生产服务器内核参数优化
说明：本优化案例适合apache,nginx,squid多种等web应用，特殊的业务可以做调整
参数解释参考：http://yangrong.blog.51cto.com/6945369/1321594 收起阅读 »
所谓内核优化，主要是在Linux系统中针对业务服务应用而进行的系统内核参数优化，优化并无特殊的标准，下面以常见生产环境linux的内核优化为例讲解，仅供大家参考，欢迎拍砖。
net.ipv4.tcp_fin_timeout = 2将上面的内核参数值加入/etc/sysctl.conf文件中，然后执行如下命令使之生效：sysctl -p
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_keepalive_time = 600
net.ipv4.ip_local_port_range = 400065000
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_max_tw_buckets = 36000
net.ipv4.route.gc_timeout = 100
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1
net.core.somaxconn = 16384
net.core.netdev_max_backlog = 16384
net.ipv4.tcp_max_orphans = 16384
#以下参数是对iptables防火墙的优化，防火墙不开会提示，可以忽略不理。
net.ipv4.ip_conntrack_max = 25000000
net.ipv4.netfilter.ip_conntrack_max=25000000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=180
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait=120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait=60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait=120
参数解释参考：http://yangrong.blog.51cto.com/6945369/1321594 收起阅读 »
部署使用varnish
节点：192.168.83.46 部署了LAMP+nagios监控系统开发80端口
节点：192.168.83.47 部署varnish做46的缓存
部署varnish
1. 设置好依赖目录
[root:~ Slave] # useradd -s /sbin/nologin varnish
[root:~ Slave] # mkdir /data/varnish/cache
[root:~ Slave] # mkdir /data/varnish/cache
[root:~ Slave] # mkdir /data/varnish/log
[root:~ Slave] # chown -R varnish:varnish /data/varnish/cache
[root:~ Slave] # chown -R varnish:varnish /data/varnish/log
Varnish的官方网址为: http://varnish-cache.org, 可以在这里下载最新版本的软件。在安装Varnish前需要安装PCRE库。如果没有安装该库，在Varnish2以上版本编译时，就会提示找不到PCRE库PCRE库则可以兼容正则表达式，所以必须先安装。下面介绍其安装过程。
2. pcre编译安装
[root:/opt/varnish Slave] # tar -zxvf pcre-8.00.tar.gz
[root:/opt/varnish Slave] # cd pcre-8.00
[root:/opt/varnish/pcre-8.00 Slave] # ./configure --prefix=/usr/local/pcre/
[root:/opt/varnish/pcre-8.00 Slave] # make && make install
3. varnish编译安装
[root:/opt/varnish Slave] # tar -zxvf varnish-2.0.6.tar.gz
[root:/opt/varnish Slave] # export PKG_CONFIG_PATH=/app/soft/varnish/lib/pkgconfig/ 这一行一定要有，不然在编译的时候会报错。这行用于指定Varnish 查找PCRE库的路径，如果PCRE安装到其他路径下，在这里指定即可，Varnish默认查找PCRE库的路径为usr/local/lib/pkgconfig。
[root:/opt/varnish/varnish-2.0.6 Slave] # ./configure -prefix=/app/soft/varnish -enable-debugging-symbols -enable-developer-warnings -enable-dependency-tracking
[root:/opt/varnish/varnish-2.0.6 Slave] # make
[root:/opt/varnish/varnish-2.0.6 Slave] # make install
[root:/opt/varnish/varnish-2.0.6 Slave] # cp redhat/varnish.initrc /etc/init.d/varnish
[root:/opt/varnish/varnish-2.0.6 Slave] # cp redhat/varnish.sysconfig /etc/sysconfig/varnish
4. 修改配置
进入varnish配置文件进行配置修改
[ root:/app/soft/varnish/etc/varnish Slave] # cd /app/soft/varnish/etc/varnish
[root:/app/soft/varnish/etc/varnish Slave] # vim default.vcl
启动和查看状态
[ root:/opt/varnish/varnish-2.0.6 Slave] # /app/soft/varnish/sbin/varnishd -f /app/soft/varnish/etc/varnish/default.vcl -s malloc,2G -T 127.0.0.1:2000 -a 0.0.0.0:8080
[root:/opt/varnish/varnish-2.0.6 Slave] # ps -ef |grep varnishd
Varnish启动运行信息 :
[root:/app/soft/varnish/bin Slave] # cd /app/soft/varnish/bin
[root:/app/soft/varnish/bin Slave] # /app/soft/varnish/bin/varnishlog
[root:/app/soft/varnish/bin Slave] # /app/soft/varnish/bin/varnishstat
杀掉varnish:
[root:/app/soft/varnish/bin Slave] # killall varnishd
隐藏nginx/tengine、apache、php版本号
一、隐藏nginx or tengine版本号
Nginx和tengine默认情况下是显示版本号的，如下所示
如上图所示可以看出服务器是tegine 2.0.0版本，有时候会暴露哪个Tengine或Nginx版本的漏洞，就是说有些版本有漏洞，而有些版本没有。这样暴露出来的版本号就容易变成攻击者可利用的信息。所以，从安全的角度来说，隐藏版本号会安全很多。
下面我们就来看看怎么设置，可以隐藏Tengine/Ngine的版本号:
1.进入到你Tengine/Nginx的安装目录，然后编辑主配置文件
# vim nginx.conf
在http {......}里加上server_tokens off;如：
http {
.....省略
sendfile on;
tcp_nopush on;
gzip on;
proxy_redirect off;
server_tokens off;
.....省略
}
2.如果后端接了php-fpm，则编辑配置文件fastcgi.conf或fcgi.conf (这个配置文件名也可以自定义的，根据具体文件名修改):
找到：
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;
改为：
fastcgi_param SERVER_SOFTWARE nginx;
3.重新加载tengine/nginx配置：
./sbin/nginx -s reload
这样就完全对外隐藏了nginx版本号了，就是出现404、501等页面也不会显示nginx版本。
最后验证结果：
如果想把Tengine也隐藏点，需要编辑Tengine源码中的src/core/nginx.h头文件
也可修改成你想要的显示信息，然后重新编译安装。
二、隐藏Apache版本号
一般情况下，软件的漏洞信息和特定版本是相关的，因此，软件的版本号对攻击者来说是很有价值的。
在默认情况下，系统会把Apache版本模块都显示出来（http返回头信息）。如果列举目录的话，会显示域名信息（文件列表正文），如：
隐藏方法：
1、隐藏Apache版本号的方法是修改Apache的配置文件，如Centos系统Linux默认是：
# vim /etc/httpd/conf/httpd.conf
分别搜索关键字ServerTokens和ServerSignature，修改：
ServerTokens OS 修改为 ServerTokens ProductOnly
ServerSignature On 修改为 ServerSignature Off
2、重启或重新加载Apache就可以了
# /etc/init.d/httpd restart
验证：
版本号与操作系统信息已经隐藏了
3、上面的方法是默认情况下安装的Apache，如果是编译安装的，还可以用修改源码编译的方法：
进入Apache的源码目录下的include目录，然后编辑ap_release.h这个文件，你会看到有如下变量：
#define AP_SERVER_BASEVENDOR “Apache Software Foundation”
#define AP_SERVER_BASEPROJECT “Apache HTTP Server”
#define AP_SERVER_BASEPRODUCT “Apache”
#define AP_SERVER_MAJORVERSION_NUMBER 2
#define AP_SERVER_MINORVERSION_NUMBER 2
#define AP_SERVER_PATCHLEVEL_NUMBER 15
#define AP_SERVER_DEVBUILD_BOOLEAN 0
可以根据自己喜好，修改或隐藏版本号与名字
三、隐藏php版本号
为了安全起见，最好还是将PHP版本隐藏，以避免一些因PHP版本漏洞而引起的攻击。
1、隐藏PHP版本就是隐藏 “X-Powered-By: PHP/5.4.42″ 这个信息：
编辑php.ini配置文件，修改或加入: expose_php = Off 保存后重新启动Nginx或Apache等相应的Web服务器即可。
验证：
2、其它几个PHP的基本安全设置：
disable_functions = phpinfo,system,exec,shell_exec,passthru,popen,dl,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
#该指令接受一个用逗号分隔的函数名列表，以禁用特定的函数。
display_errors = Off
# 是否将错误信息作为输出的一部分显示。在最终发布的web站点上，强烈建议你关掉这个特性，并使用错误日志代替。打开这个特性可能暴露一些安全信息，例如你的web服务上的文件路径、数据库规划或别的信息。
allow_url_fopen = Off
# 是否允许打开远程文件，建议关闭，如果网站需要采集功能就打开。
safe_mode = On
# 是否启用安全模式。打开时，PHP将检查当前脚本的拥有者是否和被操作的文件的拥有者相同，相同则允许操作，不同则拒绝操作。开启安全模式的前提是你的目录文件权限已完全分配正确。
open_basedir = /var/www/html/devopsh:/var/www/html/zhouuupc
# 目录权限控制，devopsh目录中的php程序就无法访问zhouuupc目录中的内容。反过来也不行。在Linux/UNIX系统中用冒号分隔目录，Windows中用分号分隔目录。
