最近使用druid来做广告平台的实时分析，发现后台内存占用长期为48G（一共56G），起初怀疑是因为每天dataSource数据量较大，如果druid将所有数据加载进内存处理则会导致这么48G的内存占用；但是在对dataSource做reindex处理后，dataSource大小缩减为5M左右的情况下内存仍然没有降下来。

通过对系统状况的综合考虑，现在有以下两个猜想：

• druid配置错误，即使dataSource很小，druid仍然抢着内存不放
• reindex操作错误，之前的segment并未删除，druid仍然加载内存导致内存溢出

其实这里之所以对问题产生的原因不确定，很大程度上是因为自己对druid这一套服务并不了解，经过查阅官方文档，了解到druid并不会把所有的数据加载进内存再处理。 而且，在执行reindex时，historical的数据会被删除，但deep storage内的数据仍然保留；在处理后续查询的过程中historical也不会按需重新将deep storage中的数据加载进来。如果确实有查询已删除segment数据的需求，可以先将数据从deep segment导入historical，之后再查询。如果想从deep storage中删除segment可以参考：🔗

historical并不会按需将所有数据存入segmentCache，只有在coordinator要求historical提前载入一个segment时才会把数据存入segmentCache。也就是说historical在加载数据时会先将所有的segment数据下载至本地硬盘，因此要注意在加载数据之前需要保证historical节点有足够的硬盘空间存放这些数据。

对于查询频率不高的历史数据，可以使用以下两个办法来降低成本：

1、在性能相对较差的机器上（比如使用机械硬盘而不是SSD）构建historical节点并设置tier规则来专门处理这些历史数据

2、另一个方法是对超过某个历史时期的数据设置较大的query granularity，从而降低segment大小；

具体的historical tier配置参考🔗