但是这里有一个很大的问题，php允许访问的内存大小是35389440字节，而实际要分配的只有1406507字节。为什么要分配的内存比实际允许访问的内存小还会引发致命错误呢？
查了很多这方面的资料，发现很多这样搜索结果，都是实际要分配的内存要小于允许的内存，但是没有找到对此的说明。
首先想到是不是php本身这个内存限制功能有bug，于是做了如下实验:
1, 生成一个10mb大小的文件 dd if=/dev/zero of=10mb bs=1m count=10
2, 生成如下php文件并访问:
发现其报错“fatal error: allowed memory size of 2097152 bytes exhausted (tried to allocate 10493952 bytes)”,这个报错和我们设置的2m的内存限制，实际要分配10m的情况是一样的。这说明内存限制本身功能是没有问题的，报错的数据和实际的数据是能对上号的。
那么，上面的问题出在哪里呢？为什么实际要分配的内存比限制的内存要小，还会导致出错？又查了一下php关于memory_limit的说明:
this sets the maximum amount of memory in bytes that a script is allowed to allocate. this helps prevent poorly written scripts for eating up all available memory on a server. note that to have no memory limit, set this directive to -1.
这里也没有对上述问题进行说明，只是告诉我们memory_limit用来限制一个脚本中分配的内存大小用来保护服务器免受poorly written scripts的影响。也就是说memory_limit是限制单个php运行脚本的可访问内存大小的，那会不会存在一种可能，整个线程中的多个操作加起来的内存超过了总限制大小，但单个操作的内存又只占整个限制的很小一部分，而最后那根压死骆驼的稻草是php报错出来的，所以显示出试图访问内存小于限制的内存大小？为了验证这个猜想，我把上述php文件改成这样并访问:
发现其报错“fatal error: allowed memory size of 15728640 bytes exhausted (tried to allocate 10493952 bytes)”，实际要分配10m内存，小于允许访问的15m，验证了前面的猜想。也就是说， 程序在运行时如果超过设置的内存，php报错信息只会提示当前操作试图访问的内存大小。
那么直接增加内存限制的大小就可以解决这个问题了，限制的大小可以通过在php的shutdown函数上注册memory_get_usage函数来统计网站的内存消耗，取一个合适的值即可。
参考资料 memory limit