ES全文检索为什么需要申请服务器？Elasticsearch怎么搭建服务器

开篇答案

ES全文检索之所以需要单独申请服务器，是因为它天生就是一个“常驻内存”的分布式中间件，必须拥有独立的CPU、内存和磁盘资源才能稳定发挥亚秒级检索能力，与业务应用共享机器极易引发内存溢出和检索卡顿。

很多团队起初都抱着“顺手装在一台机器上”的想法，结果运行几个月后频繁报错、搜索接口超时，最后才补申请服务器搬迁数据，这篇文章会把ES的“胃口”讲清楚,让你少走弯路。

ES全文检索为什么对服务器资源如此“挑剔”

ES本质上是一个独立运行的搜索引擎进程，不是业务应用的附属库

ES基于Lucene构建，启动后就是一个独立的Java服务进程，默认监听9200端口对外提供HTTP接口，它跟MySQL、Redis一样，属于需要长期驻留的系统级中间件,而不是像H2那样能嵌进业务代码的轻量数据库。

Lucene底层的索引文件以段（Segment）为单位存储在磁盘上，搜索时ES会把索引段映射到内存，利用操作系统的Page Cache加速读取。这意味着ES对内存的占用是持续性的，不是请求来了才分配，机器上如果没有足够的内存放索引缓存,搜索性能会直接断崖式下跌。

写入、合并、搜索三线并发，任何一条掉链子都会引发雪崩

ES的写入链路要先经过内存缓冲、转写到磁盘、生成新的段文件，然后后台线程还要不断对段进行合并，任何一个环节被其他应用抢占资源，都会扩散成“慢写入→积压→搜索变慢→集群卡死”的连锁反应。

业内专家指出，多数ES性能事故都不是功能问题，而是物理资源不足导致的“慢性死亡”，起初只是偶尔延迟,半年后某次大合并直接把节点拖崩。

ES对服务器配置有哪些硬性要求

内存大小直接决定能索引多少数据

ES官方长期建议给ES分配机器总内存的50%作为JVM堆内存，剩余一半留给操作系统Page Cache，假设一台服务器有32GB内存，堆设16GB，剩余16GB给OS做索引缓存，如果总内存只有8GB，堆只能设4GB，遇到稍大的数据集就频繁触发Full GC,基本没法用。

内存选型要遵循以下几点：

• 单节点堆内存建议在8GB到30GB之间，超过32GB反而不利于JVM压缩指针
• 一定要禁用Swap，否则JVM堆发生交换，延迟会指数级上升
• 内存频率和通道数同样会影响检索耗时，双通道优于单通道

CPU核数决定并发检索吞吐量

ES的搜索请求是CPU密集型操作，需要解析查询语句、遍历倒排索引、对命中结果做相关性算分，低并发场景下4核也能跑，但业务量增长后，8核起步比较稳妥，生产环境常见的是16核32GB到32核64GB的配置组合。

磁盘类型是搜索延迟的最大影响因素

ES写入依赖磁盘落盘，搜索时如果索引热数据没完全进入Page Cache,也要回读磁盘。

• 机械硬盘只能满足数据量小、并发极低的小型日志收集场景，一旦段合并开启，IO立刻打满
• SSD是最低底线，建议使用NVMe SSD，随机读取延迟比SATA SSD低数倍
• 有条件的话把数据目录挂载到独立数据盘，与系统盘分开，避免日志写满系统盘拖垮节点

网络带宽容易被忽略但很致命

多节点组成的ES集群，查询节点需要向其他数据节点分发请求并聚合结果，节点间传输的数据量可能达到原始索引体积的数倍，千兆内网只能支撑小规模集群，较大规模部署建议使用万兆内网。

ES全文检索只申请一台服务器够用吗

单节点适用的具体场景

数据量在百GB以内、日均写入几GB、并发检索量每秒不超过几十次的场景，一台性能充足的服务器完全能扛住，比如个人博客全文搜索、中小型企业内部知识库、单机日志分析平台,用一台16核32GB的服务器可以稳定运行。

单节点部署时要注意一个“坑”ES默认配置下节点会参与选举，如果偶发网络抖动，单节点也可能出现脑裂风险，需要在配置文件中指定discovery.type: single-node（适用于单机开发测试环境）或合理设置minimum_master_nodes参数。

什么时候必须从一台扩展到多台

以下情况出现任意一种,就该考虑申请第二台甚至第三台服务器了：

• 单节点CPU长时间超过70%，搜索RT出现波动
• JVM堆使用率经常超过85%，GC频率明显上升
• 磁盘剩余低于20%，段合并无法正常进行
• 需要对索引做热温冷架构分层，把热数据与冷数据放在不同节点
• 希望实现零宕机滚动升级，一台机器无法完成

多节点集群至少需要3台，2台节点的集群在脑裂问题上没有理论上的赢家，一台挂了另一台也可能因无法形成多数派而拒绝读写,比单节点更难受。

