Php ZipArchive'；s open/addFile方法在大数据集上崩溃并出现致命错误

我们有一个php（5.3.10版）cli应用程序，它在ubuntu 12.04 64位机器上执行一些繁重的工作。此脚本可以运行很长时间，具体取决于它接收的数据集。这些数据集是包含大量XML、图像和MS文档文件的zip文件

在此之前，该脚本使用很少的系统命令（shell、perl、java）来完成其任务。那时我们没有问题。最近，我们将这些脚本升级为使用RabbitMQ进行多个并发调用，从基于cron的工作转移到用于自动恢复和监视的supervisord，并且尽可能多地使用php的核心库和函数来避免shell调用

现在，在部署到生产环境后，我们发现脚本在一条线路上致命地崩溃，ZipArchive被用来创建归档文件。具体来说，仅在其方法“open”和“addFile”上。我们用有问题的数据集对此进行了多次测试，发现这才是真正的问题所在

引发的错误是“致命错误：超出了300秒的最大执行时间”。我们知道php对执行时间的限制，我们仔细检查了php.ini和“/etc/php5/conf.d”文件夹下的所有设置，并将“max_execution_time”设置为0。我们还使用“php_sapi_name（）”检查了脚本的sapi模式是否为“cli”。ini_get（“max_execution_time”）也返回0

即使脚本由supervisord管理，上述模式和执行限制也是相同的。我们无法查明300秒的“最大执行时间”限制是从何处触发的

还有一件事，当脚本因此消息崩溃时，它实际运行了600多秒。我们还认为，只有当ZipArchive自身花费了300多秒时，这种情况才会发生。但我们不确定。此外，发生这种情况时，它创建的部分zip存档介于280 MB和290 MB之间。因此，我们从其存储库下载了php源代码，并进行了快速的grep，以查看ZipArchive的代码库是否存在此类限制。我们没有找到

我们现在正试图用shell命令替换ZipArchive php代码，作为一种解决方法。我们还没有测试它。我将很快在这里发布我们的发现

---

你们中有人曾经遇到过这样的问题吗？这和ZipArchive有关吗？是否建议使用ZipArchive创建大型归档？它在崩溃之前创建的部分zip文件的大小介于280 MB和290 MB之间。

我曾经在使用zipArchive时遇到过同样的问题，文件大小大于500 MB。在某些情况下，当文件的大小相当小，但文件的数量较高时，它也会起作用。最后，我在linux zip/unzip命令上创建了一个包装器，并使用了它们，因此在内核中，它基本上只是在操作系统级别上执行exec（）。从未有过这样的问题。当然，您需要一个sysad来设置权限和所有内容，但这是一个稳定的解决方案。

将尝试这样做。但它抛出的错误消息无助于找到根本原因。此数据集有3个大小接近或超过100MB的文件。这也是我们正在调查的事情。@PeroliSivaprakasam，似乎来自Apache的超时指令。请检查您的Apache配置以获取该信息。True。但它与apache没有任何联系。我们正在从命令行运行这个。我们甚至在这个脚本的开头编写了ini_集（“max_execution_time”，0）。还是坏了，对不起。如果在ZipArchive的Open方法之前包含set_time_out（0），则该设置将起作用。但一个强有力的解决方案尚未找到。