Skip to content

Commit

Permalink
更新内存问题相关文档
Browse files Browse the repository at this point in the history
  • Loading branch information
Gavin1937 authored and hiroi-sora committed Jun 30, 2024
1 parent 6bbf2f3 commit ab68748
Show file tree
Hide file tree
Showing 3 changed files with 32 additions and 0 deletions.
6 changes: 6 additions & 0 deletions cpp/README-docker.md
Original file line number Diff line number Diff line change
Expand Up @@ -132,3 +132,9 @@ docker run -d --name mycontainer myimage
## 通过API调用OCR

我们提供了 Python、Java 等语言的API,详见 [README-通过API调用](../README.md/#通过API调用) 。您可以通过这些API的 **套接字模式** 来调用Docker中的OCR服务,向API接口传入容器的IP和暴露端口即可。

## 其他问题

### [关于内存泄漏 / 长期高内存占用](./README.md#关于内存泄漏--长期高内存占用)

如果你打算使用文档中提到的方法2,由于docker镜像在构建时就会自动构建编译整个项目,所以您只需要重新clone一遍本仓库并重新构建一遍docker镜像就行了。
4 changes: 4 additions & 0 deletions cpp/README-linux.md
Original file line number Diff line number Diff line change
Expand Up @@ -305,3 +305,7 @@ CMake会将 `build` 文件夹下的可执行文件和运行库给安装到系统
> [!TIP]
> CMake在安装PaddleOCR-json时,会将所有在 `build/bin` 文件夹下的共享依赖库给复制到安装目录的 `lib` 文件夹下。但是,Linux的很多共享库是被拆分在系统文件夹里的(比如 `/usr/lib/` )。CMake无法自动找到这些共享依赖库。如果你需要将PaddleOCR-json打包成一个无依赖的软件,你需要手动将所需的共享依赖库从系统文件夹里找出并复制到 `build/bin` 文件夹下。这样一来CMake就可以在安装时将完整的共享依赖库一起打包了。
## 6. 其他问题

### [关于内存泄漏 / 长期高内存占用](./README.md#关于内存泄漏--长期高内存占用)
22 changes: 22 additions & 0 deletions cpp/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -189,3 +189,25 @@ cmake --install build
CMake会将 `build` 文件夹下的可执行文件和运行库给安装到 `build/install/bin` 文件夹下。CMake无法在Windows下把软件安装到系统文件夹中,不过你可以将文件夹 `cpp/build/install/bin` 添加到Windows的 `PATH` 环境变量中。参考[这篇文档](https://cloud.baidu.com/article/3297806)

如果你希望安装到指定位置,你可以为上面这条命令加上参数 `--prefix /安装路径/` 来指定一个安装路径。比如 `--prefix build/install` 会将所有的文件都安装到 `build/install` 文件夹下。

## 5. 其他问题

### 关于内存泄漏 / 长期高内存占用

由于本项目是基于 [PaddleOCR v2.6 C++](https://github.com/PaddlePaddle/PaddleOCR/tree/release/2.6) 写的,它的内存占用非常激进。但是占用率不会无限制的上升,达到一定值后会放缓直至停止。官方在 PaddleOCR v2.7+ 之后修复了这个问题,不过本项目在短期内还无法跟进新版本。

当前,可以绕过内存问题的方法有:

1. 外部重启引擎,用另一个程序 / 脚本来监听引擎的输出,然后在引擎不工作时重启引擎进程(Umi-OCR就是这么做的)。
2. 从引擎内部来清理内存。在分支 `autoclean` 里面是一个修改过的引擎。新增了一个参数 `-auto_memory_cleanup`,它会开启一条线程来检查引擎状态,然后在其闲置时释放内存。

> [!CAUTION]
> **但是,这个方法无法清理干净内存里所有的资源,PaddleOCR底层的某些库所调用的资源会一直占用着一小块内存。到最后引擎闲置时的内存占用大约为600MB。这些没有正常释放资源的操作有可能会引发一些问题。**
更多细节请看这些Issue:[#43](https://github.com/hiroi-sora/PaddleOCR-json/issues/43)[#90](https://github.com/hiroi-sora/PaddleOCR-json/issues/90)[#135](https://github.com/hiroi-sora/PaddleOCR-json/issues/135)

如果你打算使用上面提到的方法2,你可以重新clone本仓库的 `autoclean` 分支,然后再自行构建编译整个项目。

```sh
git clone --single-branch --branch autoclean https://github.com/hiroi-sora/PaddleOCR-json.git
```

0 comments on commit ab68748

Please sign in to comment.