Skip to Content
Author's profile photo Former Member

Testing lockless cache in ASE16SP02

In our 64 engine systems we generate 250 to 300 billions logical IOs in a given day. At peak loads we run out of CPU resources mostly from SPINLOCK Contention. We currently have 22 named caches. We have a good sprinkle of “Relaxed LRU” caches among the 22 where in we bind small but frequently used tables. We know for a fact these are good candidates for Lockless cache. The size of the cache is larger than the elements it is bound to.

Here is the test results we have from one such lockless cache we had configured. Jeff Tallman was in our premises last Friday and we were seeking his advise on what should be criteria for turning on Lockless cache. His matrix was physical reads to logical reads ratio. However, we also dwelled into size of the cache vs sum of pages read (sum of buffers to lru and buffers to mru). I think we will have to test further to see on best we can minimize spins on our caches.

Lockless Cache feature shows great promise in our desire to scale up. We are introducing 80 engine/3TB boxes boxes into our estate and I am looking forward to the task of scaling these new beasts.

BTW: We had a great session from Jeff on ASE16SP02.




Lockless Relaxed




Mixed Relaxed LRU




Mixed Strict LRU




Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Thanks for the feedback.

      Could you give us advice on how you decide on using a Relaxed LRU cache.

      I tried them in the past and in my case they caused a slow down. I'm assuming I didn't have the right table for that cache and/or I'd sized it badly.


      Author's profile photo Former Member
      Former Member
      Blog Post Author

      The rule of thumb I would follow for Relaxed LRU is

      Cache Size > size of the bound tables + indexes

      Some of our caches which are relaxed are small sized (5GB or so). We have small lookup tables bound to it. The LIOs are very high on these caches. The spinlock contention is manageable (definitely way better than "Strict").