如何防止 GD 内存不足？

发布于 2024-07-10 08:28:13 字数 621 浏览 8 评论 0原文

我不确定内存是否是这里的罪魁祸首。我正在尝试从内存中的数据实例化 GD 图像（它以前来自数据库）。我尝试这样的调用：

my $image = GD::Image->new($image_data);

$image 返回为 undef。 GD 的 POD 说，如果内存不足，构造函数将返回 undef，所以这就是我怀疑内存的原因。

图像数据为PNG 格式。如果我调用 newFromPngData，也会发生同样的事情。

这适用于非常小的图像，例如 30K 以下。但是，稍大的图像（例如 ~70K）会导致问题。我不认为 70K 图像会导致这些问题，即使它被缩小了。

该脚本在 OS 10.4 上通过 Apache 2.0 在 CGI 下运行（如果这很重要的话）。

Apache 默认情况下是否有任何内存限制？可以增加吗？

感谢您的任何见解！

编辑：澄清一下，GD::Image 对象永远不会被创建，因此从内存中清除 $image_data 并不是真正的选择。

原文

I'm not sure if memory is the culprit here. I am trying to instantiate a GD image from data in memory (it previously came from a database). I try a call like this:

my $image = GD::Image->new($image_data);

$image comes back as undef. The POD for GD says that the constructor will return undef for cases of insufficient memory, so that's why I suspect memory.

The image data is in PNG format. The same thing happens if I call newFromPngData.

This works for very small images, like under 30K. However, slightly larger images, like ~70K will cause the problem. I wouldn't think that a 70K image should cause these problems, even after it is deflated.

This script is running under CGI through Apache 2.0, on OS 10.4, if that matters at all.

Are there any memory limitations imposed by Apache by default? Can they be increased?

Thanks for any insight!

EDIT: For clarification, the GD::Image object never gets created, so clearing out the $image_data from memory isn't really an option.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

绝對不後悔。 2024-07-17 08:28:13

GD 库会占用图像大小的每个字节许多字节。比例远远超过10:1！

当用户将图像上传到我们的系统时，我们首先检查文件大小，然后将其加载到 GD 图像中。如果它超过阈值（1 MB），我们不会使用它，而是向用户报告错误。

如果我们真的关心，我们可以将其转储到磁盘，使用命令行“转换”工具将其重新缩放到合理的大小，然后将输出加载到 GD 库并删除临时文件。

convert -define jpeg:size=800x800 tmpfile.jpg -thumbnail '800x800' -

将缩放图像，使其适合 800 x 800 的正方形。它的最长边现在是 800px，应该可以安全加载。上述命令会将缩小的 .jpg 发送到 STDOUT。 size= 选项应该告诉 Convert 不要费心在内存中保存巨大的图像，而只是足以缩放到 800x800。

GD library eats many bytes per byte of image size. It's a well over a 10:1 ratio!

When a user uploads an image to our system, we start by checking the file size before loading it into a GD image. If it's over a threshold (1 Megabyte) we don't use it but instead report an error to the user.

If we really cared we could dump it to disk, use the command line "convert" tool to rescale it to a sane size, then load the output into the GD library and remove the temporary file.

convert -define jpeg:size=800x800 tmpfile.jpg -thumbnail '800x800' -

Will scale the image so it fits within an 800 x 800 square. It's longest edge is now 800px which should safely load. The above command will send the shrunk .jpg to STDOUT. The size= option should tell convert not to bother holding the huge image in memory, but just enough to scale to 800x800.

回复收藏 0 原文

來不及說愛妳 2024-07-17 08:28:13

我遇到过同样的问题几次。

我的解决方案之一就是增加脚本可用的内存量。另一个是清除缓冲区：

原始脚本：

$src_img = imagecreatefromstring($userfile2);
imagecopyresampled($dst_img,$src_img,0,0,0,0,$thumb_width,$thumb_height,$origw,$origh);

编辑脚本：

$src_img = imagecreatefromstring($userfile2);
imagecopyresampled($dst_img,$src_img,0,0,0,0,$thumb_width,$thumb_height,$origw,$origh);
imagedestroy($src_img);

通过清除第一个 src_image 的内存，它释放了足够的空间来处理更多处理。

I've run into the same problem a few times.

One of my solutions was simply to increase the amount of memory available to my scripts. The other was to clear the buffer:

Original Script:

$src_img = imagecreatefromstring($userfile2);
imagecopyresampled($dst_img,$src_img,0,0,0,0,$thumb_width,$thumb_height,$origw,$origh);

Edited Script:

$src_img = imagecreatefromstring($userfile2);
imagecopyresampled($dst_img,$src_img,0,0,0,0,$thumb_width,$thumb_height,$origw,$origh);
imagedestroy($src_img);

By clearing out the memory of the first src_image, it freed up enough to handle more processing.

回复收藏 0 原文

~没有更多了~