128MB PHP 内存限制很多吗？答案

【问题标题】：Is a 128MB PHP memory limit a lot?128MB PHP 内存限制很多吗？
【发布时间】：2010-10-07 14:43:08
【问题描述】：

今天我在我正在构建的内容管理系统中添加了一个新功能。根据您将图像上传到的位置，PHP 将调整图像大小以适合指定位置。它工作得很好，但是当我尝试上传更大的图像时，比如在 3MB 图像中，我遇到了一个致命错误：

Fatal error: Allowed memory size of 134217728 bytes exhausted 
(tried to allocate 42520 bytes) in...

我认为 128MB 的内存是相当多的，考虑到我没有运行那么多......至少我不这么认为。它尝试为调整大小的过程再分配 42520 字节，但失败了。

我的问题是我应该 (A) 增加限制还是 (B) 重新评估我为什么首先使用这么多内存？ 128MB 是个好数字还是太大/太小？

谢谢，瑞恩

分辨率

我得出的结论是 128MB 对于调整图像大小确实太大了，我非常专注于查看其他选项......比如 exec() 选项，我从未仔细查看我的“样本”数据。事实证明，即使我的大图像只有 2.83MB，但它的宽度却超过了 10000 像素。那是个问题。 :)

【问题讨论】：

没有人需要超过 128 MB 的内存 :)
所以我确定了哪个函数导致脚本出现致命错误。就是这个：imagecreatefromjpeg()。我的下一个问题是，这是正确的做法吗？ -瑞安
现在我已经将其范围缩小到这个函数，我阅读了一些关于它是如何工作的，并且我理解了这个问题。在另一个论坛中，我读到了这篇文章“......但是你可以使用 exec() 启动一个调用 ImageMagick 的新进程，然后 PHP 内存限制不会影响它。”有人对此有任何想法吗？似乎没有解决 imagecreatefromjpeg() 的方法，因为它完成了它的工作。 -瑞安
@Abel - :-) “640K 对于任何人来说都应该足够了。” （经常被误认为是 William H. Gates III）
@Mark Baker 这就是我的意思！

【解决方案1】：

GD 将图像作为位图存储在内存中，因此我不完全排除某些 JPG 图像（例如，高分辨率、高度压缩）的位图版本可能非常大的可能性。

在您打开并开始调整图像大小之前致电memory_get_usage() 并查看该内存量是否太大。

也仅供参考，当脚本显示“（尝试分配 42520 字节）”时，这并不意味着它只需要 42520 字节才能成功运行。它只是意味着在那一刻它需要 42520 更多字节。稍后它可能会尝试分配更多内存。因此，仅在内存总量中增加 42520 字节可能不会解决任何问题。

【讨论】：

非常有帮助！我现在就试试，然后回复结果！
文件：940KB。之前：89724。之后：2321281。文件：2.83MB。之前：89724。之后：错误。我的新问题：如何根据图像大小从 2.2MB 跃升至 128MB 以上？问题是否与脚本如何调整图像大小有关？ -瑞安
好吧，就像注释一样 - 脚本必须将图像解压缩为位图。我可以轻松制作一个使用 1gb 内存的小 gif。然后它必须重新包装。
就我而言，我有哪些选择？ -瑞安
大多数图像格式都涉及一些压缩，并且不会为每个像素存储全彩色信息。例如：如果 PNG 文件中的像素与左侧像素的颜色相同，则它不存储任何颜色信息，它只是（基本上）存储“同上”。位图图像没有任何压缩，并为每个像素存储全彩色信息。这就是尺寸被放大的地方。

【解决方案2】：

您如何调整图像大小？我希望您使用像imagecopyresampled() 这样的库函数？如果是这样，您不需要 128M 的 RAM 来调整 3M 图像的大小。它表明您做某事不正确或效率低下。

【讨论】：

我实际上在这里使用了这个脚本的很大一部分：white-hat-web-design.co.uk/articles/php-image-resizing.php
@Ryan S：所以你是说你不知道你从互联网上剪切和粘贴的代码是做什么的？实际上，这写得相当好，并且确实调用了 imagecopyresampled() - 但是如果您通过剪切和粘贴其他人的代码而不检查其质量来实现您的网站，难怪您会遇到问题。看起来其他地方有泄漏。
我确实知道代码的作用。我超越了剪切和粘贴。该脚本确实看起来非常干净且易于理解，因此我选择了它。问题是，在我开始调整图像大小之前，我可以上传一张 5MB 的图片，而且从来没有内存问题。这并不是说我可能只是在极限之下。是否有“监视器”来查看图表或查看每行的内存使用情况？ -瑞安

【解决方案3】：

您永远不需要分配那么多内存。重新评估您的代码以减少其消耗，并确保您没有多余地存储数据。

【讨论】：

我会说我在共享主机上，所以我不知道128MB是我的还是所有人的？我实际上正在考虑将所有内容移至专用虚拟主机，但我想确保我理解这个问题。通常，正如您所建议的，向它扔内存并不能最终解决问题。 -瑞安
从头开始...限制是每个脚本。 -瑞安

【解决方案4】：

对真彩色图像消耗多少内存的粗略估计：

width x height x 4

如果您的用户被告知上传图片的最大尺寸（以像素为单位），那么您可以确定必须分配的最小 RAM。

顺便说一句，考虑在格式转换、复制等操作中使用的变量。

【讨论】：

函数 imagecreatefromjpeg() 占用资源最多是否正常？在该函数运行之前，我使用了可用 128MB 中的 91316 字节。对于 2.82MB 的图像，这个功能真的需要超过 128MB 吗？有没有其他选择？ -瑞安
2.82MB 压缩图像并不表示需要多少 RAM（未压缩图像）。 1280x800 TrueColor 图像在 RAM 中消耗 4MB，但由于 JPEG 压缩，磁盘上的物理大小可能只有 256KB。
所以它基于它的物理尺寸。 -瑞安

【解决方案5】：

使用 64mb，您可以处理很多事情。如果您需要更多，则需要开始清理已用内存的东西。 128Mb 应该是脚本需要的最大值，而且确实是一个非常大的脚本。

【讨论】：