Solr
  1. Solr
  2. SOLR-3486

The memory size of Solr caches should be configurable

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: search
    • Labels:
      None

      Description

      It is currently possible to configure the sizes of Solr caches based on the number of entries of the cache. The problem is that the memory size of cached values may vary a lot over time (depending on IndexReader.maxDoc and the queries that are run) although the JVM heap size does not.

      Having a configurable max size in bytes would also help optimize cache utilization, making it possible to store more values provided that they have a small memory footprint.

      1. SOLR-3486.patch
        12 kB
        Adrien Grand
      2. SOLR-3486.patch
        13 kB
        Adrien Grand
      3. LFUMap.java
        5 kB
        Adrien Grand

        Activity

        Adrien Grand created issue -
        Hide
        Adrien Grand added a comment -

        This patch makes the maximum memory size of LRUCache configurable. It would be nice to add the same feature to the concurrent caches although I expect it to be a little more tricky.

        Show
        Adrien Grand added a comment - This patch makes the maximum memory size of LRUCache configurable. It would be nice to add the same feature to the concurrent caches although I expect it to be a little more tricky.
        Adrien Grand made changes -
        Field Original Value New Value
        Attachment SOLR-3486.patch [ 12529161 ]
        Hide
        Shawn Heisey added a comment -

        This is an awesome idea. SOLR-3393 is a new implementation of LFUCache, I'll have to figure out how to include this, unless you want to give it a try.

        Show
        Shawn Heisey added a comment - This is an awesome idea. SOLR-3393 is a new implementation of LFUCache, I'll have to figure out how to include this, unless you want to give it a try.
        Hide
        Adrien Grand added a comment -

        Hi Shawn,

        I modified the patch in order to make it easier to add this functionality to other cache implementations. All you need to do for SOLR-3393 to support maximum memory size is to split your implementation into a LFU map (a regular map, with no evictions) which iterates (entrySet().iterator()) in frequency order and a LFU cache (that will probably extend or wrap this LFU map). Then to have a LFU cache with a fixed max mem size, just wrap your LFU map into a new SizableCache instance.

        Show
        Adrien Grand added a comment - Hi Shawn, I modified the patch in order to make it easier to add this functionality to other cache implementations. All you need to do for SOLR-3393 to support maximum memory size is to split your implementation into a LFU map (a regular map, with no evictions) which iterates (entrySet().iterator()) in frequency order and a LFU cache (that will probably extend or wrap this LFU map). Then to have a LFU cache with a fixed max mem size, just wrap your LFU map into a new SizableCache instance.
        Adrien Grand made changes -
        Attachment SOLR-3486.patch [ 12529696 ]
        Hide
        Shawn Heisey added a comment -

        It's going to take me a while to digest what you've just said, but my first thought is that I can't change the implementation without destroying the O(1) nature. The cache is implemented in two parts - a simple map (HashMap) for fast lookup, and an array of sets (LinkedHashSet[]) for fast frequency ordering. When the frequency for an entry needs to be changed, it is removed from one set and added to another.

        Although it's not implemented as an actual iterator method, I have code to iterate over the array. I should probably create an iterator and backwards iterator, just to eliminate some duplicate code. If I don't already have a remove method, I should be able to add one.

        Show
        Shawn Heisey added a comment - It's going to take me a while to digest what you've just said, but my first thought is that I can't change the implementation without destroying the O(1) nature. The cache is implemented in two parts - a simple map (HashMap) for fast lookup, and an array of sets (LinkedHashSet[]) for fast frequency ordering. When the frequency for an entry needs to be changed, it is removed from one set and added to another. Although it's not implemented as an actual iterator method, I have code to iterate over the array. I should probably create an iterator and backwards iterator, just to eliminate some duplicate code. If I don't already have a remove method, I should be able to add one.
        Hide
        Adrien Grand added a comment -

        I've just uploaded LFUMap.java based on your implementation of LFUCache. To have a LFU cache with configurable maximum size in bytes, just wrap an instance of this class into a SizableCache.

        I uploaded this file to show how SizableCache could be used with different kinds of backends. But building a LFUCache is a different issue. I think we should continue the discussion on LFUCache on SOLR-3393 and only discuss configurability of the mem size of Solr caches here. Feel free to reuse the code LFUMap.java if you want, just beware that I didn't test it much.

        Show
        Adrien Grand added a comment - I've just uploaded LFUMap.java based on your implementation of LFUCache. To have a LFU cache with configurable maximum size in bytes, just wrap an instance of this class into a SizableCache. I uploaded this file to show how SizableCache could be used with different kinds of backends. But building a LFUCache is a different issue. I think we should continue the discussion on LFUCache on SOLR-3393 and only discuss configurability of the mem size of Solr caches here. Feel free to reuse the code LFUMap.java if you want, just beware that I didn't test it much.
        Adrien Grand made changes -
        Attachment LFUMap.java [ 12529741 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Adrien Grand
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development