This message was deleted.
# general
s
This message was deleted.
k
Enabling cache on historicals with
druid.historical.cache.useCache
and
druid.historical.cache.populateCache
( https://druid.apache.org/docs/latest/configuration/#historical-caching) enables the on-heap caffeine cache for partial query results https://druid.apache.org/docs/latest/configuration/#cache-configuration This is different from the segment cache, which is the memory-mapped segment file cache. Not sure if you’ve seen https://druid.apache.org/docs/latest/querying/caching/
a
Thanks @Kyle Hoondert While I understand the
caffeine
part of the cache, I want to understand the memory mapped segment file cache. How to enable it?
My understanding from mmap is that some of the segments in disk will be mapped and there will be less paging. If that's the case how do I control this parameter like I have TB's of data in each historical (segment cache location on disk) I have around 280 GB FREE system memory on each historical.
Copy code
Direct Memory =28G
Merge buffer =500MB
numThreads=45
Is there a specific parameter to be configured to control how much to mmap. I assumed it could take a lot of RAM to map the underlying segment while my pod does not consume more than 50GB.
k
You don’t configure it - it is managed by the OS. Any free memory will be used to cache segments which have been recently accessed https://druid.apache.org/docs/latest/design/historical/#loading-and-serving-segments-from-cache
a
This is little strange considering the fact pod memory never goes beyond 48 Gb Each query I run queries 7 day of data, each hour has 35 segments of 500mb each. And 28G is Maxdirectmemory
Is there a possible metric which could indicate this mmap of segments
k
Maybe something like
Copy code
$ cat /proc/meminfo | grep Mapped
Mapped:           178172 kB
🙌 1
a
Thx
I checked it again, most of the RAM is consumed by
buff/cache
that is consuming around 250 gb
Whereas
map_count
is near 55000