>> Ah, this sounds interesting. So, (total fetches - adjacent fetches) >> gives me some kind of unique fetches from the cache? > > Yes, I would hope so. > >> I have a dream (*g*): Why shouldn't Firebird be able to automagically >> increase RAM usage beyond the strict pattern (page buffers * page size), >> if a set of very frequented pages don't fit into the cache, or at least >> tell the DBA/user somehow that increasing the cache by a factor X allows >> the server to hold the page hotspots in RAM. > > Handling memory allocation automagically may sound like a clever idea, > but let's don't forget that DBAs often have to set up the higher limit > of the resource consumption, so the cache limit is still likely to > persist.
Sure, an upper limit always needs to be taken into account. > But perhaps it could be disabled by default (targeted to > dedicated hosts) or maybe measured in 50% of available RAM instead of > using the fixed number of pages. > > As for telling the DBA about the need to increase the cache, IMO this is > what the MON$ tables should be used for. > If they don't provide that > information nowadays, then it should be implemented. Feel free to > suggest how it could be done ;-) The information is there, although the mix of pointer and data pages in MON$PAGE_FETCHES is probably misleading when e.g. calculating the number of fetches per physical read. Your proposed new formula might help here. >> What are the key disadvantages of using large page caches with CS and SC >> in both, OLTP and OLAP patterns? We have been told to use a rather >> smallish page cache for these architectures, even if plenty of RAM might >> be available. Does this also apply to a typical OLAP deployment with a >> heavy read access pattern on possibly a very large database with a >> largish server with a lot of RAM. > > I'd say that a big page cache is bad for OLTP but good for OLAP > patterns. But the Classic architectures also benefit from the file > system cache, so there should be some kind of balance. Also, some > Windows versions are suspected in giving the file system cache too high > priority thus possibly swapping out the pages of the process working > set, so a largish internal page cache could prove itself to be a bad > idea in this case. With all that stuff, there are quite some variables involved here to optimize Firebird in respect to RAM usage for different acccess patterns, OS, database size, number of concurrent connections etc. Especially file system cache vs. Firebird cache for better performance is worth a separate discussion I think. This all asks for some kind of white paper ... ;-) Regards, Thomas ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
