6 Replies Latest reply on Sep 17, 2013 11:17 AM by smalone

    Evictions with low number of entries

    smalone

      Hello,

       

      I have been seeing evictions occurring in caches where the  number of entries in the cache are extremely low for the maxEntries size. Below is the statistics for one of those caches:

       

      Max Entries: 1000

      Current size: 40

      Number of possible entries: 85 (There are only 85 distinct keys possible)

      Number of Hits: 30,579,978

      Number of Misses: 1,736,737

      Number of Evictions: 1,713,019


      For this cache I have the following configuration set:

      Max lifespan: No limit

      Max idle time: No limit

      Expiration: No limit

      Eviction Strategy: LIRS


      I am not sure why this is happening. I know that evictions occur based on the segment level, but the fact that only 40 out of 1000 possible entries are being cashed at a time seems a bit odd to me.


      Please let me know what other information you might need from me in order to answer my question. Any help would be greatly appreciated.


      Thanks!

        • 1. Re: Evictions with low number of entries
          vblagojevic

          Sean, yeah this is possible in LIRS if I recall correctly. I would have to review algorithm in details to confirm but in the meantime here is one question for you: why even turn on eviction if you only have 85 possible entries?

           

          Regards,

          Vladimir

          • 2. Re: Evictions with low number of entries
            smalone

            Hey Vladimir,

             

            Thanks for the response. We have a cache on this table because of the number of queries being ran on that key. It is about 60 million queries a day. Removing the cache would be quite detrimental to our system. So, if you're saying that the LIRS algorithm can cause the number of actual entries in the cache to be substantially lower than the max entries size, what is a good heuristic for setting our max size?

            • 3. Re: Evictions with low number of entries
              vblagojevic

              Sean,

               

              I am not saying to remove cache just turn eviction off for your cache. Configure your cache without eviction [1]. Does this make sense or are we not understanding each other? :-(

               

              Regards,

              Vladimir

               

              [1] Eviction - Infinispan 6.0 - Project Documentation Editor

              • 4. Re: Evictions with low number of entries
                smalone

                Ah! I'm sorry. I misread your comment. We cannot turn eviction off for all of our caches. We have several hundred caches. I was only using that one as an example. It's happening to all of them. We have memory constraints that require us to use evictions. I was just wondering why this case might be happening.

                • 5. Re: Evictions with low number of entries
                  vblagojevic

                  Yes LIRS will evict on segments and I think because your max entries is 1000 many more segments are created than actually needed. Try lowering max entries and/or try some other eviction algorithm.

                   

                  Regards,

                  Vladimir

                  • 6. Re: Evictions with low number of entries
                    smalone

                    Hey Vladimir,

                     

                    Thanks for responding again. So maybe I'm misunderstanding what the documentation says. It seemed like it was saying that segments are on a higher level than the max entries. So there could potentially be multiple cache maps in a single segment. Are you saying that this is incorrect and that in fact there are multiple segments in a single cache map? So this would mean that depending on the size of the cache could determine how many segments there are? If this is the case, what determines the size of a segment in order to determine how many reside in a cache map?

                     

                    Thanks,

                    Sean