9

我的 php 脚本使用 ZipArchive() 在 CentOS 5.6 和 PHP 5.2.12 上运行，并成功创建了超过 1.6Gb 的 .zip 文件，但对于 2GB 或更大的较大存档却没有 - PHP 中止且没有明显错误。PHP 错误日志或标准错误中没有任何内容。该脚本正在 cmd 行中执行，而不是以交互方式执行。

脚本运行了大约 8 分钟，临时存档增长，在检查文件大小时，最后一个清单显示 tmp 文件的大小为 2120011776，然后 tmp 文件消失，PHP 脚本通过逻辑并在存档创建后执行代码.

由于某种原因，top 显示 CPU 仍处于 95% 并且正在创建一个新的 tmp 存档文件 - 它这样做了另外 5 分钟以上，然后静默停止并留下未完成的 tmp 存档文件。在此测试中 - 预期文件少于 4000 个。

如上所述的脚本可以很好地创建较小的存档文件。

在几组不同的大型源数据上进行了测试 - 大型文件的结果相同。

这个问题听起来类似于这个问题： Size limit on PHP's zipArchive class?

我想也许 ls -l 命令正在返回 2K 块的计数，因此 2120011776 将接近 4GB，但该大小以字节为单位 - xxxx.zip.tmpxx 文件的大小。

谢谢！

4

4 回答 4

3

这可能是很多事情。我假设您有足够的可用磁盘空间来处理该过程。正如其他人所提到的，可以通过编辑 php.ini 文件或在代码本身中使用 ini_set() 函数来解决一些问题。

你的机器有多少内存？如果它耗尽了您的实际内存，那么它会在一定大小后定期中止是有道理的。因此，在脚本执行之前检查可用内存使用情况并在脚本执行时对其进行监控。

第三种选择可以基于文件系统本身。我对 CentOS 没有太多经验，但有些文件系统不允许超过 2 GB 的文件。虽然，从产品页面来看，CentOS 上的大多数系统似乎都可以处理它。

如果您查看上面链接的产品页面，则会出现第四个选项，这似乎是最有希望的，另一个可能的罪魁祸首是“最大 x86 每进程虚拟地址空间”，大约为 3gb。x86_64 大约是 2tb，所以检查处理器的类型。

同样，似乎第四个选项是罪魁祸首。

于 2014-02-11T06:44:41.870 回答
-1

当您的文件很大时，将其归档 ZIP 需要一些时间，但在 PHP (php.ini) 中执行时间最长，因此您必须尝试增加该值。

于 2014-02-28T05:32:37.683 回答
-1

你有在 php.ini 中使用 set_limit 变量吗？

你可以使用. Htacess 或 PHP 脚本内。在脚本内 set_time_limit(0); .htaccess 里面的 php_value memory_limit 214572800;

于 2014-01-28T20:04:28.717 回答
-2

php.ini 中的最大执行时间有一个设置，
也许这​​被解雇了！
努力增加价值！

操作系统也有不同的文件大小限制，请尝试检查！

于 2011-04-21T14:12:10.673 回答