我正在尝试跟踪处理URL的脚本的内存使用情况。基本思想是在将另一个URL添加到cURL多处理程序之前，检查是否存在合理的缓冲区。我正在使用“滚动cURL”概念，该概念在多处理程序运行时处理URL数据。这意味着我可以在每次处理和删除现有URL时通过从池中添加新URL来保持N个连接处于活动状态。
我已经使用memory_get_usage()了一些积极的结果。添加该real_usage标志很有帮助（虽然并不清楚“系统”内存和“ emalloc”内存之间的区别，但是系统显示的数字更大）。memory_get_usage()确实会随着URL的添加而增加，而随着URL设置的耗尽而减少。但是，我刚刚超过了32M限制，最后一次内存检查为〜18M。
memory_get_usage()
real_usage
每当cURL multi信号返回请求时，我都会轮询内存使用情况。由于可能同时返回多个请求，因此一堆URL可能同时返回数据，并且实际上使内存使用量跃升了14M。但是，如果memory_get_usage()准确的话，我想这就是事实。
[ 更新 ：在问我猜之前，应该运行更多测试，增加php的内存限制（但在脚本中保留“安全”数量相同），并且报告的内存使用量确实从我自己施加的25M限制以下跃升至32M以上。然后，如预期的那样，缓慢地降低为未添加的URL。但是我会提一个问题：这是正确的方法吗？]
我可以这样信任memory_get_usage()吗？是否有更好的替代方法来获取内存使用情况（我已经看到一些脚本解析shell命令的输出）？
real_usage 这样工作：
Zend的内存管理器不会为每个需要的块使用系统malloc。相反，它分配了一大块系统内存（以256K为增量，可以通过设置环境变量进行更改ZEND_MM_SEG_SIZE）并在内部进行管理。因此，有两种内存使用情况：
ZEND_MM_SEG_SIZE
可以通过返回其中之一memory_get_usage()。哪种对您更有用取决于您要寻找的内容。如果您要优化特定部分的代码，则“内部”对您可能更有用。如果您要全局跟踪内存使用情况，则“实际”将更有用。memory_limit限制“实数”，因此一旦限制所允许的所有块都从系统中取出，并且内存管理器无法分配请求的块，分配就会失败。请注意，在这种情况下，“内部”使用量可能小于限制，但是由于碎片，分配仍然可能失败。
memory_limit
另外，如果您使用某些外部内存跟踪工具，则可以设置此环境变量USE_ZEND_ALLOC=0，该变量将禁用上述机制并使引擎始终使用malloc()。这会带来更差的性能，但允许您使用malloc跟踪工具。
USE_ZEND_ALLOC=0
malloc()
