2

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

3

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

4

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

5

6

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

7

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

8

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

9

10

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

11

开 20 线程 不用 bulk 直接 indexrequest