The block cache is an LRU cache of recently accessed CellStore blocks. It stores the blocks uncompressed. All of the Block cache access code is in CellStoreScannerV0.cc/h The block cache is only used for single row scans (i.e. random row key lookups). For long scans such as SELECT *, the cache is not used and a readahead mechanims is used to asynchronously fetch blocks. Take a look at CellStoreScannerV0.cc to get a good idea of how it is used.
- Doug On Mon, Mar 9, 2009 at 1:38 PM, Mateusz Berezecki <[email protected]>wrote: > > Hi Doug, > > I've managed to run some simple diagnostic tests and here's what I got > > [mate...@bebe log]$ grep -i " checkout " *.log|wc -l > 3949 > [mate...@bebe log]$ grep -i "checkin " *.log|wc -l > 251 > > There's a great difference in the number of checkins to cache and > checkouts from it. > Could you please outline it a bit more a block cache mechanisms and > design concepts. > > Could it be that having 3 scanners, and one of them being the long > living one, that long living scanner cases a block cache space > exhaustion? > > My app has 3 scanners, and one of them is used for a much longer > period of time than the other two which are just fetching single row > and get destroyed. > > The first long living scanner is actually used for sweeping through > the much larger table than the other two. > > > Mateusz > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Hypertable Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hypertable-dev?hl=en -~----------~----~----~----~------~----~------~--~---
