LRU chain latch contention could be the result of problems acquiring the latch, holding the latch too long, or both. If the operating system is CPU-bound, acquiring a latch could take a long time, because there simply are not enough CPU cycles to go around. Once the latch is acquired and the LRU chain-related kernel code is run, if CPU cycles are in short supply or there are limited unpopular free buffers, the LRU chain latches could be held long enough to cause significant contention.

So, first, there must be intense physical read activity. Second, the IO subsystem response time is very fast, passing the majority of wait time from read wait events to the LRU chain latch wait event. This contention requirement combination provides many resolutions options. Here are the options I consider, in no particular order.

* Tune physical IO SQL. As I mentioned, there can be no significant LRU chain latch contention without physical IO. So, from an application perspective, look for the SQL statements that perform the majority of block reads; that is, physical IO activity. Do whatever you can to reduce their physical IO consumption. This means classic SQL tuning, including indexing, as well as reducing the execution rate of the top physical IO SQL during the performance-critical times.