合同全文检索场景的服务器资源分配，核心看三个数：合同文档总量、索引膨胀倍数、业务高峰并发数，多数情况下，按“1GB源文档配5-8GB内存、CPU核数按并发查询数×2”起步，磁盘用SSD并预留索引体积1.5倍空间，能覆盖90%的企业合同管理需求。
合同全文检索服务器配置要求：先看这三项硬指标
配置服务器之前，先别急着数CPU核数，合同全文检索和普通网站不一样，它搜的是已解析的正文文本，要同时处理分词、倒排索引、高亮片段，资源消耗主要看三件事：存量合同总量、检索并发数、未来增长空间。
文档总量与索引体积怎么算
一套合同全文检索系统里，源文件通常有PDF、Word、扫描件，扫描件要经过OCR识别，每页生成的文本很小，但索引反而会膨胀，行业共识认为，倒排索引加原文存储，整体体积约为源文档的3倍，比如你有10万份合同，平均每份2MB，源文件约200GB，那么索引加上原始文件,磁盘至少准备600GB。
这里有一个容易漏掉的点：合同原文里的盖章、手写体、表格，OCR后会产生大量无意义碎片词，索引精度低就会导致体积进一步膨胀，建议在资源估算时，按源文档体积的3.5倍作为兜底,而不是刚好3倍。
并发查询量决定CPU和内存
合同检索的并发通常来自法务部门或业务系统调用，一般日常检索不会像搜索引擎那样每秒几十次，但月底审计、合规检查时会集中爆发。CPU核数建议按“峰值并发查询数×2”配置，例如峰值30个查询，留出处理余量，至少准备8核,最好16核。
内存方面，每个查询在Lucene层面要占用一小块文件缓冲，但大头是操作系统页缓存，多数情况下，热数据能全部放进页缓存，检索速度才有保障，如果内存只够放下索引的1/5，命中率会明显下降，表现为翻页变慢、高亮卡顿。
磁盘读写速度是易忽略的瓶颈
合同检索对磁盘的要求比数据库高，因为要随机读取多个倒排表文件，机械硬盘在碎片化读场景下延迟会飙到几十毫秒，而全文检索要求亚秒级响应。务必使用SSD，尤其是NVMe接口，如果合同量大到单机放不下，需要把索引分到多块盘，也要确保每块盘顺序读写至少500MB/s。
Linux系统文件句柄和mmap预读设置也要跟着改，不然即使磁盘好，系统默认的vm.swappiness和max_map_count不调,检索进程也可能频繁缺页中断。
全文检索服务器内存多大合适？别再凭感觉配
很多人一上来就说“内存加到64G”，但合同规模只有几万份，纯属浪费；反过来，索引有800G却只给128G内存，检索肯定慢,这里给一套可以直接参考的经验配置。
按合同量分档的内存建议
| 合同规模 | 索引及源文件总量 | 建议物理内存 | 建议CPU核数 |
|---|---|---|---|
| 小型企业，几万份合同 | 50GB以下 | 16-32GB | 8核 |
| 中型企业，10-50万份 | 100-300GB | 32-64GB | 16核 |
| 大型集团，百万级合同 | 500GB-1.2TB | 128-256GB | 24-32核 |
| 多法人/集团统一平台 | 2TB以上 | 256GB以上，或分布式多节点 | 32核×3节点以上 |
这个表适合Elasticsearch、OpenSearch这一类通用全文检索组件，如果自己用Lucene写搜索层，内存需求可以略低，但开发成本高,不推荐。
堆内存与系统内存要分开算
以Elasticsearch为例，JVM堆内存只在查询聚合、连接协调、索引写缓冲时被使用，真正的倒排表读写在堆外，业内专家指出，堆内存设置不要超过物理内存的一半，并且单节点堆内存不要超过31GB，剩下的内存要留给操作系统页缓存,这样Lucene才能直接读文件映射。
实操时，先通过GET _cat/nodes?v&h=heap.percent,ram.percent观察堆使用率，如果堆长期占用超过80%，说明聚合或缓存设置不合理，而不是要加内存，如果系统内存充足但ram.percent很低，检索仍然慢,要检查文件系统缓存是否被容器限制。
合同检索系统部署方案价格：从单机到集群的取舍
合同检索系统的部署成本，不只是服务器的采购价格。同一个合同量，选单机高配和选三节点集群，总体花费可能相差2-3倍，但可用性和扩展性完全不同。
单机部署适合多少合同量
单个节点可以承担约200万份以下、总索引在1TB以内的合同检索，这种方案最便宜，一台两路服务器加两块NVMe固态盘，预算集中在内存上，适合合同量稳定、业务允许短时中断的小型法务团队。
但要注意，单机部署一旦磁盘满了或索引损坏，恢复时间往往要按天算，建议至少做冷备份,每天把索引快照存到另一台存储服务器或对象存储。
集群部署的节点角色划分
合同量超过1TB或需要高可用，就应该上集群，最低起步是3节点：一个节点管master与协调，另外两个放数据,每个数据节点的内存与磁盘按前面表格单独配置。
这里有一个常见的资源分配误区：以为master节点必须要很强，其实master节点主要负责集群状态管理，2核4GB就够用，但必须稳定，真正吃硬件的是数据节点，如果用了专用协调节点，内存也要给足,因为查询协调需要临时聚合结果。
从价格角度，云服务器和物理机的选择也影响成本，云服务器优势是弹性扩容，适合合同量逐年增长的企业；物理机优势是内存大、磁盘吞吐稳定。合同检索场景要优先选大内存实例，而不是高主频，例如云厂商的通用型实例，内存和CPU比例在4:1左右,通常比计算型实例划算。
合同全文检索性能优化：分配完资源后还要做什么
服务器资源只是地基，分配完不调优，实际效果可能只发挥一半，下面这几个动作,在配置服务器时就要一并规划。
索引分片与副本设置
索引分片数不能乱设，合同检索库通常按月或按合同类型建索引，每个分片控制在20-40GB比较合适，如果单分片过大，检索时单线程扫描时间长；分片太多,则节点间通信开销大。
副本数至少在1以上，保证一台数据节点宕机时不丢索引，但副本会额外占用一倍磁盘和内存，资源分配时要算进去，实操时，通过GET _cat/allocation?v看每个节点的磁盘和分片分布,确保没有热点节点。
查询缓存与冷热数据分离
合同有很强的时效性当前年度合同检索频繁，三年前的合同偶尔才查，建议把服务器分成热节点和冷节点：热节点用大内存SSD，存放最近两年的合同索引；冷节点用普通SSD甚至机械盘，存放历史归档，查询时用
routing或者别名限定到热节点,能明显提升峰值响应速度。
查询缓存不要盲目开大，ES的indices.queries.cache.size默认是10%，如果内存紧张，可以保持在10%不变；如果合同库都是精确短语查询，缓存命中收益有限，反而可以调小到5%。
监控与容量规划
资源分配不是一次性的，上线后要每天看磁盘水位、CPU平均负载、堆内存趋势，推荐使用cerebro或prometheus+grafana监控集群指标，当磁盘使用率超过70%时要预警，因为Lucene的段合并需要临时空间,磁盘写满会导致索引只读。
容量规划上，每年合同增量按总量的10%-20%预判比较稳妥，合同量增长不是线性，并购、审计等场景可能突然翻倍，预留资源时，集群比单机更容易横向扩容,这也是为什么合同量在百G级就建议上集群。
合同全文检索服务器配置常见问题
合同规模500万页，需要几台服务器？
500万页的合同文本，按每页OCR后约2KB计算，源文档约10GB，索引按3倍算约30GB，这个规模并不大，单台16核32GB内存的服务器就能跑得很稳，但要注意这500万页如果扫描件多，OCR处理时的临时空间会翻倍,建议系统盘单独留出100GB。
全文检索用Elasticsearch还是自研？对硬件要求差多少？
Elasticsearch基本是当前合同检索的主流选择，硬件要求主要看分片和副本设置，默认配置下比自研Lucene方案多约30%内存开销，自研方案能省一些内存，但分词、高亮、权限过滤都要自己写，项目周期拉长，硬件上省下来的钱远不够补开发成本,建议没有特殊合规要求就选Elasticsearch。
合同检索系统部署在云服务器还是物理机更划算？
这不是简单的价格对比，云服务器按年付费，适合合同量波动大、需要快速扩缩容的企业；物理机一次性采购，适合合同量稳定且对数据主权要求高的单位。合同检索对内存和磁盘IO的要求远高于CPU，无论哪种方式，都要优先保证大内存和NVMe磁盘,否则后期性能瓶颈很难靠加机器解决。