###內存泄漏   內存泄漏指的是在程序運行過程中申請了內存，但是在使用完成后沒有及時釋放的現象， 對于普通運行時間較短的程序來說可能問題不會那么明顯，但是對于長時間運行的程序， 比如Web服務器，后臺進程等就比較明顯了，隨著系統運行占用的內存會持續上升， 可能會因為占用內存過高而崩潰，或被系統殺掉 ###PHP的內存泄漏   [PHP](http://lib.csdn.net/base/php)屬于高級語言，語言級別并沒有內存的概念，在使用過程中完全不需要主動申請或釋放內存， 所以在PHP用戶代碼級別也就不存在內存泄漏的概念了。 但畢竟PHP是使用C編寫的解釋器，而[C語言](http://lib.csdn.net/base/c)的程序是可能出現內存泄漏問題，所以本質上還是一樣的，那么可以這么說：如果你的PHP程序內存泄漏了，會有三種可能： 首先肯能是自己的代碼有問題，比如沒有及時釋放大內存的變量等。 很多公司都會有自己的PHP擴展，而擴展通常也使用C/C++來編寫，這樣擴展本身也可能會因為內存不正確釋放而導致內存泄漏。 有些擴展是對第三方庫的一種包裹， 比如PHP的sqlite數據庫操作接口主要是在libsqlite之上進行了封裝，所以如果 libsqlite本身有內存泄漏的話，那也可能會帶來問題。 ###PHP-CGI   根據官方的介紹，php-cgi不存在內存泄漏，每個請求完成后php-cgi會回收內存，但是不會釋放給[操作系統](http://lib.csdn.net/base/operatingsystem)，這樣就會導致大量內存被php-cgi占用。(這個對于內存不大的服務器，比如云主機就太致命了，利用命令：ps aux|grep php-cgi|grep -v grep|awk '{if($4>=1)print $2}' ?可以查詢占比1%的php-cgi的pid，然后kill掉(kill -9),這個方法比較好)?官方的解決辦法是降低PHP_FCGI_MAX_REQUESTS 的值。 ###Nginx&PHP-FPM   這里先簡單說一下nginx+php-fpm模式的工作原理： nginx服務器fork出n個子進程（worker），php-fpm管理器fork出n個子進程。 當有用戶請求，nginx的一個worker接收請求，并將請求拋到socket中。 php-fpm空閑的子進程監聽到socket中有請求，接收并處理請求。   這里要重點說一下第三步驟。第三步涉及到php-fpm進程生命周期的東西。一個php-fpm的生命周期大致是這樣的：模塊初始化（MINIT）-> 模塊激活（RINIT）-> 請求處理 -> 模塊停用（RSHUTDOWN） -> 模塊激活（RINIT）-> 請求處理 -> 模塊停用（RSHUTDOWN）……. 模塊激活（RINIT）-> 請求處理 -> 模塊停用（RSHUTDOWN）-> 模塊關閉（MSHUTDOWN）。在一個php-fpm進程的生命周期里，會有多次的模塊激活（RINIT）-> 請求處理 -> 模塊停用（RSHUTDOWN）的過程。這個“請求處理”的大致過程是這樣的：php讀取相應的php文件，對其進行詞法分析，生成opcode，zend虛擬機執行opcode。   PHP配置文件里面的memory_limit 這個東西，其實，它限制的只是這個“請求處理”的內存。所以，這個參數跟php-fpm進程占用的內存并沒有什么關系。php是用c寫的，所以，難免又會一些內存泄露。也就是說，在“請求處理”這個過程結束后，有些變量沒有被銷毀，然后就導致一個php-fpm進程占用的內存越來越大。 那么，有什么辦法能阻止這個問題呢？?php-fpm.conf中有個參數pm.max_requests ，等同于PHP_FCGI_MAX_REQUESTS。該值的意思是一個fpm進程處理多少個請求后自動殺掉另起新進程。?這個參數默認是關閉的，我們需要開啟這個參數，并且適當降低這個值，用以讓php-fpm自動的釋放內存。另一個跟它有關聯的值max_children，這個是每次php-fpm會建立多少個進程，這樣實際上的內存消耗是max_children*max_requests*每個請求使用內存，根據這個我們可以預估一下內存的使用情況，就不用再寫腳本去kill了。