es 插入索引的正常性能应该是多少？

[winRain]

背景：由于公司业务需要，引入了 es 。于是，我在公司内网虚拟机（ 8c8g ，固态硬盘）上用 docker compose 启动了一个 es 和 kibana ，并给 es 的 jvm 分配了 6g ，并配置了一些 jvm 参数。

当我用 spring data elasticsearch 的 repository saveAll 操作去批量插入 100 条数据时，发现耗时在 200 ms 左右。其实我感觉这个速度跟正常用公有云的 rds 批量插入数据是差不多了。

那么问题来了，es 这个插入速度是正常的吗，是不是还有其他优化参数可以配置，用来提升这个插入性能？如果这样是正常的，那么 es 在插入和查询上相比于 rds ，在实际应用中，优势体现在哪些地方呢？

[DonaldY]

100 条插入要 200ms ，那 qps 是 500 。

优化的话，内存明显不够。ES 堆内存 6G ，总内存 8G ，那么就剩 2G ，要给 kibana 、docker 、机器本身，剩下给 os cache 就没多少。

详细优化可以看官网，很全了： https://www.elastic.co/guide/en/elasticsearch/reference/7.9/tune-for-indexing-speed.html#tune-for-indexing-speed


优势写入快，近实时查询，且能分词。

[strawberryBug]

不正常。
生产单实例平均每秒写入 8k 条，每条约 0.7kb 。

[totoro52]

es 和 kibana 两个内存猛兽你全跑了，剩给系统的时间不多了

[billlee]

1. es 需要使用系统 page cache, 一般配置 jvm 堆只能使用一半的系统内存，也就是说 8g 机器配置 4g 的堆，剩下的内存也不能用来跑 kibana 了
2. 延迟 != 吞吐量，提高并发可以增大吞吐量
3. 有两个关键参数影响 es 的写入速度：translog 的 flush 间隔和 reindex 间隔
4. 数据库系统对磁盘 I/O 性能敏感，没有人会在生产环境拿虚拟机来跑 es 或 rdbms 的，即使公有云的服务也是直接在物理机上跑

[mosliu]

刚才看了眼
用的 bulkProcessor 240 多条用大约 200ms 吧。
平均插入的数据单条在 40+ kB
折合每秒能力在 1k 以上

分析：这个的内存分配极为不合理啊
es6G
kibana 和系统 还有 es 的 cache 一起去分 2G ？？？

[winRain]

@mosliu 其实我 200 多条的数据插入速度也跟你这个差不多。但是 kibana 和 es cache 分 2G 这个我之前确实不太懂，没考虑到，那如果按这个 8g 的虚拟机来的话，内存应该怎么分配呢

[winRain]

@DonaldY 感谢大佬回复，我看过这篇帖子，也试了里面说的一些方法，但是提升仍然也是不明显

[winRain]

@billlee 我后面也试过公有云的 es ，用的免费版那种，对比下来跟我虚拟机搭的这个环境也差不了多少。在我最刚开始的想法中，es 的 bulkindex 应该是可以类比为 MySQL 的批量插入的，而我用公有云的 rds 批量插入几十条数据，实际可能几十 ms 肯定不到 100 ms ，那么我刚开始觉得，es 既然是专门用来做搜索的，批量插入这种应该不慢，起码我在公有云上随便搭个 redis ，性能也就几十 ms 。所以我一直想说，有没有什么办法可以让 es 的批量插入 几十 条数据的速度也能在几十 ms

[mosliu]

@winRain 嗯 我这边同时有 10+ 个程序同时在操作 es 吧...

记得新插入的数据是放在内存里面的。等定时再去持久化。这个时间可配置，我忘了是啥了。

你这内存分配确实不合理。一般至少留和 heap 一样的内存给 es 。

我没用过很大的集群。只是十几个节点（ 12C ，64G ）的小集群的情况 仅供参考

[winRain]

@mosliu 我在另一台 32 g 内存的云服务器也按同样的方式搭了 es 和 kibana ，这样来看的话，应该不存在上面说的没有 os cache 的问题，但速度还是 100 多 ms 。这样的话，抛去硬件因素，es 有没有可能通过一种搭建方式，能够达到 20 多条用 bulk index 也能达到 50 ms 以下的插入速度？

[mosliu]

开 20 线程 不用 bulk 直接 indexrequest