ES服务器选云主机还是自建物理机

云服务器是大多数中小团队的主流选择

云厂商提供的云服务器规格覆盖了各种配置段，从ECS或轻量云主机到裸金属物理机一应俱全,优缺点如下：

• 优点是分钟级开通，按量付费，扩缩容方便，异地灾备容易实现
• 缺点是IOPS上限受实例类型限制，性能波动比物理机明显，长期占用成本可能高于自购
• 但考虑到自建机房还需要机柜、带宽和运维人力，除非你有专业运维团队，否则云服务器更适合绝大多数团队

物理机适合超大数据量的重型场景

搜索引擎类业务会长期跑着ES，不像业务容器能在高峰扩容，行业共识认为，数据量达到TB级以上并且增速稳定的场景，可以考虑自建物理机集群,否则维护成本会淹没性能收益。

地域选择和价格差异

国内主要云厂商的服务器价格因地域不同有明显差异，北京、上海等一线城市机房的带宽和IP资源稀缺，同配置服务器价格往往比成都、贵阳等西部节点贵一截。如果检索业务对延迟不敏感，选择西南地域能把es全文检索服务器多少钱这个问题的答案直接砍掉近一半，但如果你的用户主要分布在华东，那么即使上海地域贵一些，也必须把节点放在上海,物理距离带来的延迟是跨地域方案无法克服的。

ES全文检索服务器申请与配置实操指南

操作系统层面的必要调整

拿到服务器后不能直接装ES,先执行以下操作：

• 编辑/etc/security/limits.conf，将nofile设为65535及以上，memlock设为unlimited，解决“max file descriptors [4096] for elasticsearch process is too low”报错
• 调整内核参数vm.max_map_count至少为262144，执行sysctl -w vm.max_map_count=262144并写入/etc/sysctl.conf
• 执行free -h检查内存，确认没有其他进程占用主要资源
• 生产环境务必执行swapoff -a禁用交换分区，并把/etc/fstab中的swap挂载行注释掉

修改ES的JVM堆内存配置

如果使用官方tar包安装，堆内存配置在config/jvm.options文件中，修改-Xms和-Xmx为同一个数值，不确定的情况下建议先设置为系统物理内存的一半，例如机器有32GB内存就设为16g，只改-Xmx而不改-Xms会导致JVM启动后逐渐申请内存,可能无意中占用过多系统内存。

安装完成后的验证清单

启动ES后依次检查：

• curl localhost:9200返回包含cluster_name的JSON响应
• curl localhost:9200/_cat/health?v查看集群状态为green或yellow
• 写入几个文档测试分词效果，确认中文分词器插件正常工作

ES检索性能跟不上，优先排查服务器瓶颈而非调整查询语句

当线上ES搜索变慢时，很多人的第一反应是优化查询语法、加filter缓存，但服务器资源不足才是最常见的根因,建议优先按以下顺序排查：

1. 用top看CPU和内存占用，确认ES进程没有大量swap
2. 用iostat查看磁盘IO等待，若util长期超过80%，问题多半在磁盘
3. 用curl localhost:9200/_nodes/stats查看JVM的GC次数和堆占用，若老年代持续增长，说明内存不够
4. 用curl localhost:9200/_cat/thread_pool/search?v查看搜索线程池是否有拒绝

如果确认是资源瓶颈，再怎么改查询语句都是治标不治本,扩容服务器才是唯一解。

Q&A

ES全文检索比MySQL的like查询快在哪里

MySQL的like查询无法使用B+树索引优化（除非前缀匹配），必须全表扫描并逐行进行模式匹配，数据量越大耗时越长，且扫描期间MySQL不释放CPU资源，而ES基于倒排索引，将文档内容先切词建立词项到文档的映射关系，查询时直接通过词项锁定文档ID集合，再针对命中的少量文档做算分排序，复杂条件还能借助跳表进行合并求交。倒排索引的结构决定了搜索时间只与关键词命中的文档数相关，与总数据量几乎无关,这就是ES全文检索的核心优势。

ES全文检索服务器一般需要多大内存

规格取决于数据量和查询并发，但有一条通用底线：给JVM堆分配机器一半内存，同时确保机器总内存至少16GB，几十GB的日志量用16GB总内存可以跑，百GB以上从32GB起步，TB级数据量单机内存通常要配置64GB以上，或者直接规划三节点以上的集群，此外磁盘预留空间至少等于数据总量的20%,否则段合并过程中磁盘写满会直接导致索引只读。

申请ES服务器时应该把配置重点放在哪一项

数据量决定内存，并发量决定CPU，延迟敏感度决定磁盘类型，三者比重不同时答案完全不同，多数情况下ES的瓶颈首先出现在内存和磁盘IO上，这两项预算不要压缩，CPU可以后期扩容,但磁盘和内存的升级往往需要迁移数据才能完成。