1

我不确定内存是否是这里的罪魁祸首。我正在尝试从内存中的数据(它以前来自数据库)中实例化一个 GD 图像。我尝试这样的电话:

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

$image回来了undef。GD 的 POD 说构造函数将undef在内存不足的情况下返回,所以这就是我怀疑内存的原因。

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

这适用于非常小的图像,例如 30K 以下。但是,稍微大一点的图像,比如 ~70K 会导致问题。我不认为 70K 的图像会导致这些问题,即使在它被瘪了之后。

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

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

感谢您的任何见解!

编辑:为澄清起见, GD::Image 对象永远不会被创建,因此从内存中清除$image_data它并不是一个真正的选择。

4

2 回答 2

1

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

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

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

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

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

于 2009-11-28T19:19:25.047 回答
0

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

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

原始脚本:

$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 的内存,它释放了足够的空间来处理更多的处理。

于 2008-12-23T05:33:09.273 回答