我们有一个 php（版本 5.3.10）cli 应用程序在 ubuntu 12.04 64 位机器上做一些繁重的工作。该脚本可以运行很长时间，具体取决于它接收到的数据集。这些数据集是包含大量 XML、图像和 MS doc 文件的 zip 文件。
早些时候，这个脚本使用很少的系统命令（shell、perl、java）来完成它的任务。那时我们没有问题。最近，我们将这些脚本升级为使用 RabbitMQ 进行多个并发调用，从基于 cron 的工作转移到 supervisord 以进行自动恢复和监控，并尽可能使用 php 的核心库和函数来避免 shell 调用。
现在，在部署到生产环境后，我们发现脚本在使用 ZipArchive 创建档案的线路上致命地崩溃了。具体来说，仅在其方法“open”和“addFile”上。我们用有问题的数据集对此进行了多次测试，发现这是真正的问题所在。
抛出的错误是“致命错误：超过 300 秒的最大执行时间”。我们知道 php 对执行时间的限制，我们仔细检查了 php.ini 和“/etc/php5/conf.d”文件夹下的所有设置，并且在任何地方我们都将“max_execution_time”设置为 0。我们还检查了脚本的 sapi模式是使用“php_sapi_name()”的“cli”。ini_get("max_execution_time") 也返回 0。
即使脚本由supervisord管理，上述模式和执行限制也是一样的。我们无法找到这个 300 秒的“max_execution_time”限制是从哪里触发的。
还有一件事，当脚本因这条消息而崩溃时，它实际上运行了 600 多秒。我们也觉得，只有当 ZipArchive 本身耗时超过 300 秒时，才会发生这种情况。但我们不确定。发生这种情况时它创建的部分 zip 存档也在 280 MB 和 290 MB 之间。因此，我们从其存储库下载了 php 源代码，并进行了快速 grep 以查看 ZipArchive 的代码库是否有任何此类限制。我们没有找到。
我们现在正尝试用 shell 命令替换 ZipArchive php 代码作为解决方法。我们还没有测试它。我很快就会在这里发布我们的发现。
你们中有人遇到过这样的问题吗？这与 ZipArchive 有关吗？是否建议使用 ZipArchive 创建大型档案？它在崩溃之前创建的部分 zip 文件在 280 MB 和 290 MB 之间。