ezpdf php 使用 100% cpu 使用率
我有一个问题。我正在使用 class.ezpdf.php 创建一个 PDF，并在浏览器上打开该 PDF。此 PDF 由事件组成，这些事件是 snort 检测到的项目。我列出了每个事件的某些标准。当事件数量达到数千时，最终无法创建 PDF。
它会在那里停留一两分钟，然后不会打开 PDF，而是询问我是否要打开或保存用于创建 PDF 的 php 文件，但该文件是空的。 PDF 从未创建。与此同时，我在我的盒子上运行了 top 命令，我可以看到当它尝试处理时，进程 php.fcgi 正在使用 100% 的 cpu。
即使出现保存/打开框以获取 php 文件并且我关闭此框后，它仍继续显示 100% 正在使用几分钟。看来我必须关闭正在运行该脚本的浏览器才能释放此进程。我不知道该怎么办。曾经有一个 Perl 脚本在获取事件并将其放入 PDF 中执行相同的操作，但是这个问题并不存在，即使对于包含这么多事件的 PDF 也是如此。
任何帮助将不胜感激。
提前致谢。
I have a question. I am using class.ezpdf.php to create a PDF that I am pulling up on my browser. This PDF is made up of events, which are items that are detected by snort. I am listing certain criteria for each event. When the amount of the events gets into the thousands, the PDF ends up not being created.
It will sit there for a minute or 2, then will instead of opening the PDF, it will ask if I want to open or save the php file I am using to create the PDF, but the file is empty. The PDF is never created. In the meantime, I have run the top command on my box and I can see while this is trying to process, the process php.fcgi is using 100% cpu.
Even after the save/open box comes up for grabbing the php file and I close this box, it continues to show 100% is being used for several minutes. It seems that I have to close my browser that was running that script for it to release this process. I am at a loss on what to do. There used to be a perl script that did the same thing in regards to taking the events and putting them into a PDF, however this issue did not exist, even for a PDF that would contain this number of events.
Any help would be appreciated.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来您正在使用的 Web 服务器在等待 FastCGI 进程给出响应时超时。它可能会向您提供可能存在的任何数据（在本例中是导致下载的标头），然后关闭连接。
您需要查阅 Web 服务器文档来查找 FastCGI 超时并根据需要增加它。
It sounds like the web server you are using is timing out while waiting for the FastCGI process to give it a response. It's probably giving you whatever data might be present -- the headers causing a download, in this case -- then just closing the connection.
You will need to consult your web server documentation to find the FastCGI timeout and increase it as needed.