nginx常见问题和坑

开启Nginx Proxy Cache性能不升反降

开启Nginx Proxy Cache后，性能下降，而且过一段时间内存使用率到达98%,解决方案如下。
1、内存占用率高的问题是内核问题，内核使用LRU机制，本身不是问题，不过可以通过修改内核参数来改善：

sysctl -w vm.extra_free_kbytes=6463787
sysctl -w vm.vfs_cache_pressure=10000

2、在HDD上使用Proxy Cache性能差，可以通过tmpfs缓存或nginx共享字典缓存元数据，或者使用SSD

“惊群”问题

        管理进程＋工作进程模式有很多优点，同时也有一些问题需要解决
        Nginx 里的工作进程 般是按系统 CPU 核数配置的，有多少个 CPU 核心，就会配置多少个工作进程，工作进程启动时就会利用 fork 函数创建多少个工作进程，并且所有的工作进程都监听在 nginx.conf内配置的监听端口上，这样可以充分利用多核机器的性能。网络事件通过底层的 events 模块管理，当客户端连接请求到来时， 一个新连接事件会上报，各个
作进程就会发生对事件的抢夺，这就是“惊群”问题 工作进程越多，问题越明显，这会造成系统性能下降，所以， 必须避免“惊群”问题 详细来说，“惊群”问题的典型场景是这样的：在没有用户请求的时候，所有的工作进程都在休眠，此时， 个用户向服务器发起了连接请求，例如，在 poll 模式下，内核在收到了 TCP的SYN 包时， 会**所有休眠的作进程，最先接收连接请求的工作进程可以成功建立新连接，其他工作进程的接会失 这些失败的唤醒是不必要的，引发了不必要的进程上下文切换，增加了系统开
销，这就是“惊群”问题
        Nginx 应用层制定了 个机制解决这个问题：规定同一时刻只能有唯一一个工作进程监听Web 端口，这样，新的连接事件只能唤醒唯一一个工作进程。内部的实现实际上是使用了一个进程间的同步锁，工作进程每次唤醒都先尝试这把锁，保证同一时间只有一个工作进程可以进入锁，获得锁的进程设置监昕连接的读事件，以处理未来的新连接请求，并处理已连接上的事件；未能进入监听锁的工作进程则不监听新连接事件，只处理已连接上的事件，将唤醒的工作进程分为了两类，一类（只有1个）是可以监听新连接的，另一类是正常处理已有连接请求的
        设置了连接事件监听的进程在连接事件到来时会被唤醒并检查系统变量，发现新连接队列中有连接则释放锁，并调用对应事件的 handler 方法。这种技术既解决了叫”惊群”问题，也避免了一个进程过长占用锁使新连接得不到及时处理的问题，接收了一个连接后，把连接放入队列后马上释放锁，如果恰巧有新连接马上进来， 则会由 一个新的工作进程接收连接，起到一定的负载均衡作用 放入队列的请求事件会在后续阶段处理