2016-07-28 67 views
8

我注意到有什麼topps報告內存使用了PHP的過程,對比一下過程本身認爲使用(與memory_get_usage)其之間完全不同。PHP實際使用多少內存?

該進程實際使用多少內存?

當運行下面的代碼與我的應用程序之一沿着:

echo "Memory usage: " . pretty_bytes(memory_get_usage()) . PHP_EOL; 
echo "Peak memory usage: " . pretty_bytes(memory_get_peak_usage()) . PHP_EOL; 
echo "'Actual' memory usage: " . pretty_bytes(memory_get_usage(true)) . PHP_EOL; 
echo "'Actual' peak memory usage: " . pretty_bytes(memory_get_peak_usage(true)) . PHP_EOL; 

$ps_output = exec("ps --pid " . getmypid() . " --no-headers -o rss"); 

echo "'Memory usage according to ps: " . pretty_bytes(intval($ps_output) * 1000); 

一個隨機點的輸出是:

Memory usage: 4.77 MB 
Peak memory usage: 4.99 MB 
'Actual' memory usage: 5.00 MB 
'Actual' peak memory usage: 5.00 MB 
Memory usage according to ps: 17.66 MB 

在我的具體情況,這是一個問題,因爲我m運行了不少工人和守護進程。

當我將PHP內存限制設置爲例如根據PHP自己的測量結果,每個守護進程都有128 MB的空間,這些進程只有在達到128 MB時纔會被殺死。但是,根據ps,到那時爲止每個進程將使用大約200 MB。

回答

2

應該強調的究竟是什麼值由報告0和memory_get_usage(true)是。

ps -o rss報告實際居民套裝大小。依靠這個值是一個很大的缺陷,因爲它不包括最終換出的內存。在一般情況下,你想要的USS,在一套獨特的尺寸,這基本上是不共享內存(看看smem(8)爲)。內核實際上已經爲該進程映射了頁面的非共享內存數量,即物理地在RAM或交換文件中存在非共享內存。這與您可以獲得「真實」內存使用情況相近。 [請參閱/proc/$PID/smaps以獲得詳細的概述,正如IVO GELOV的答案中所述,您可以在技術上通過解析該虛擬文件來計算您自己的內存。]

關於memory_get_usage(),這將報告由使用PHP內部內存管理器的系統實際分配的堆內存。這意味着,直接使用系統的其他內存管理器(mmap(2)malloc(3))的庫不會在這裏公開它們的內存使用情況。 [這是一個例子,爲什麼mysqlnd確實表現出多大的內存使用量,同時的libmysqlclient不 - 。後者使用malloc()國內]

如果您通過true作爲第一個參數,即memory_get_usage(true),它返回內存PHP的內存管理器的總量已經從系統要求。這個數字一般是略微的,但不會比memory_get_usage(false)高得多。它也是memory_limit INI設置與之比較的數字。

如果你想看看你可以運行多少工作,請注意PHP除了內核可能共享共享結構(操作碼,類信息等)的庫內存和opcache外,並不共享太多內存。因此共享內存對你來說應該不重要。對你來說最重要的價值應該是USS。

+0

Thanks @bwoebi。這和Ivo的答案讓我們對問題有了充分的瞭解解決手頭的問題。 – Robbert

6

memory_get_usage報告由PHP進程來運行你的腳本分配的內存。 ps報告PHP進程本身使用的內存,其中包括用於腳本的內存。 PHP進程使用許多外部庫,這些庫都可以分配內存,而不需要PHP進程意識到這一點。

因此memory_get_usageps本質上衡量不同的事情,並應報告不同的數字。這一切都歸結爲你如何定義「實際的內存使用情況」。我明白你的情況你更關心PHP進程的內存使用情況。那麼ps的輸出更適合你。但你可以很容易地發現,即使在現代操作系統和共享存儲器世界中,ps報告的RSS值也不是那麼黑白。

參見:

+0

謝謝Erki。這是一個有益的開始,但是我們仍然錯過了@bwoebi能夠在他的答案中提供的一些細節。 – Robbert

2

您可能會發現有趣的事情,當這些命令之一:

cat /proc/PID_NUMBER/smaps 
pmap -d PID_NUMBER 
+0

沒有解釋的一些祕密結果(儘管潛在的教育)可能不是正確的方法。 ; o) – Jakumi

+0

在很多地方可以找到其他信息,例如 –

+0

,但很有可能,但除非您鏈接到其中一些地方,否則您的答案本身並不能提供任何見解。 – Jakumi