在做集群规划的时候,到底需要给集群的每个节点多少个核心数?这个问题一直困扰了我很久。最近一段时间做千亿数据,PB存储量集群规划的时候,突然想明白了这件事,大致可以用一个公式来计算!
我觉得这是一个非常重要的问题,非常值得重视。其实所谓的集群规划,无非就是根据数据量评估出需要的es节点数,每个节点应该需要多少的CPU,多少的磁盘,多少内存。其中磁盘毋庸置疑,每个节点不要挂过多的数据,如果你想要保证性能,每个节点不要超过4T数据。多了以后堆的压力会比较大(根据实际的生产经验)。至于内存,内存基本上也就是每个节点31G,不超过32G,防止指针压缩失效而浪费堆内存。我测试的上限值是32.95G。至少留一半的内存给linux的 OS Cache。也就是每个机器的标配是64G内存,最大4T硬盘,有条件的数据控制到2.5T以内。磁盘有条件的可以选择SSD,且做raid0。唯独cpu核心数难计算,如果不熟悉es底层检索原理,很难算出来每个节点需要多少个核心数。
下边我把核心数的计算推导成一个公式!
ES 集群规划 核心数计算公式
在es中,查询是search线程池去处理请求的。请求到了底层会落到分片上,分片是分配线程资源的最小单元!所以我们应该先计算出来需要的查询线程数
search thread pool = (单次请求命中总分片数 / 节点数) * 每秒最大并发数 * 单个分片的响应时间(换算成秒)
这里以最小集群规模,3个节点来计算。
假如单次请求命中的总分片数为15,那么每个节点5个分片。每秒并发数为10,单个分片请求时间为 0.2s(200ms )
search thread pool size
search thread pool size
根据官网给出的公式,search thread pool size
CPU核心数 *3 / 2 +1
For count/search/suggest operations. Thread pool type is fixed_auto_queue_size with a size of int((# of available_processors * 3) / 2) + 1, and initial queue_size of 1000.
1000是请求队列的大小
所以我们需要的核心数为:
search thread pool size
假如单次请求命中的总分片数为15,那么每个节点5个分片。每秒并发数为10,单个分片请求时间为 2s(2000ms )
那么想要满足以上的检索需求,则需要最少的核心数为100。显然,单台机器的CPU核心数不可能给那么多。即使CPU核心数给到,磁盘的IO也会受限。
理论上来说 单个节点CPU的核心数不超过32核心。在16核心 - 32核心之间。取决于磁盘的IO能力。另外也会受限于JVM的GC。所以实际情况,可以结合理论推导公式,结合压测情况,来给核心数。
做压测,做压测,一定要做压测。根据压测结果配合公式来确定最终需要的核心数!
标签:search,核心,单台,Elasticsearch,分片,计算公式,节点,pool,size From: https://blog.51cto.com/u_15812686/6132088