过去一年里，来找我们问文档归档服务器怎么配的客户，问法几乎一模一样：我们有几十万页的历史扫描件，要放到一套能全文检索的无纸化归档系统里，这台机器该给多少核、多少内存、多大盘。这类需求落到开源方案上，Paperless-ngx 是被提到最多的名字之一——它是一套走消费目录思路的开源文档管理系统，你把文件丢进指定目录，系统自己去解析、去 OCR、去归档、去建索引，最后给一个能搜中文的检索框。听起来很轻，但真正把它搬进机房的人很快会发现，账不是按“有多少页纸”算的，而是按“一个原件进来以后会衍生出几份数据”算的。这一篇就把这笔账和上线第一周最容易踩的几个坑一起摆开讲。
先把结论性的判断放在前面，方便你决定要不要往下读：容量账的核心是“倍数”，不是“页数”——原件、带文本层的归档版、缩略图、索引条目会同时存在；OCR 是典型的短时高 CPU 负载，批量导入历史档案时瓶颈在核数和并发度，不在磁盘；数据库反而是三者里最小的，它存的是元数据和索引引用，真正撑爆系统盘的是媒体目录和索引目录；邮件拉取规则配错会让同一份合同进来三遍，这是上线第一周磁盘莫名长胖十倍的高频原因；备份必须三件套一起做，只备份数据库等于只备份了目录卡片，书全丢了。
这套东西的受众其实非常好识别：凡是“原件是纸、但以后要按关键词找回来”的业务，都是它的主场。我们在租用与托管咨询里遇到的客户，大多不是技术公司，而是财务共享中心、法务部、人事行政、以及有留存年限要求的行业客户。他们共同的特点是：纸张还在源源不断地进来， scanners 每天吐出几百到几千页，但这些页一旦进了柜子就再也找不着了，只能靠人回忆是哪一年哪一摞。Paperless-ngx 这类系统的价值就在于，把“进柜子”这个动作换成“进消费目录”，让 OCR 出的文本层成为以后唯一的检索入口。
财务场景是最典型的一类。发票、收据、银行回单、报销单，这些凭证的共同特点是数量大、单份体积小、但有明确的报销期间和供应商字段需要检索。财务同事真正想要的不是把扫描件存下来，而是“输入供应商名字就能把三年的往来单据全翻出来”。这就意味着 OCR 出来的文本必须能进全文索引，而且索引要能按字段加权：抬头、金额、日期这类字段的权重应该高于正文里的偶然词。也正因为单份小、数量大，财务场景的容量账里，条目数和索引膨胀会比单份体积更早成为问题。
合同档案是另一类典型负载，特点和财务票据刚好相反：数量不算多、但单份可能几十上百页，而且扫描分辨率往往开得很高，因为法务担心看不清签章。高分辨率扫描带来的直接后果是单份原件体积大，OCR 之后生成的归档版 PDF 又要再叠一层文本层，等于一份合同在系统里同时躺着两份接近原始体积的文件。我们在容量估算里会特别提醒这类客户：合同场景的磁盘压力主要来自原件分辨率的选择，而不是文档条数。
人事档案有个别的场景少见的痛点：它不是增量进来的，而是“一次性全量”。很多公司是上了系统才想起来把过去若干年的员工档案一次性扫进去，于是第一天就要导入几万页。这个动作会直接把 OCR 任务队列打满，让系统在接下来的一段时间里一直处于高 CPU 占用状态。如果你的人事场景也有这种“补历史课”的计划，那么配置这台服务器时该优先考虑的是核数能不能撑住这段导入期，而不是现在这点日常量需要多少资源。
行政公文的特点是格式杂：有扫描件，也有 Word、Excel、甚至版式文件。Paperless-ngx 处理 Office 类文档以及抽取元数据时会用到额外的外部组件（历史上常见的是用 Gotenberg 一类组件做文档转 PDF、用 Tika 一类组件做内容抽取），这些组件本身也会占用内存和 CPU，并且会带来额外的端口与容器编排工作。具体到某个版本依赖哪些组件、组件叫什么名字，一律以你部署版本的官方部署文档为准，不要照搬任何第三方教程里写死的组件清单，因为这类依赖在不同版本之间有过调整。
最后一类客户是被留存要求推着走的。他们不一定在意检索有多快，但在意两件事：一是文档不能被改，二是任何一次调阅要有记录。这类需求对 Paperless-ngx 来说是“存储与备份策略”问题，而不是功能问题。你需要明确归档版 PDF 是只读的、原始件与归档版要分开存放、以及备份要能恢复到某个时间点。我们在给这类客户做方案时，会把磁盘分层和备份窗口单独列出来谈，而不是混在配置清单里一笔带过。
要算准容量和算力，先得把这条流水线拆开。Paperless-ngx 的后端是 Python + Django，异步作业交给 Celery 一类任务队列处理，任务中间件可选 Redis 或文件队列（不同部署方式取舍不同，以官方部署文档为准），前端是 SPA 形态。理解这个技术栈的意义在于：它决定了“投喂”和“处理”是两个解耦的阶段，文件进来了不代表立刻处理完，中间的队列深度就是你系统压力的温度计。下面按六个环节逐个说清楚每一段到底吃掉什么。
第一段是投喂，也就是文件怎么进来。Paperless-ngx 支持从消费目录直接捡文件，也支持配置邮件拉取规则，从指定邮箱或目录按规则取附件入库，当然也支持网页端手动上传。这一段的资源消耗几乎可以忽略——它主要是磁盘写入和一次目录扫描。但它埋了两个雷：一是消费目录如果不做归档分流，处理完的文件和待处理的文件混在一起，会让目录越来越大、扫描越来越慢；二是邮件拉取规则一旦写得过宽，会把不该进来的东西也拉进来，这个我们后面单独用一个小节讲。
第二段是解析。系统要判断进来的是 PDF 还是图片、是Office 文档还是纯文本，并且抽取能抽到的元数据。这一段对非 PDF 文件会调用外部组件做转换，因此对内存有一定要求，尤其是转换服务本身通常以独立服务或容器形式运行，会常驻占用一部分内存。这一段的耗时通常不长，但它是失败率相对高的一段——格式不支持、文件损坏、转换服务没起来，都会让任务在这里报错。你在规划批量导入时，必须为这一段预留失败重试和失败清单的处理流程。
第三段的 OCR 是整条流水线里最重的一环。它依赖 Tesseract、OCRmyPDF 一类工具完成，语言包需要单独安装，中文包的体积明显大于英文包，而语种包的选择会直接影响识别率与 CPU 耗时——这一点必须反复强调：为了省事只装英文包去识别中文票据，结果就是索引里一片空白，检索形同虚设；而装了过多语种又会让每次识别的候选空间变大、耗时上升。这一段是纯 CPU 活，磁盘只是写入结果，内存占用取决于并发任务数与单页图像解码后的大小。
第四段是归档，也就是生成那个“带文本层的归档版 PDF”。这里要特别注意：归档版不是把原件覆盖掉，而是另存一份。于是同一份文档在系统里就有了两个实体——原始上传件和归档版。这个“另存”动作就是容量账里最大的一笔支出，而且它发生在 OCR 之后，意味着你在导入期会同时看到磁盘占用和 CPU 占用一起往上冲。归档阶段通常还会顺带生成缩略图，缩略图按页数产生，页数多的文档在这里会派生出更多小文件。
第五段是索引。OCR 出来的文本层被送进全文索引，生成可检索的条目。这一段的体积决定因素不是页数本身，而是文本量、分词粒度和参与索引的字段数。中文分词尤其特殊：它不像英文那样天然按空格切词，分词器的选择会直接改变索引条目的数量级。索引写入还有一个容易被忽略的特征——它在重建索引时会出现体积与 IO 的峰值，平时看起来很温和的索引目录，在重建窗口里可能临时膨胀。所以给索引目录留空间时，不能只按当前稳态大小来算。
第六段是检索，也就是用户真正在用的那一下。这一段对硬件其实相当友好，查询本身消耗的资源远小于前面的处理环节。真正影响检索体验的是配置：分词器、语言设置、字段权重。很多人把“搜不到”归咎于机器不够快，于是加内存加核，结果毫无改善，因为问题出在文本层没建好或者字段没加权。我们在下一节之后会专门用一小节讲这个取舍。
现在我们来讲这篇的核心。归档系统的容量账，正确的算法是“倍数”，不是“页数”。一份扫描件进入系统之后，会同时存在四类数据：原始上传件（或扫描原件）、归档版 PDF（OCR 之后带文本层的版本）、缩略图、以及全文索引条目。很多人在做预算的时候只算了第一类，于是上线一个月发现磁盘见底，还以为是系统有 bug，其实是账本来就没算全。
我们可以给一个估算框架，但必须先把话说死：框架里每个系数都必须用你自己的样本实测，本文不给“一定是多少倍”的定论。框架的形式是这样的——总占用 ≈ 原件总体积 ×（1 + 归档版增量系数 + 缩略图系数）+ 索引膨胀量。其中：归档版增量系数指的是 OCR 后 PDF 相对原件体积的增加比例，它取决于文本层的写入方式、字体是否嵌入、以及原件的压缩方式；缩略图系数指的是缩略图总体积相对原件的比例，它取决于文档页数与缩略图尺寸，页数越多这个系数越高；索引膨胀量则单独按文本量和分词粒度估算，不按原件体积线性推导。
怎么用这个框架？做法是抽样。从你真实的档案里挑出有代表性的几十份——要覆盖不同分辨率、不同页数、不同来源（扫描件、Office 转换件、邮件附件），先记下它们的原始总体积，跑完整条流水线之后，再分别量出归档版目录、缩略图目录、索引目录各自的增长量，用这些实测值反推出属于你自己的三个系数。这个动作花不了多少时间，但它能把一个拍脑袋的磁盘预算变成一个站得住的数字。我们建议客户在上机之前就做，因为一旦导入了几万页再去改分区，代价要大得多。
还有一个容易被漏掉的项：临时文件与任务队列。异步任务在处理过程中会产生中间文件，批量导入期间这部分会陡增，虽然任务跑完会清理，但在导入窗口内它确实占着磁盘。所以你在做容量规划时，不能把磁盘按稳态占用算到百分之九十以上，必须给临时文件和导入峰值留出余量。这也是我们反复建议把媒体目录、索引目录、以及临时目录放在独立的大分区上的原因——它们各自的增长曲线完全不同，混在一个分区里，任何一个失控都会把整个系统盘拖垮。
讲完磁盘，讲 CPU。OCR 是非常典型的短时高 CPU 负载：任务进来的时候几乎要把核吃满，任务跑完又立刻归零。它的吞吐由三个变量决定——单页耗时、语言包、分辨率。单页耗时是你自己的样本实测出来的，不是网上抄来的；语言包决定识别时的工作量，中文包的开销和英文包不在一个量级；分辨率决定图像解码与预处理的工作量，开到很高的 DPI 去扫一张本来就清晰的文档，等于白白多付好几倍 CPU。
反推核数的方法其实很朴素，我把它拆成四步。第一步，实测单页耗时：拿你的真实样本，在目标机器上跑一遍，记下从任务开始到归档完成的墙钟时间，注意要跑在“没有其他负载”的机器上，否则测出来的是被干扰值。第二步，算出总页数：把你要导入的历史档案按页数统计清楚，不是按份数，因为一份一百页的合同和一份一页的回单对 CPU 的意义完全不同。第三步，用总页数乘以单页耗时，得到“单核串行跑完需要多久”这个基准时长。第四步，用你能接受的导入窗口去除这个基准时长，得到的就是并发度，而并发度直接对应你要的核数。
举个推导的形态（注意是形态不是结论）：假设你的样本实测是单页耗时若干秒，历史档案总共若干万页，那么单核串行需要的时间是两者相乘，可能是几百个小时这个量级；如果你希望在一个周末的两天内导完，就把那个总时长除以四十八小时，得到需要的并发任务数。这个并发数再向上取整并留一点余量，就是要买的核数。这里的每一个输入都必须替换为你的实测值，本文不提供任何具体秒数与具体页数，因为不同语言包、不同分辨率、不同机器之间的差距可以非常大，抄一个数字过来只会误导你。
还有两个工程上的补充。第一，并发度不是越高越好：任务并发数要和核数匹配，超过核数的并发只会带来上下文切换和内存压力，不会带来吞吐提升；同时 OCR 是内存也吃的活，并发任务多的时候每个任务都要解码图像，内存要给够。第二，导入期的 CPU 高峰会影响前端响应：如果这台机器还要同时给同事提供检索服务，那么批量导入最好错峰，或者把导入的并发度压低一档，用更长的导入窗口换取白天更好的使用体验。这个取舍在租用配置阶段就要定下来，因为它直接决定你买几核。
下面这张表是我们给归档类客户做方案时常用的对照清单，把“一份原件变成几份数据”这件事拆到对象级别。表里每一行的体积决定因素，都是你在做容量预算时要单独去实测的量，不要互相套用。稳态还是峰值这一列尤其要看：它决定了你是按“长期占用”还是按“导入窗口占用”来给这个对象留空间，这两者规划错位的后果完全不同。
| 数据对象 | 从哪里产生 | 体积决定因素 | 稳态还是峰值 | 备份时怎么处理 |
|---|---|---|---|---|
| 原始上传件 / 扫描原件 | 消费目录投喂、网页上传、邮件拉取附件入库 | 扫描分辨率与色彩模式、单页体积、是否为多页文件 | 稳态累积；批量导入期出现写入峰值 | 必须纳入媒体目录整体备份，建议只读存放、与归档版分目录 |
| 归档版 PDF（含 OCR 文本层） | OCR 与归档任务在原件之外另存生成 | 原件体积 + 文本层与字体嵌入增量、页数、压缩方式 | 稳态累积，是长期占用的主要部分 | 可由原件与配置重新生成，但重新生成代价高，建议一并备份 |
| 缩略图 | 归档阶段生成预览图，通常按页派生 | 文档页数 × 缩略图尺寸 × 每页份数 | 稳态累积，页数多的文档增长更明显 | 可重建，优先级低于原件与归档版；空间紧张时可最后备份 |
| 全文索引数据 | 索引模块写入，来源为 OCR 文本层与元数据 | 文本量、分词粒度、参与检索的字段数量 | 平时稳态；重建索引时出现体积与 IO 峰值 | 必须与数据库同时点备份，否则恢复后索引与元数据会错位 |
| 数据库（SQLite / PostgreSQL / MariaDB） | Django 后端写入文档元数据与索引引用 | 文档条数、字段与元数据规模，与文件体积基本无关 | 稳态，体量通常远小于媒体目录与索引目录 | 用数据库自身的导出或快照机制，与索引目录同一时间点备份 |
| 任务队列与临时文件 | 异步任务处理过程中的中间产物与队列状态 | 并发任务数 × 单任务临时体积 × 队列积压深度 | 典型峰值对象，批量导入期陡增，跑完回落 | 不纳入常规备份，但必须预留峰值空间，避免写满导致任务失败 |
把几万页历史档案一次性丢进消费目录，是上线阶段最容易出事的动作。问题不在于系统扛不住，而在于你没有观察窗口：一旦全部灌进去，队列深度、CPU、磁盘会在同一时间冲到顶点，你既看不出哪个环节先到瓶颈，也没法在出问题的时候停下来。正确的做法是把导入拆成批次，每批的规模以“能在可控时间内跑完、并且跑完能立刻核对”为原则，宁可多批也不要一批到底。
限并发是第二个要点。并发度要和核数匹配，前面已经推导过怎么算；这里要补充的是，导入期间并发度的设定应该比日常低一档，因为你可能还需要这台机器对外提供检索服务。如果你有明确的停机窗口，比如周末两天，那就在窗口内把并发拉满；如果没有停机窗口，就把并发压到不影响白天使用的水平，用更长的导入周期去换稳定性。这个选择没有标准答案，取决于你的业务能不能接受“系统白天有点慢”。
错峰与核对是最后两步。错峰不只是避开白天，还包括避开备份窗口——导入期会产生大量临时文件和索引写入，如果和备份任务撞在一起，两者都会变慢，还可能出现备份到一半文件被改动的情况。核对则要做得比想象中细：跑完一批之后，要核对成功页数与失败清单，把失败的文件单独摘出来看是格式问题、转换组件问题还是文件本身损坏；同时要核对磁盘增长量是否和你前面实测的系数吻合，如果偏差明显，说明你的样本不具代表性，需要重新抽样再算一遍。
这是配置阶段最常见的一个误判。很多人按“我们有五十万份文档”去估数据库规模，于是给数据库分区划了很大的空间、给媒体目录划了很小的空间，结果上线后第一个告警就是媒体目录写满。实际上 Paperless-ngx 的数据库存的是元数据和索引引用——文档的标题、标签、对应关系人、创建时间、以及指向索引的引用，这些东西的体积和文件本身有多大基本无关，和文档条数有关，而单条元数据的体积是很小的。生产规模下官方通常建议使用 PostgreSQL 或 MariaDB 而不是 SQLite，但那是并发与可靠性的考量，具体版本要求以官方部署文档为准，不要据此断言某个版本强制某种数据库。
真正会变大的是两个目录：媒体目录和索引目录。媒体目录装着原始上传件、归档版 PDF、缩略图，也就是前面表格里前三类数据对象，它是绝对的占用大头；索引目录装着全文索引数据，它的体积取决于文本量和分词粒度，在中文场景下尤其不能低估。这两者的共同点是：它们都在文件系统上，都在持续增长，而且增长速度都和你的导入节奏直接挂钩，不像数据库那样缓慢线性。
这个判断直接决定了系统盘该怎么给。我们的建议是不要纠结“系统盘要不要很大”，而是要做分层：操作系统与数据库放在一块相对小但稳定的盘上，媒体目录单独挂一块大容量存储，索引目录单独一块并且给足重建时的余量，临时目录再单独一块或者至少独立分区。这样做的好处有三个：一是任何一个目录失控都不会把系统盘写满导致整机不可用；二是不同目录可以用不同的存储策略，比如媒体目录追求容量、索引目录追求 IO；三是备份策略可以按目录分别制定，索引和数据库要同一时间点，媒体目录可以按增量去做。
邮件拉取是 Paperless-ngx 很受欢迎的一个功能：配好规则之后，往指定邮箱发一封带附件的邮件，附件就自动入库了。但这个功能也是上线第一周事故率最高的地方，因为它把“入库”这个动作的触发权交给了不受你控制的外部邮件流。我们总结下来最常见的翻车有四类，下面逐个讲清楚机理和防范。
第一类是重复投递，也就是同一封邮件被反复导入。这不是系统 bug，而是幂等问题：如果规则写得过宽，或者邮件在邮箱里的状态没有被正确标记，系统就会在每一轮拉取时都认为这是一封新邮件，于是同一份合同进来三遍、五遍。解决办法是让规则足够具体，并且明确“已处理”的判定方式——具体支持哪些去重与已读标记机制，以你部署版本的官方文档为准，不要凭想象配置。上线第一周务必每天看一眼新增条数，如果新增条数明显超过你实际发出的邮件数，那基本就是重复投递在发生了。
第二类是签名图污染。很多企业邮箱的签名档里带着公司 logo、二维码、甚至装饰性图片，这些图片在邮件结构里同样是附件。如果规则是“取全部附件”，那么每一封邮件都会附赠几张小图进库，它们会被当成文档去 OCR、去建索引，浪费 CPU 不说，还会在检索结果里冒出一堆毫无意义的条目。防范办法是在规则层面限定附件的类型与大小下限，把明显属于签名档的小图挡在门外；同时建议给员工发一个统一的投递规范，说明什么样的附件才应该发到这个邮箱。
第三类是附件误收，也就是把不该归档的东西拉了进来。典型场景是同一个邮箱既收归档件又收日常往来，规则一宽就把报价单、聊天截图、甚至是转发链里的历史附件全部收入。这类问题的治理成本比前两类高，因为东西已经进库并且建了索引，清理起来要逐条核对。所以我们建议归档专用邮箱单独开一个，不要把日常邮箱拿来兼用；如果必须兼用，规则就要写得非常窄，宁可漏收也不要错收，漏收可以补，错收要清理。
第四类是去重失效的连锁反应。当重复投递和签名图污染同时存在时，系统里的条目数会以一种看起来毫无道理的速度膨胀：你以为一天发了十份合同，实际入库了三百条。这正是“上线第一周长胖十倍”的典型成因，而且它同时放大了 CPU 和存储压力——每一条都要走一遍 OCR，每一条都要生成归档版和缩略图。所以我们的建议很明确：邮件拉取功能先小范围试运行一两周，把规则和去重确认没问题之后再放量，不要一上线就把全公司的归档邮箱都接进来。
使用一段时间之后，最常见的抱怨是“搜不到”或者“搜出来的不对”。这时候很多人的第一反应是机器不够，于是加内存、加核，但基本没有改善，因为瓶颈根本不在硬件。检索这一段对资源的消耗远小于 OCR 那段，日常查询的压力通常很轻。真正决定检索体验的是三件配置上的事：分词、语言、字段权重。
分词是中文场景的核心。英文天然有空格，切词相对简单；中文没有，分词器怎么切，直接决定了索引里有什么词、以及你能搜到什么。如果分词器选得不合适，或者语言设置没配对，那么 OCR 出来的文本即使完全正确，也建不出可用的索引——你会遇到“这段文字明明在文档里，但就是搜不到”的情况。所以上线之后如果发现检索不准，第一步应该去验证文本层是否正确生成、分词与语言设置是否匹配，而不是去看监控里的 CPU 曲线。具体的分词配置项与语言设置项名称以你所部署版本的官方文档为准，不同版本在暴露哪些配置项上有差异。
字段权重是第二件。一份归档文档通常有标题、对应人、标签、日期、正文等多个字段，如果所有字段一视同仁地参与匹配，那么正文里偶然出现一次关键词的文档，可能会排在标题就是这个关键词的文档前面。合理的做法是给标题、标签这类强信号字段更高的权重，让它们命中时排在前面。这个调整不需要任何硬件投入，但对“找不找得到”的体感影响极大。
第三件是语言包与识别质量的连带关系。前面说过，语种包的选择直接影响识别率与 CPU 耗时。如果你的文档以中文为主但只装了英文包，那么文本层质量会非常差，后面无论分词怎么配都救不回来；反过来，装了过多用不到的语种，又会让每次识别的开销上升。所以语种包的选择要按你的真实文档构成来定，不要装一堆“以防万一”的包。这一条看似是 OCR 配置，实际是检索体验的上游决定项。
最后一个避坑点，也是最容易被忽略的一个。很多运维同学做备份时的第一反应是“把数据库导出来”，因为数据库有成熟的导出工具和明确的备份流程，做起来最顺手。但在 Paperless-ngx 这里，只备份数据库是一次教科书式的翻车：数据库里只有元数据和索引引用，真正的文档内容在媒体目录里，真正的检索能力在索引目录里。只恢复数据库的结果是——你得到了一套完整的目录卡片，上面写着有哪几万份文档、标题是什么、标签是什么，但点开全是空的，检索也搜不出东西。
所以正确的备份对象是三件套：数据库、媒体目录、索引目录。三者要一起备份，而且要尽量在同一个时间点上取，因为它们之间存在一致性关系：数据库里的条目指向索引里的条目，索引里的条目对应媒体目录里的文件。如果三者的备份时间点错开太多，恢复之后就可能出现“数据库说有这个文档、索引里没有”或者“索引里有、文件不在”的错位，这种不一致排查起来非常痛苦。
具体到策略上，我们给客户的建议是这样：数据库用数据库自身的导出或快照机制，并且和索引目录在同一时间点取；媒体目录因为体积大、增长快，适合用增量方式做，但恢复演练时必须验证增量链完整；索引目录要和数据库对齐时间点，因为它和数据库是一致性最强的一对。临时目录和任务队列不需要纳入常规备份，但必须保证磁盘不会因为临时文件写满而中断任务。另外，无论策略多完善，都要定期做一次真实的恢复演练——备份没验证过就等于没有备份，这一点在归档系统上是铁律，因为它的价值恰恰在于“多年以后还能翻出来”。
结合前面整篇的推算，如果你正在为一套 Paperless-ngx 归档系统挑服务器，我们的两项推荐是这样。第一项推荐是把预算优先投在 CPU 核数上。理由已经在 OCR 那一节讲透了：这类系统的重负载是短时高 CPU，批量导入期的吞吐直接由核数与任务并发度决定，而日常检索对资源的需求并不高。把钱花在核上，换到的是导入窗口更短、队列不堆积、白天使用不卡顿；把钱花在很豪华的内存上，收益反而不明显。
第二项推荐是磁盘一定要分层，不要一块大盘走天下。媒体目录、索引目录、临时目录、系统与数据库目录，各自的增长曲线和性能诉求都不同，混在一块盘上的结果是任何一个失控都会拖垮整机，而且备份策略没法按对象分别设计。分层之后，你可以给媒体目录配大容量、给索引目录配更好的 IO、给临时目录留足峰值余量，每一块钱都花在对应的地方。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
上线第一周不要急着放量，先做校准。我们建议按下面这个顺序走一遍，每一步都留下记录，这些记录就是你以后扩容的依据。第一步，抽样实测：从真实档案里挑几十份覆盖不同分辨率、不同页数、不同来源的样本，跑完整条流水线，量出原件、归档版、缩略图、索引各自的增长量，算出属于你自己的三个系数。第二步，用这些系数去核对最初拍的磁盘预算，偏差大就调整分区，越早调整代价越小。
第三步，核对导入速率：在限并发的条件下跑一批，记录队列深度、CPU 占用、单批耗时，用实测的单页耗时去修正你之前估算的导入总时长，看看按现在的并发度能不能在预期窗口内跑完，不能就调整并发或者核数。第四步，盯邮件拉取：每天看新增条数是否与实际投递量吻合，看有没有签名图混进来的小文件条目，发现异常立刻收紧规则。第五步，做一次恢复演练：把数据库、媒体目录、索引目录三件套恢复到一台测试机上，验证能不能真的检索到内容——这一步是唯一能证明备份有效的方式。
做完这五步，你对这套系统的认识就从“听说”变成了“有数”。后面再谈扩容、再谈加机器，都有实测数据支撑，而不是凭感觉。我们见过太多相反的例子：上线前不校准，出问题就加配置，加了还是不够，最后发现瓶颈根本不在加的那个地方。归档系统的特点是一次性投入大、迁移成本高，所以前期多花两天做校准，是非常划算的。
最后把下单前要确认的事情列清楚，方便你对着谈。第一，确认 CPU 核数与你预期的导入窗口匹配：带上你实测的单页耗时和总页数，我们帮你反推并发度与核数，这比直接报一个“要几核”靠谱得多。第二，确认磁盘分层方案：媒体目录、索引目录、临时目录分别给多大、用什么介质、是否独立分区，这些要在下单前定下来，因为事后改分区的代价很高。第三，确认内存与任务并发的匹配关系：并发任务数上去之后内存也要跟上，这部分我们按你的并发设定来配。
第四，确认备份与快照方案：数据库与索引目录要同一时间点备份，媒体目录可以做增量，备份窗口要和批量导入窗口错开，这些都要在方案里写清楚。第五，确认网络与访问方式：归档系统通常只在组织内部使用，是否需要公网访问、要不要配访问控制、同事从哪些网络环境进来，这些决定了带宽与防护怎么配。第六，确认后续扩容路径：核数能不能加、磁盘能不能扩、加的时候要不要停机，这些在下单前问清楚，比用到一半才发现扩不了要好。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。以上关于 CPU 核数、磁盘分层与备份方案的选型建议，均基于本文所述的容量估算框架与工程做法给出，实际机型组合、可用区域与参考预算会随库存与活动变动，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
