【发布时间】：2016-02-13 21:50:17
【问题描述】：
MySQL 5.1.73 阿帕奇/2.2.15 PHP 5.6.13 CentOS 6.5 版 Cakephp 3.1
大约 4 分钟（3 分 57 秒）后，我正在运行的导入过程停止。在我能找到的任何日志中都没有错误或警告。导入过程由大量 SQL 调用和数据处理组成，没什么太疯狂的，但如果要对更新进行全面比较，可能需要大约 10 分钟才能完成 5500 条记录。
Firefox：安全连接失败 - 加载页面时重置了与服务器的连接。 Chrome：ERR_NO RESPONSE
- php 设置时间限制设置为 900，正在工作。我可以将其设置为 5 秒并得到一个错误。未达到限制。
- 我可以让另一个控制器休眠 10 分钟，并且这个错误没有发生，这表明实际程序中的某些东西导致它失败，而不是托管服务因为它花费的时间太长而终止了请求（阅读有关 VPS 做这是为了防止垃圾邮件）。
- php 错误在 php.ini 中一直向上出现，只是为了确定，在控制器本身中。
- 如果我减小要导入的文件的大小，则导入过程完成。如果它足够长，它将完成并显示浏览器消息。这向我表明它不是每次都在同一执行点失败。
- 我已删除所有缓存并重新启动服务器。
- 除了发出请求之外，我在 apache 日志中看不到任何输出。
- 我在mysql日志中没有看到任何错误，但是我不知道是不是因为它没有打开。
- 完全相同的代码在我的本地主机上运行没有任何问题。这不是服务器的完美匹配，但它很接近。 Ubuntu Desktop vs Centos，php 5.5 vs php 5.6
- 我一直关注内存使用情况，没有发现任何问题。
此时，我正在寻找有关其他方面的任何好的建议或对可能导致失败的原因的见解。有很多可能的地方可以查看，而且如果没有错误，很难缩小问题的可能范围。提前感谢您的任何建议！
更新
仔细查看请求期间的内存使用情况后，我注意到它比理想情况下要高得多。
httpd (apache) 进程被杀死并产生了一个新线程。一旦新线程内存不足，错误就会出现在屏幕上。当我之前查看它时，它只有 30%，可能是因为它刚刚杀死了旧进程。全程观察，我看到它高达 80%，这与其他进程一起足以让它耗尽内存，并且被杀死的进程无法记录任何内容，因此没有错误或警告。令我感兴趣的是，该过程刚刚开始备份。
我发现了一个命令来显示哪些进程由于内存而被杀死，这被证明非常有用：
dmesg | egrep -i '杀死进程'
【问题讨论】：
-
那么，服务器没有崩溃？崩溃后可以立即访问吗？
-
您说“完全相同的代码在我的本地主机上运行没有任何问题。”你在共享主机上吗？您确定 900 秒的最大执行时间在此服务器中有效吗？你能验证一下apache是否实现了超时吗？
-
崩溃后可以立即访问服务器。但是，当我尝试从不同的选项卡访问不同的页面时，它会等到初始导入请求完成后再响应。我认为这是因为发出请求的是同一个会话。
-
这不是共享主机，它是私有的，只有一个应用程序。我确保超时正常工作的测试是将其设置为低于 4 分钟并查看 php 错误。 apache 配置中有超时，但都远低于 4 分钟。
-
原来是内存问题（请参阅主帖中的更新）。随着记录集随着时间的推移而增长，我最终可能会选择小批量，以减少发生这种情况的机会。理想情况下，虽然我想摆脱对快速开发很有用的 Cakephp ORM，但除非得到密切管理，否则效率极低。