php-fpm 找不到 php-cgi.sock 怎么办

php-fpm有两种listen方式，一种是通过端口来 *** 作，一种是sock文件。

在nginx的server配置当中，如果设置为fastcgi_pass unix:/tmp/php-cgi.sock的话，有可能会出现502错误，这是以为nginx此项没有找到php-cgi.sock文件或者权限问题导致的,我们也可以改成fastcgi_pass:127.0.0.1:9000来修正这个错误 。

当我们神旦镇用php-fpm来管理我们的php启动时，按照如下的配置，就会自动生成/tmp/php-cgi.sock文件，然后再访问的话就不回出现502 Gateway错误了。配置如下：

[global]

pid = /var/run/php-fpm.pid

error_log = /var/log/php-fpm.log

log_level = notice

[www]

listen = /tmp/php-cgi.sock

user = www

group = www

pm = dynamic

pm.max_children = 20

pm.start_servers = 2

pm.min_spare_servers = 1

pm.max_spare_servers = 3

注：将迟猛php.ini里的cgi.fix_pathinfo设游粗置为0,不然会有漏洞～

Nginx 采用的是多进程（单线程） &多路IO复用模型。使用了 I/O 多路复用技术的 Nginx，就成了”并发事件驱动“的服务器。

异步非阻塞

1、Nginx 在启动后，会有一个 master 进程和多个相互独立的 worker 进程。

2、接收来自外界的信号，向各worker进程发送信号，每个进程都有可能来处理这个连接。

3、 master 进程能监控 worker 进程的运行状态，当 worker 进程退出后(异常情况下)，会自动启动新的 worker 进程。

worker 进程数，一般会设置成机器 cpu 核数。因为更多的worker 数，只会导致进程相互竞争 cpu，从而带来不必要的上下文切换

惊群现象

主进程（master 进程）首先通过 socket() 来创建一个 sock 文件描述符用来监听，然后fork生成子进程（workers 进程），子进程将继承父进程的 sockfd（socket 文件描述符），之后子进程 accept() 后将创建已连接描述符（connected descriptor）），然后通过已连接描述符来与客户端通信。

那么，由于所有子进程都继承了父进程的 sockfd，那么当连接进来时，所有子进程都将收到通知并“争着”与它建立连接，这就叫“惊群现象”。大量的进程被激活又挂起，只有一个进程可以accept() 到这个连接，这当然会消耗系统资源。

Nginx对惊群现象的处理

Nginx 提供了一个 accept_mutex 这个东西，这是一个加在accept上的一把共享锁。即每个 worker 进程在执行 accept 之前都需要先获取锁，获取不到就放弃执行 accept()。有了这把锁之后，同一时刻，就只会有一个进程去 accpet()，这样就不会有惊群问题了。accept_mutex 是一个可控选项，我们可以显示地关掉，默认是打开的。

主要用来管理worker进程，包含：接收来自外界的信号慧迟，向各worker进程发前腊李送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。

worker进程工作流程

当一个 worker 进程在 accept() 这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，一个完整的请求

什么是IO多路复用呢？

对于 *** 作系统而言，IO多路复用就是局晌要完成 *** 作系统IO的请求。对于IO文件的请求，当一个IO流要进行文件处理的时候，要获取一组文件的描述符，当文件描述符还没有就绪时，那么它就在等待，直到描述符一旦就绪，马上上报系统通知的机制，告诉应用程序我准备就绪，你可以来 *** 作了。这就是IO多路复用的方式。

这种机制处理起来就很高效，多路复用就是在一个线程里，交替并发的完成。复用的就是一个线程。

当你在Ubuntu下使用nginx和uwsgi部署flask时，uwsgi服务器的默认配置可能会导致问题。uwsgi默认会创建一个主进程和一个或多个工作进程，而当nginx代理请求时，它可能会将请销禅轿求发送到已经关闭的工作进程，导致超时错误。使用killall -s INT uwsgi命令杀袭茄掉uwsgi进程可以解决这个问题，因为这个命令会向uwsgi主进程发送SIGINT信号，通知它关闭所有工作进程。然后，当你再次启动uwsgi时，它会重新创建一组新的工作进程，这些工作进程应该都能够正常工作。

为了避免这种情况，你可以修改uwsgi的配置，使它只创建一个工作进程。这样，当nginx代理请求时，它就只会将请求发送到一个工作进程，而不亏肆会出现超时错误。你可以在uwsgi配置文件中添加processes = 1来实现这一目的。例如：

==============

[uwsgi]

socket = /tmp/uwsgi.sock

chdir = /path/to/your/app

wsgi-file = app.py

callable = app

processes = 1

==============

希望这些信息能够帮助你解决问题。

---