把 Stirling-PDF 这台"PDF 处理全家桶"跑在自己租用的服务器上，和把它当成一台轻量级 Web 应用来对待，是两件完全不同的事。真正动手部署过的人都会发现一个反差：它在功能上几乎能替代一整套商业 PDF 工具，但底层并不是一个单一的、省内存的脚本，而是一个常驻的 Java 后端、一个独立的 LibreOffice 转换守护进程、一套 OCR 引擎，外加一个前端站点拼起来的小舰队。当你谈论"租用一台服务器来跑它"时，你其实是在为一套有状态、吃内存、转码时陡然拉高 CPU 的服务组合做容量规划。
本文不堆砌营销话术，也不给出任何虚构的跑分数字或报价。我们基于 Stirling-PDF 的公开技术栈、官方性能文档与社区部署经验，逐一拆开它在服务器租用场景下的六个硬件维度——CPU、内存、SSD、带宽、电力、机位与部署形态，并给出可落地的选型与避坑建议。凡是无法从公开来源确认的结论，文中一律标注为"需结合实测"或"以官方文档为准"，不替你下确定性的判断。
先说清楚一件事：Stirling-PDF 不是给偶尔合并一次 PDF 的个人用户准备的。它的价值在"把敏感文档留在自己可控环境里"这个前提上才成立。典型会把它搬上自建服务器的，是这么几类角色。
第一类是处理涉密或受监管文档的团队：律所的案卷、金融机构的信贷与 KYC 材料、医疗机构的病历、工业企业的图纸与技术手册。这些材料一旦上传到第三方在线 PDF 网站，就脱离了企业的安全边界，而 Stirling-PDF 的官方卖点恰恰就是"文档不出域、可完全离线运行（air-gapped）"。对这类用户而言，服务器租用的核心诉求不是便宜，而是可控、可审计、数据不出本地网络。
第二类是已经有一套内部文档中台或自动化流水线的工程团队。Stirling-PDF 把几乎每一个工具都暴露成 REST API，合并、拆分、压缩、加水印、转图、OCR 都有独立端点，还可以用 Pipeline API 把"上传一次、连续跑多个步骤、下载一次"串起来；它还内置了一个默认关闭的 MCP 服务，让 AI 智能体也能驱动它。当 PDF 处理成为某个业务流程的环节，把它部署在离业务系统最近的服务器上， latency 和隐私都更稳。
第三类是提供 SaaS 或对外文档处理能力的服务商。他们要的不是"一台能跑的机器"，而是可水平扩展、可接外部数据库、可上集群的多实例形态。这种场景对服务器配置、带宽与运维的要求，和单人自用完全不在一个量级。
如果你只是偶尔转一个文件，浏览器里用官方或开源的网页版就够了；但一旦"文档不能出网"或"要批量自动化"，自部署就变成刚需，而服务器怎么选就成了成本与稳定的分水岭。
理解技术栈，是理解它为什么"吃资源"的前提。根据对仓库结构、构建文件与官方文档的公开梳理，Stirling-PDF 的核心后端是一个基于 Spring Boot 的 Java 应用，运行在较新的 JDK 上，底层 PDF 操作以 Apache PDFBox 为主引擎；Office 与 PDF 之间的互转则依赖一个独立的 LibreOffice 守护进程 unoserver，通过本地 socket 调用，而不是在请求时临时起一个 LibreOffice 进程；OCR 走 Tesseract（经 OCRmyPDF 封装）；压缩、线性化、转图、电子书转换还会用到 qpdf、Ghostscript、ImageMagick、Calibre 等外部工具；此外还有一个用 Python（FastAPI）实现的 AI 引擎服务，以及一套独立的 TypeScript/React 前端。
这意味着"一个 docker run"背后，生产形态其实是一组协作的进程：JVM 后端常驻内存、LibreOffice 转换池常驻、OCR 引擎按需拉起、前端站点提供交互。官方镜像也确实拆分出 backend、frontend、base、unoserver、embedded 等多个构建目标，证实了这不是单容器童话。
关键的运行模型特征有三个。其一，JVM 常驻且会自己占住真实内存，即便空闲时也比轻量容器高得多，所以你不能拿"静态站点"的尺度去给它配内存。其二，官方 Docker 镜像会依据容器内存上限自动设置 Java 堆，通常取到上限的约七成，剩下约三成留给 LibreOffice、Tesseract 等外部工具——所以"给容器设内存上限"不是可选项，而是让 JVM 正确自适配的前提。若不设上限，它会按宿主机总内存去算堆，极易把整台机器拖垮。其三，各类工具的资源消耗差异极大：合并拆分是轻操作、随文件总大小增长；OCR 是 CPU 与内存双高且极度吃 CPU；Office 转换每个实例大致单线程、单核跑、内存也高；PDF 转图属于中等 CPU 但内存极高；压缩、PDF/A 转换是中等 CPU、偏高内存。这个差异直接决定了后面六个维度该怎么权衡。
先说结论的边界：单文档转码的精确耗时与具体硬件强相关，公开资料没有给出一个可照搬的"某 CPU 跑某文件要几秒"的权威基准，所以本文不编造数字，只谈可验证的规律与参数杠杆。
CPU 维度真正要盯的不是"核数越多越好"这种空话，而是"转码队列的并发上限该设多少"。Stirling-PDF 内部用 ProcessExecutor 模式管控每个工具的并发与超时，并通过环境变量给 LibreOffice、Tesseract 等设会话上限，比如控制 LibreOffice 同时转换数的 PROCESS_EXECUTOR_SESSION_LIMIT_LIBRE_OFFICE_SESSION_LIMIT，以及控制 Tesseract 并发的相应上限。这些上限本质上就是你的"转码队列宽度"——它和 CPU 核数必须匹配。
把规律讲透：Office 转换是单核密集型，一个转换大致占满一个核，所以若你设了 4 个 LibreOffice 会话上限，就需要至少 4 个空闲核才能让它真正并行，否则它们只是在内核调度层面轮流，实际吞吐上不去。OCR 则是更狠的 CPU 消耗，Tesseract 对扫描页做图像分析，单任务就能把一两个核吃满，并发一高整台机器都会变卡。PDF 转图中等 CPU 但渲染时内存暴涨，和 CPU 的关系是"核够用即可，瓶颈常在内存"。
因此 CPU 选型的取舍很清楚：如果你的主力场景是合并拆分（低 CPU），两到四核就够；如果以 Office 互转或 OCR 为主，核数要按"期望并发数 × 单任务占核"来倒推，并留出富余给系统、JVM 与前端。实战上，社区普遍反馈 OCR 与批量转换阶段 CPU 会被明显推高，所以这类负载应直接按高 CPU 档位去租，而不是按"平时很闲"的平均态去配。另外，给容器设 CPU 上限（如 deploy.resources.limits.cpus）能防止单个异常任务把整机拖死，是租服务器时必须一起配的护栏。
内存是 Stirling-PDF 在自部署里最容易翻车的地方，原因在于它的"内存放大"特性。官方性能文档有明确说法：单个大 PDF 在处理期间会膨胀到文件体积的数倍常驻内存；一个带复杂矢量图、嵌入字体、多页的 50 MB PDF，处理时可能涨到 200 至 500 MB 内存。更麻烦的是，它按文件大小分层加载：小文件全进内存、中文件部分落盘、超大文件才主要走磁盘——一旦系统可用内存跌破阈值，所有操作会被强制切到磁盘模式，速度骤降。
JVM 堆的设定逻辑必须记牢：官方镜像会依据容器内存上限自动分配堆，约取上限的七成。例如容器限 4 GB，堆大约 2.8 GB，剩下约 1.2 GB 给 LibreOffice、Tesseract 等。如果你发现重载下容器频繁停掉，官方给出的对策是显式把堆降下来，比如用 JAVA_CUSTOM_OPTS 设 -XX:MaxRAMPercentage=50，给外部工具多留空间；也可以直接给固定堆，如 -Xmx2g。注意官方明确提示不要依赖会被镜像覆盖的 JAVA_TOOL_OPTIONS，容器里应通过正确的环境变量或挂载的启动命令来传 JVM 参数。
避坑要点：第一，务必给容器设内存上限，否则它按宿主机总内存算堆，平均一台 32 GB 的机器可能被它吃掉大半，其他进程直接饿死。第二，内存上限至少应是 -Xmx 的 1.5 倍，给 LibreOffice、Tesseract 腾地方。第三，按"最大并发数 × 单任务内存峰值"来预留，而不是按单任务。举例（仅为示意，非官方承诺）：若你希望同时跑 4 个 OCR、每个峰值约 0.5 GB，加上 JVM 堆与系统开销，起步就该往 8 GB 以上看，重度场景 16 GB 才稳。第四，官方给出过按用户量的参考区间：1 到 10 人约 2 至 4 核、4 GB 内存、10 GB 磁盘；10 至 50 人约 4 至 8 核、8 至 16 GB、50 GB（建议 SSD）；50 人以上约 8 核以上、16 GB 起、100 GB 以上 SSD。这些数字来自官方文档，仅作容量规划起点，实际仍要以你的真实文件大小与并发为准。
很多人以为 PDF 处理是纯内存活，其实临时文件才是隐形杀手。合并、拆分、Office 转换、OCR 中间产物都会在磁盘上落盘；Stirling-PDF 的临时目录常见为 /tmp/stirling-pdf（可通过 -Djava.io.tmpdir 自定义），镜像内还有 /configs、/customFiles、/logs、OCR 训练数据 /usr/share/tessdata、以及流水线目录 /pipeline 等需要持久化的挂载点。租服务器时磁盘这一维要分两层看。
第一层是"速度"。转换与 OCR 中间文件频繁读写，机械盘会明显拖慢整个队列。官方在容量建议里对 10 人以上场景直接写"SSD 推荐"，对 50 人以上写"SSD 强烈推荐"，这不是营销，而是因为随机小文件读写密集。更进一步的优化是把临时目录挂成 tmpfs（内存盘），社区实践中把 /tmp/stirling-pdf 用 tmpfs 挂载、配 1 GB 大小，可显著拉升大文件处理的 IO；但 tmpfs 吃的是内存，必须和上面的内存预算一起算，否则就是拆东墙补西墙。
第二层是"持久化与空间"。/configs、/customFiles、OCR 的 tessdata、日志目录都应映射到宿主机卷，否则容器一删，字体、水印、配置、OCR 语言包全没。磁盘余量要按"并发任务数 × 单任务峰值临时占用 + 仓库文件"来留，官方对 10 至 50 人给了 50 GB、50 人以上 100 GB 以上的参考，重度批处理建议在此基础上再加缓冲。租用机器时别只盯 CPU 内存，SSD 容量与 IOPS 同样要写进配置单。
租用机器时别只盯 CPU 内存，SSD 容量与 IOPS 同样要写进配置单。一个容易踩的误区是只看了"系统盘 50 GB 够不够"，却没问清这块盘是共享带宽的云盘还是本地 NVMe、随机读写 IOPS 上限多少。PDF 转换与 OCR 的临时文件特征正是大量随机小文件读写，云盘一旦被邻居挤占或被限速，队列会莫名其妙地变慢，排查时却又看不出 CPU 内存的问题。所以选盘时把"随机 IOPS"和"是否为独享本地盘"问清楚，比单纯看容量数字更有意义。
另一个细节是 OCR 的 tessdata 语言包体积不小，且会随你支持的语言数量线性增长，若只处理中文，就只挂载中文字包，避免把十几种语言包全拉下来白白占盘、也拖慢镜像首次拉取。还有，把临时目录走 tmpfs 本质是把内存当盘用，前面内存预算已强调要一起算，别为了提速反而把堆挤爆。
带宽这维容易被低估，因为它不像 CPU、内存那样会"当场崩"。Stirling-PDF 的前端用 PDF.js 在浏览器里渲染文档，处理前后文件都要在客户端与你的服务器之间来回传。换算逻辑很朴素：一份 50 MB 的 PDF 上传进来、处理完再下载回去，单趟就是一个来回 100 MB 流量；如果一天有几十人次的批量操作，月流量轻松到数百 GB 甚至 T 级。
带宽选型的取舍取决于访问来源。若用户都在同一内网或同一办公网，租一台有内网互通的机器、走内网交互，对外带宽几乎不消耗，成本低且延迟小。若要对公网多地点提供服务，就要看"单用户平均文件大小 × 并发上传/下载数"来估峰值带宽，并考虑预览流是持续读取而非一次性传输。这里还有一层安全与成本耦合：把 Stirling-PDF 直接裸奔在公网 8080 端口，既不安全也容易被扫，正确做法是用反向转发（如 Nginx/Caddy）收口并配 TLS；而反向转发和源站之间的内网传输，又不该占用你的计费公网带宽。
价格提醒：IDC 服务商对带宽的计费方式有"按固定带宽""按流量计费""共享/独享"等多种，且不同服务器、不同线路单价差异很大。凡是涉及具体单价、套餐价，本文一律不虚构，只建议你把"预估月流量"和"峰值带宽"两项算清楚后，再去对比各家公开报价或示例价格，最终以官网实时或咨询确认为准。
电力这维对租用场景的直接意义，在于它和"计费形态"绑在一起。租用独立服务器（裸金属）通常按月或按年计费，电费已含在机柜与托管成本里，你不必像自建机房那样单独算每度电；但如果你考虑的是把一台小主机放家里或放办公位长期开机，那 7×24 的功耗就得自己买单，这时选低 TDP 的 CPU、少风扇、低待机功耗的主板才有意义。
回到 Stirling-PDF 的负载特征：它是常驻服务，JVM 不休眠，LibreOffice 转换池也常驻，所以"闲时"并非零占用，而是维持一个基线内存与少量 CPU。真正拉高功耗的是转码与 OCR 的高峰——CPU 满载时整机能效比明显下降。因此电力维度的取舍是：租用场景优先看"月费是否含电、是否含冗余电源与散热"，而不是单看标称功耗；若是自购硬件长期开机，则要把"日均运行小时数 × 待机功率 + 高峰时长 × 峰值功率"折算成电费，再和租一台低配云/物理机的月费比，往往后者更省心。
一个常被忽略的点：散热与稳定性。CPU 在 OCR/转换高峰持续满载，如果机器散热不行会降频，反而拖慢队列。租用具备良好机房空调与冗余供电的服务器，比在家里用消费级设备硬扛更稳，这也是"电力"这一维在托管语境下的真实含义。
补充一句关于计费透明度：租用前务必让服务商把"月费含不含电、含不含公网带宽、超流量怎么计、是否锁合约期"写清楚。PDF 批处理是流量与算力双高场景，含糊的计费条款在月底账单上最容易爆雷，比机器本身的选择更值得提前确认。
CPU 在 OCR/转换高峰持续满载，如果机器散热不行会降频，反而拖慢队列。租用具备良好机房空调与冗余供电的服务器，比在家里用消费级设备硬扛更稳，这也是"电力"这一维在托管语境下的真实含义。"机位"在这里指你的服务落在什么形态上：独立服务器、云主机、还是容器平台。不同形态对 Stirling-PDF 的部署细节影响很大。
端口与暴露：Stirling-PDF 默认监听 8080，Docker 映射通常是 8080:8080。把它直接对公网开放 8080 是常见雷区——既无传输层加密，又暴露了技术指纹，容易被扫描与试探。正确做法是前面套一层反向转发，对外只暴露 443（HTTPS），把 8080 留在内网或仅本机。官方与社区都明确建议：Stirling-PDF 负责 PDF 活，传输安全交给反向转发的 TLS。若需要 SSO、审计日志等企业要件的 HTTPS 与身份集成，属于其付费/企业层能力，规划时要确认你是否真的需要，以及所选镜像/方案是否包含。
部署形态的选择：单容器 embedded 镜像最省事，把转换服务与 JVM 打包在一起，适合个人或小团队，代价是镜像更重、隔离更弱；生产侧更推荐把 backend、unoserver、前端拆开，用 Docker Compose 或 Kubernetes 编排，既方便单独扩 LibreOffice 池，也方便做健康检查（Spring Boot Actuator 的健康端点可接 healthcheck）与自动重启（restart: unless-stopped，官方特别提醒：内存耗尽时容器会停、在跑任务全失败，所以自动重启必须开）。多实例水平扩展则要外部数据库与会话亲和等支持，属于企业层能力。
机位维度的选型结论：个人/小团队选一台带 root 权限的云主机或轻量独立服务器即可，把 8080 收进反代；企业多实例选能挂共享存储、可编排容器、具备外部数据库选项的环境。无论哪种，反向转发、TLS、自动重启、卷持久化这四件事缺一不可。
很多人在"租服务器自建"和"直接用 SaaS"之间纠结，本质是拿"可控与隐私"换"运维与成本"。这里用几个硬维度做权衡，不替你拍板。
隐私与合规：自部署的核心优势是文档不出域，可完全离线、可审计，适合受监管行业；SaaS 则要把文件传出去，对涉密场景基本一票否决。
运维负担：自部署意味着镜像拉取、反代配置、版本升级、卷备份、监控告警全是你自己的事；SaaS 是打开即用。Stirling-PDF 的官方也提供托管 SaaS（含免费层与按自动化额度计费的付费层），对个人用户很友好。
成本结构：SaaS 按用户/额度付费，轻度使用可能更便宜；自部署要付服务器月费 + 带宽 + 你的运维时间，重度批量反而可能摊薄单价。但注意其开放核心（open-core）模式：核心 50 余个工具自部署永久免费，SSO、外部数据库、集群、审计等才是付费/企业能力——所以"免费用"和"企业级用"不是一回事。
能力边界：需要 MCP/AI 引擎、本地大模型、批量自动化时，自部署能跑满；只偶尔转文件，SaaS 足够。一句话取舍：涉密、批量、要接入业务系统→自部署；轻度、偶尔、怕运维→SaaS。本文站位是前者，所以下面聚焦租用服务器的选法。
还有一层隐性成本容易被忽略：版本升级与回滚。Stirling-PDF 迭代很快，新版本会带来新工具、新依赖甚至镜像结构变化；自部署时你得自己评估升级风险、备份卷、必要时回退。SaaS 把这层也兜走了，但代价是你就失去了对版本节奏的完全掌控。所以"谁来做运维"这个问题，本质上决定了你选哪条边：团队里有人能管 Docker、能看日志、能配反代，自部署才划算；否则 SaaS 的订阅费其实是在买省心。
下表汇总公开可见的几类 Stirling-PDF 镜像与部署形态，从资源占用、能力、适用场景三个可验证角度做对比。表中"磁盘体积""内存占用"等来自社区与官方镜像描述的公开区间，属参考区间而非承诺值；具体以你拉取的标签与运行实测为准。
| 方案 / 镜像 | 典型内存占用 | 转码能力（Office/OCR） | 磁盘体积与隔离 | 适用场景 |
|---|---|---|---|---|
| 标准版 latest（多架构官方镜像） | 约 4 GB 级起，随容器上限自适配堆 | 含 LibreOffice 与 Tesseract，能力最全 | 镜像较大（公开描述约 4 GB），单容器 | 大多数生产环境、功能最均衡 |
| 精简版 ultra-lite | 明显更低（社区称内存占用可降约六成） | 移除非核心能力，无 OCR/Office 转换 | 体积更小（公开描述约 2 GB） | 仅合并拆分压缩等轻操作、低配机器 |
| 全功能版 fat | 最高，含 AI 引擎资源 | 含 AI/扩展能力，转码最全 | 最大（公开描述 6 GB 以上） | 企业级、需本地 AI 与扩展的场景 |
| 拆分部署（backend + unoserver + 前端） | 可分别限内存，整体弹性更好 | LibreOffice 池可单独扩容并行 | 多容器，隔离强、运维略复杂 | 有并发转换压力的生产系统 |
| 嵌入式 embedded（单镜像打包） | 合并后偏高，隔离弱 | 内置转换服务，开箱即用 | 单容器最省事、镜像偏重 | 个人/小团队快速上线 |
选哪一档，直接回到你的真实负载：只做轻量处理、机器小→ultra-lite；要 OCR 与 Office 互转、求稳→standard；要 AI/企业能力→fat 或企业方案；有并发转换高峰→拆分部署把 unoserver 单列并扩会话上限。
把社区踩过的坑集中讲一遍，能帮你省掉至少一晚的排障。
雷区一：不设容器内存上限。后果是 JVM 按宿主机总内存算堆，机器被吃满、隔壁容器或宿主进程饿死，重载时 Stirling-PDF 自己也会因外部工具没内存而崩。护栏是 deploy.resources.limits.memory 必设，并让堆约为其七成、至少留三分之一给外部工具。
雷区二：OCR/转换高峰容器频繁停止却没开自动重启。官方明确：内存耗尽时容器会停、在跑任务全失败，所以 restart: unless-stopped 要常开，并配合 Actuator 健康检查的 healthcheck。
雷区三：临时目录没挂持久化或没用 SSD。合并/转换/OCR 的中间文件落盘，机械盘拖慢队列；/configs、/customFiles、tessdata、日志不映射卷，容器一删配置字体全丢。正确做法是用 SSD、把必要目录挂宿主机卷，重 IO 场景可把临时目录挂 tmpfs（但要算进内存预算）。
雷区四：直接公网暴露 8080。无 TLS、暴露指纹、易被扫。务必反代收口到 443、8080 留内网，传输安全交给反向转发。
雷区五：用错 JVM 参数入口。官方提示不要依赖会被镜像覆盖的 JAVA_TOOL_OPTIONS，应通过 JAVA_CUSTOM_OPTS 或正确挂载的启动命令传 -Xmx/-XX:MaxRAMPercentage 等。
雷区六：按"平均态"配机器。闲时很闲、OCR 批量一来 CPU 内存同时飙，按平均值配必然翻车。要按峰值并发 × 单任务峰值来留余量。
雷区七：忽略版本与许可证边界。早期版本曾有过 SSRF、XSS 等漏洞（部分已在后续修复），所以及时升级、关注安全公告是运维的一部分；同时开放核心模式下部分能力（SSO、外部数据库、集群、审计）属于付费/企业层，别假定"开源镜像里全都有"。
雷区八：把日志与健康检查当摆设。Stirling-PDF 暴露 Spring Boot Actuator 健康端点，不接 healthcheck 就发现不了"进程活着但服务不可用"的假活状态；不收集日志就无从定位是 OCR 慢、是磁盘满、还是 LibreOffice 池耗尽。租服务器省不下可观测性这一份投入，至少把健康检查和日志持久化卷配齐，出事时才能快速判断该扩容还是该重启。
早期版本曾有过 SSRF、XSS 等漏洞（部分已在后续修复），所以及时升级、关注安全公告是运维的一部分；同时开放核心模式下部分能力（SSO、外部数据库、集群、审计）属于付费/企业层，别假定"开源镜像里全都有"。把前面六维收成一张可执行的配置清单。以下为参考预算与区间，非精确报价；实际机型、带宽与价格以官网实时或咨询确认为准。
轻量自用（合并拆分压缩为主、无 OCR、少量用户）：约 2 核、4 GB 内存、10 GB 以上 SSD，镜像选 ultra-lite 或限堆的标准版；参考预算为低配云主机/轻量服务器的公开报价区间，月费以各家官网为准。
标准团队（10 人内、含 OCR 与 Office 互转）：约 4 核、8 GB 内存、50 GB SSD，标准版镜像 + 设容器内存上限 6 至 8 GB、堆约七成；如需更快转换把 LibreOffice 会话上限调到 2 并预留 4 核。参考预算为中配云主机或入门独立服务器的公开报价/示例价格。
重度批量（50 人上下、频繁 OCR 与批量转换）：约 8 核以上、16 GB 起、100 GB 以上 SSD，拆分部署 backend + unoserver，LibreOffice 会话上限 4、Tesseract 上限 2，tmpfs 临时目录计入内存；如需多实例再上外部数据库与负载均衡（企业层）。参考预算为高配独立服务器或容器平台的公开报价，具体以咨询确认为准。
网络与机位：同一内网优先走内网交互省带宽；对公网服务用反向转发 TLS 收口；若需多地域低延迟，可考虑在华南、华东、华北及中国香港等服务器就近部署，具体服务器与线路以服务商实际覆盖为准。电力维度在租用场景通常已含于机柜与托管月费，重点确认是否含冗余电源与制冷；若是自购硬件长期开机，再单独折算电费与稳定性成本。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营服务器与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时或咨询确认为准。
问：跑 Stirling-PDF 到底要多少内存才不 OOM？答：没有放之四海皆准的数字，因为它会被单文件体积放大数倍。可验证的起点是官方区间（1 至 10 人 4 GB、10 至 50 人 8 至 16 GB、50 人以上 16 GB 起），并务必设容器内存上限、堆留约七成、至少留三成给外部工具；OCR/批量场景在此基础再加缓冲。
问：为什么我设了 -Xmx 还是会崩？答：很可能你用的是会被镜像覆盖的 JAVA_TOOL_OPTIONS，或容器没设内存上限导致堆按宿主机总内存算、外部工具没空间。改用 JAVA_CUSTOM_OPTS 或正确的启动命令传参，并设容器 limits。
问：OCR 特别慢、CPU 跑满正常吗？答：正常，Tesseract 本就 CPU 密集型；可通过调 Tesseract 会话上限控制并发、给足核数、把临时目录挂 tmpfs 提速，但仍要避免无上限并发把整机拖死。
问：能不能只在内网用、完全不接公网？答：可以，官方定位就含完全离线（air-gapped）形态；只要你的用户都在内网，把 8080 收在内网、用内网反代即可，对外零暴露。
问：租服务器时最该问服务商哪几个点？答：是否含冗余电源与制冷、SSD 的 IOPS 与容量、带宽计费方式（固定/流量/独享共享）、是否支持容器编排与共享存储、服务器覆盖（如华南/华东/华北/中国香港等）。把这些和你的峰值并发、文件大小、月流量一起算，再对比各家公开报价。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营服务器与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；如需按业务场景定制 PDF 处理或文档中台方案，可直接联系一万网络确认可用机型与交付周期。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
