14.11.2016 20:27, Thomas Steinmaurer wrote: ... > So, with 16G RAM and an OLTP emul database with ~ 2,9G, it is still > recommended with Firebird 3 SS and the shared page cache, to rather use > a smaller number, lets say 50K and keep the FileSystemCacheThreshold at > 64K to have the file system cache enabled? Or e.g. increase both > DefaultDbCachePages and FileSystemCacheThreshold?
I have no universal answer :) 50K pages for Firebird SS page cache looks like good starting point for investigations > The main question is how to utilize cheap and available RAM best. It is already utilized by OS : file system cache, temporary files for sorting and GTT's, etc. Why people looks at one part of whole system - Firebird process - and often forget about all other parts ? ... >>> From my understanding, file system cache is much more important for >>> SC/CS than with a large single page cache in SS. Is this assumption wrong? >> >> SS requires less support from file system cache for reads but still need >> it >> for writes, especially in OLTP environment. > > Why writes in particular? Without file system caching, on "spinning disk (7200K)" you'll have 100-150 writes per second - this is upper estimation for transactions per second as every tx start requires header page write and every commit requires TIP page write. Firebird page cache will amortize many (or most) reads, but every write without file system cache is long and hard physical write. Careful write not allows us to avoid random IO, unfortunately. Large shared page cache (in SS) helps to avoid most writes up to commit time but commit iself will be slow. BTW, SSD could help in such scenario. Regards, Vlad ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
