elasticSearch的搜索速度,严重依赖于system cache,尽可能让所有的索引都通过内存缓存。
通常情况下,索引全部被内存缓存时,搜索速度是几毫秒到几百毫秒,如果从磁盘读取数据,肯定超过秒,有可能是1s,5s,10s。
查看索引的大小:
curl -k -u uname:upass "https://127.0.0.1:9200/_cat/indices?v&pretty"
结果如下:
D:\>curl -k -u uname:upass "https://127.0.0.1:9200/_cat/indices?v&pretty"
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open .items-default-000001 mOEiC3rXR1-XMDp1soa0vw 1 1 0 0 225b 225b
yellow open .lists-default-000001 poClkftKRMK7htN58Sh8uA 1 1 0 0 225b 225b
green open metrics-endpoint.metadata_current_default CqOKMDC7T32jN1LU6xArNg 1 0 0 0 225b 225b
yellow open doc2 R9rIVYJjRH-lLN5RN_k8SQ 1 1 4294 0 1.3mb 1.3mb
yellow open doc YspvOw9XQ02LuoFLRam4ZA 1 1 22267 24 5.2mb 5.2mb
这里的 v 表示返回表头,这里的pretty表示美化输出结果。
其中,green 表示最佳状态,yellow 表示数据和集群可用,但是集群的备份有的是坏的
如果是红色,则表示数据和集群都不可用。
docs.count表示索引总数,store.size表示索引大小,pri.store.size表示主分片占用的磁盘空间大小。
一般来说,要保证给予的es内存(总内存)大于索引大小,以便es能缓存所有的索引。
如果数据太大,或机器内存太小,可考虑仅把搜索字段加入到es中,其他字段存放在sql/hbase,首先通过es查询出doc_id,然后再查询hbase(适合海量数据存储),此时速度会比较快,例如es花费20ms,hbase花费10ms,处理处理返回前端大约50ms,而如果直接把大量数据存储在es中导致es从磁盘读取文件,数据量大的情况下搜索长达5-10s。
es内存和os cache详细
elasticSearch的jvm分配的内存,是堆内存,堆内存会发生gc(lucense则是依赖于os cache,并不是靠jvm内存处理数据),堆越大,则在发生gc时会更慢,则在满足条件下堆越小越好。
es依赖于lucense,而lucense应该得到足够的内存。简单划分,es和luncense各占一半,给es多大内存,预计lucense也占这么大,所以留出一半的内存给lucense。
换句话说,es库大小1gb,则简单来看lucense给1gb(确保全部数据缓存),es也给1gb(es堆大小)。
新增数据过程:往es写入数据,则首先经过es的堆内存,然后写入磁盘,再被os cache读取。
数据搜索过程:首先读取os cache,如果读取不到,则从磁盘中读取数据并在堆内存中处理,响应数据并将数据缓存到os cache。
总体来看,os cache作为真正的缓存系统,而es的堆内存作为交换。
给jvm更少内存,64g服务器,给jvm最多16g
es官方是建议,es大量是基于os cache来进行缓存和提升性能的,不建议用jvm内存来进行缓存,那样会导致一定的gc开销和oom问题
给jvm更少的内存,给os cache更大的内存
64g服务器,给jvm最多16g,几十个g的内存给os cache
os cache可以提升doc value和倒排索引的缓存和查询效率
本篇完,还有疑问?留下评论吧