我确定StackOverflow中是否允许这种Q，但我主要是在寻找建议。
我有一个网络应用程序，它接受PDF上传，将它们转换为TIFF，然后使用Tesseract对其进行OCR。
这些 PDF 的长度为 50 - 200+ 页。我的服务器为少于 6 页的 PDF 完成此操作。
生成的 TIFF 为 1.2GB。PDF只有98KB。我们有一些 PDF 已经有数百 MB，所以谁知道它们一旦转换后最终会变成什么样子。这个大小似乎不对，但现在让我们把它放在桌子上。
一旦我们开始谈论 200 页的 PDF，就什么都行不通了。我收到错误：
exec(): Unable to fork [tesseract '/home/forge/default/storage/app/ocr/1.tiff' /tmp/tesseractbO7aur -psm 3 2>&1]
TIFF转换工作正常，即使对于大型PDF。但是当PDF超过~6页时，Tesseract总是给出这个错误。
也许我只是需要更多的内存。我的问题是：
如何确定命中的极限/最大值是多少？我怎么知道这是 RAM 问题、CPU 问题还是其他问题？
你会如何运行这个？我应该将其保留在我们的 Web 服务器上并显着提高规格吗？或者你会制造另一台专门用于生产 OCR 的机器吗？他们不需要即时响应用户事件 - 如果他们上传并且 OCR 甚至需要几个小时也没关系。我习惯了需要大量功能的应用程序，只是需要很长时间，而不是完全死亡。我可以接受 OCR 需要很长时间，只要该过程不会失败。
我只在用户发出请求并显示页面的简单 Web 应用程序上工作过。我不习惯这种东西。我正在为该应用程序使用 Laravel，因此如果应该使用它们，我可以访问 Redis 队列等。我在 AWS 上使用 Nginx。我确实考虑过 AWS Lambada，但我认为这不能实现我需要的。
谢谢，我希望有人能帮忙。
山 姆
我怀疑这与PHP无关。
首先，您需要确保您可以直接在命令行上在 Tesseract 中实际运行此过程。
打开两个SSHsesssions，在一次运行类似htop的内容来监视服务器资源，然后在第二次尝试手动运行转换过程。
如果您看到资源使用率和平均负载在 htop 中疯狂，那么您就知道您需要一个更强大的服务器，或者找到一种更有效的方法来运行任务。
只有当您知道它将在命令行上手动工作时，您才应该尝试通过 PHP 使其工作。
即使使用 PHP，我也会建议使用某种作业队列来调度转换任务。
我通过在一个巨大的AWS EC2实例上运行它来解决这个问题。较小的 EC2 实例也会遇到同样的问题。通过转换运行 500 页的 PDF 和 OCR 在计算优化的 c4.4xlarge (600 美元/月(上工作。