我注意到,与进程本身认为使用(使用)的内容相比,PHP进程的内存使用情况top或ps报告之间存在很大差异memory_get_usage.
该进程实际使用了多少内存？
与我的某个应用程序一起运行以下代码时:
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
在我的特殊情况下,这是一个问题,因为我正在运行相当多的工人和守护进程.
当我为这些守护进程中的每一个设置PHP内存限制为例如128 MB时,这些进程只有在根据PHP自己的测量值达到128 MB时才会被杀死.但是,根据ps这个过程,这个过程将使用大约200 MB.
memory_get_usage报告PHP进程分配的内存以运行脚本.ps报告PHP进程本身使用的内存,其中包括用于脚本的内存.PHP进程使用许多外部库,它们都可以在没有PHP进程知道的情况下分配内存.
因此memory_get_usage,ps本质上衡量不同的东西,并应报告不同的数字.这一切都取决于你如何定义"实际内存使用".据我所知,在您的情况下,您对PHP进程的内存使用更感兴趣.那么输出ps对你来说更相关.但是你可以很容易地发现,即使报告的RSS值ps在现代操作系统和共享记忆的世界中也不是那么黑白.
也可以看看:
应该强调的究竟是什么价值观报道ps和memory_get_usage(true)是。
ps -o rss报告实际的居民集大小。依赖此值是一个陷阱，因为它不包括最终换出的内存。通常，您需要USS，唯一集大小，它基本上是未共享的内存（对此有所了解smem(8)）。这是内核实际上已为该进程映射页面的未共享内存的数量，即物理上存在于RAM或交换文件中的未共享内存。这与“实际”内存使用量所能达到的程度非常接近。[也可以参考/proc/$PID/smapsIVO GELOV的答复中提到的详细概述，在技术上您可以通过解析该虚拟文件来计算要自己计算的内存。]
关于memory_get_usage()，这报告了系统实际使用PHP的内部内存管理器分配的堆内存。这意味着，直接使用系统其他内存管理器（mmap(2)或malloc(3)）的库不会在此处公开其内存使用情况。[例如，这就是为什么mysqlnd确实显示大量内存使用而libmysqlclient不显示-后者在malloc()内部使用的原因。]
如果您true作为第一个参数传递，即memory_get_usage(true)，它将返回PHP的内部内存管理器从系统请求的内存总量。该数字通常略大，但不高于memory_get_usage(false)。这也是与memory_limitINI设置进行比较的数字。
如果要查看可以运行多少个工作程序，请注意，PHP不会共享太多内存，只是内核可能共享库内存和opcache，后者共享结构（操作码，类信息等）。因此，共享内存对您而言应该不重要。因此，对您来说最重要的价值应该是USS。