有一个项目需求，要在每天凌晨5点的时候执行一个任务，获取一系列的PDF文件并解析。

后端是Django框架，定时任务用Celery来实现的。

本地跑没什么问题，但是一放到服务器上跑就会宕机，而且是毫无征兆的宕机，至少在宝塔面板上看到的宕机前的负载、CPU使用率和内存占用率还是正常的。

一开始以为是Celery的问题，但是排查了很久都没发现有啥问题，尤其是这个脚本在本地是可以跑的。

于是我就不通过Celery，手动执行了一下这个脚本，通过逐行打印的方式，定位到了问题函数。

    def process_pdf(self):for i in range(len(self.pdf.pages)):print(f"正在处理第 {i} 页……")page = self.pdf.pages[i]self.extract_text_and_tables(page)

这个函数就是遍历PDF的每一页，然后提取这一页的文本和表格。

在执行这个函数的过程中，通过 htop 命令实时观察内存占用，发现随着处理的页面越来越多，占用的内存也越来越多，直到服务器完全卡住，宕机了。

所以问题就很明显了，服务器的资源不够，内存占满了，所以才导致了宕机。

我是通过 pdfplumber 加载的 PDF 文件，所以自然而然的去 pdfplumber 的 GitHub 上看看有没有人遇到类似的问题，果然找到了一个。

Memory issues on very large PDFs

其中提到了一些方法，综合了一下，修改代码如下。

    def process_pdf(self):for i in range(len(self.pdf.pages)):print(f"正在处理第 {i} 页……")page = self.pdf.pages[i]self.extract_text_and_tables(page)# 清理缓存，避免内存泄漏# https://github.com/jsvine/pdfplumber/issues/193del page._objectsdel page._layoutpage.flush_cache()gc.collect()

问题解决！

---

其实一开始也想到了可能是机器资源不行，毕竟是比较低配的机器，还抱怨过要是有钱买服务器就好了。

但是发现问题并解决问题之后，更多的其实是有一些羞愧，自己还是太菜了，代码有漏洞。

再想想当年阿波罗登月的时候，计算机内存只有几十 KB，就这样人家都能上月球，现在服务器内存都 2G 了，还不知足。

菜就多练，今天这次之后，处理这种大文件就记得要关注内存泄漏的问题了。