部署问题 - Githubissues

xzm123456 commented 3 months ago

能不能简化部署方式，目前的部署方式尝试一遍没有成功，然后不好排查原因出在哪里？希望采纳，简化流程，将所有包、文件在一个项目下，直接下载，然后执行命令部署。

hiroi-sora commented 3 months ago

你好。想要简易部署，有个最简单的办法：

下载发行版，确保发行版能跑起来。 https://github.com/hiroi-sora/Umi-OCR/releases
clone主仓库。 git clone --single-branch --branch main https://github.com/hiroi-sora/Umi-OCR.git
将发行版目录中全部内容复制粘贴到主仓库目录中（不覆盖原有内容）。

xzm123456 commented 3 months ago

3. 原有

我是在docker镜像中部署的，缺少qt的相关库，虽然用ldd排查了，但是还是运行出错。出错时，是改用了第二种环境的方案，请问作者大大，你有用docker的方式试过吗？

xzm123456 commented 3 months ago

你好。想要简易部署，有个最简单的办法：

下载发行版，确保发行版能跑起来。 https://github.com/hiroi-sora/Umi-OCR/releases

clone主仓库。 git clone --single-branch --branch main https://github.com/hiroi-sora/Umi-OCR.git

将发行版目录中全部内容复制粘贴到主仓库目录中（不覆盖原有内容）。

我又试了一下，直接dockers pull ubuntu ,然后在这个镜像上试了这个方法。python运行环境，方式二显示我缺少包，但是到导入了；方式一又说我QT的问题，是docker的原因吗。。。

hiroi-sora commented 3 months ago

不好意思，我还没有试过docker部署的方式。

QT问题，大概率是缺少依赖库。参考： https://github.com/hiroi-sora/Umi-OCR/issues/447#issuecomment-2226950867

xzm123456 commented 3 months ago

不好意思，我还没有试过docker部署的方式。

QT问题，大概率是缺少依赖库。参考： hiroi-sora/Umi-OCR#447 (comment)

h好像不是这个问题，我去提个建议，docker化部署，哈哈哈哈哈哈哈。

hiroi-sora commented 3 months ago

已基本实现Docker部署，见文档：

Docker部署文档

xzm123456 commented 3 months ago

已基本实现Docker部署，见文档：

Docker部署文档

感谢博主的帮助，我已经尝试并成功部署。此外，想请教下博主，我发现一个奇怪的问题。在window下，直接运行umi，ocr速度很快，但是使用docker运行时，速度骤降，在10s左右才能识别，目前在排查原因。

hiroi-sora commented 3 months ago

使用docker运行时，速度骤降，在10s左右才能识别

我估计可能的原因：

机器性能差异：你的windows电脑的CPU，比你部署docker的主机的CPU要好。CPU性能对OCR速度影响很大。
核心数错误设置：Umi-OCR默认自动获取CPU的核心数量，设置OCR可用线程。但是可能因为虚拟化屏蔽了一些硬件信息，导致容器内未获取正确的核心数。比如CPU本身有8核16线程，但OCR自动设置了2线程，导致未能充分发挥CPU性能。

你可以：

如果能打开GUI的话，去全局设置→文字识别→PaddleOCR，看看线程数是否正确（应设为电脑可用线程数），MKL加速是否已开启。

如果不能打开GUI，那么进入容器的命令行，打开文件 /app/UmiOCR-data/.settings ，检查以下设置项是否正确：

[Global]
ocr.linux_x64_PaddleOCR-json_v140_beta.cpu_threads=16 （应设为电脑可用线程数）
ocr.linux_x64_PaddleOCR-json_v140_beta.enable_mkldnn=true

xzm123456 commented 3 months ago

使用docker运行时，速度骤降，在10s左右才能识别

我估计可能的原因：

机器性能差异：你的windows电脑的CPU，比你部署docker的主机的CPU要好。CPU性能对OCR速度影响很大。

核心数错误设置：Umi-OCR默认自动获取CPU的核心数量，设置OCR可用线程。但是可能因为虚拟化屏蔽了一些硬件信息，导致容器内未获取正确的核心数。比如CPU本身有8核16线程，但OCR自动设置了2线程，导致未能充分发挥CPU性能。

你可以：

如果能打开GUI的话，去全局设置→文字识别→PaddleOCR，看看线程数是否正确（应设为电脑可用线程数），MKL加速是否已开启。

如果不能打开GUI，那么进入容器的命令行，打开文件 /app/UmiOCR-data/.settings ，检查以下设置项是否正确：
[Global]
ocr.linux_x64_PaddleOCR-json_v140_beta.cpu_threads=16 （应设为电脑可用线程数）
ocr.linux_x64_PaddleOCR-json_v140_beta.enable_mkldnn=true

性能问题很神奇的好了。但是遇到了其它问题，在启动是添加了参数 -e HEADLESS=true，还是遇到了No native systemtrayicon implementation available这个问题。难道进入容器后，也不能直接启动 umi-ocr.sh，需要修改global配置后再启动吗？另外我发现了一个docker 使用时可能遇到的问题，debian:12-slim版本太高，容易下面的问题。所以建议docker中的debian建议改成11的，就不会遇到了。 “docker版本过低（version 20.x）而容器对应的基础镜像版本过高,如Ubuntu22.04、Debian12等，执行程序时程序无法多线程执行。”

hiroi-sora commented 3 months ago

添加了参数 -e HEADLESS=true，还是遇到了No native systemtrayicon implementation available这个问题

如果启动 run.sh 时，有如下的报错：

ERROR: No native SystemTrayIcon implementation available.
Qt Labs Platform requires Qt Widgets on this setup.
Add 'QT += widgets' to .pro and create QApplication in main().

ERROR: No native Menu implementation available.
Qt Labs Platform requires Qt Widgets on this setup.
Add 'QT += widgets' to .pro and create QApplication in main().

不过，最后能够正常启动服务：

Listening on http://0.0.0.0:1224/

那么不需要管这个报错。报错的前端组件不会影响后端的HTTP服务。

debian:12-slim版本太高，容易下面的问题

OK，我之后会调整一下。

hiroi-sora / Umi-OCR_runtime_linux

部署问题 #2