Druid调优指南(一)- Historical

【翻译自https://druid.apache.org/docs/latest/operations/basic-cluster-tuning.html

本文档提供Druid部署调优基础指南,涉及相关属性配置以及集群架构设想。

请注意,本文档提供一般性的指导原则和经验法则:对于集群调优来说,这些法则并不是绝对的,通用的,而且并没有完全覆盖到Druid属性调优的所有部分。

如果对于特定的case有疑问或者本文未尽事宜,请详询https://druid.apache.org/community/

Historical(历史节点)

Heap sizing(堆大小)

Historical节点中堆使用主要集中在:

     来自于segments中未合并的查询结果

     用于lookups的存储地图

通常情况下,调整Historical堆大小的经验规则:(0.5GB * CPU核数),上限约为24GB。这个公式并不是一个硬性标准,仅供参考。

如果堆太大,则可能会导致GC时间过长,因此要设置一个24G左右的上限。

如果在Historical节点上启动了缓存,则缓存存储在堆中,大小由druid.cache.sizeInBytes决定。

Historical节点上的堆耗尽,说明配置错误或者所用的方式导致集群过载

Lookups

目前处于试验阶段,暂不说明

Processing Threads and Buffers(线程和缓冲)

关于 Historicals:

druid.processing.numThreads(用于并行处理segment的线程数):通常设置为(number of cores -1),值设置的小不能充分利用cpu,超过核心数会导致不必要的cpu争用

druid.processing.buffer.sizeBytes:可设置500M

druid.processing.numMergeBuffers(用于合并查询结果的直接内存缓冲区数):numMergeBuffers:numThreads = 1:4,通常是一个合理的选择

Direct Memory Sizing(直接内存大小)

当历史节点处理查询请求时,它需要读取segments,此时,需要一些直接内存空间。

预估直接内存使用量的公式:

(druid.processing.numThreads + druid.processing.numMergeBuffers + 1) * druid.processing.buffer.sizeBytes

Connection pool sizing(连接池大小)

对于历史节点,druid.server.http.numThreads 应设置为略高于druid.broker.http.numConnections 数量和(集群中所有broker节点相加)

可以从每个历史节点接收50个查询和10个非查询开始对集群连接池进行调优

Segment Cache Size(缓存大小)

druid.server.maxSize:Coordinator节点能够分配给一个Historical节点 segment 总的数据大小

druid.segmentCache.locations:segment 存储所在历史节点的位置,这些位置所在磁盘的大小应该大于等于druid.server.maxSize

历史节点利用可用的系统内存(没有被jvm以及堆/直接内存缓冲区使用的内存)将segment文件映射到内存中,当查询到来时,不在内存中的segment将会被从磁盘分页(从磁盘移动到内存)

因此,druid.server.maxSize的设置应该使历史节点不分配过量的segment。随着 (free system memory/druid.server.maxSize)值的增加,内存中可以保留更多的segment,提供更好的查询性能。

Number of Historicals(历史节点的数量)

所需历史节点的数量依赖于数据量的大小。为了获取良好的性能,将需要足够的历史节点,以致于每个历史节点有一个好的比率(free system memory/ druid.server.maxSize),如上述 segment cache size部分描述的那样。

在对使用场景有足够的容错情况下,拥有较少的大型服务器通常比拥有较多的小型服务器要好。

SSD storage(SSD存储)

我们建议历史节点采用SSD存储,因为该节点处理存储在磁盘上的segment数据。

Total memory usage(总的内存使用)

根据如下指导来预估历史节点总的内存使用量:

Heap(堆):(0.5GB *  number of CPU cores) + (2 * total size of lookup maps) + druid.cache.sizeInBytes

Direct Memory(直接内存):(druid.processing.numThreads + druid.processing.numMergeBuffers +1) * druid.processing.buffer.sizeBytes

历史节点将会使用任意可用的系统内存(jvm、堆/直接内存缓冲区以及系统上其他进程未使用到的内存)来对磁盘上的segments进行内存映射。为了获取更好的查询性能,需要确保一个合适的比率(free system memory/ druid.server.maxSize),这样就可以在内存中保留更大比例的segments。

续接 Druid调优指南(二)

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,657评论 6 505
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,889评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,057评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,509评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,562评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,443评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,251评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,129评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,561评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,779评论 3 335
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,902评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,621评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,220评论 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,838评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,971评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,025评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,843评论 2 354