On Sat, Mar 24, 2012 at 09:53:47PM -0700, Roger Binns scratched on the wall:
> Yes, but the tools primarily come from the OS vendor. After all they have > to be able to compile and debug the code making up the operating system > and base applications. Which makes it all the more disappointing that so many of the vendor tools of are such moderate quality-- even the pay-for versions. > > True, but the OS doesn't typically cache filesystems on a ramdisk. > > Huh? There was no claim of ramdisks being used by the operating system as > a filesystem cache. No, there wasn't. I'm saying the OS shouldn't cache blocks from filesystems that reside on a ramdisk volume. There is no need. Device I/O is just as fast as the cache. > The claim was that memory used by a ramdisk is not available for use > as a cache. Yes, but if you're database is on a ramdisk-- and that's your primary performance concern for this system-- there is a greatly reduced need for filesystem cache space. The OS shouldn't need to cache blocks off the ramdisk, so the overall need for filesystem cache space is reduced. Things change if this is a general purpose system with many different process profiles, but if you have a single need strong enough to justify a ramdisk, you're already somewhat past that point. > > Caching slows things down and wastes memory. > > Really? Caches as a rule do not slow anything down. Having the OS cache pages off a ramdisk based filesystem adds a layer of indirection and consumes more memory. The point of almost all types of caches is to reduce the cost of an upstream process-- in this case physical I/O. If the upstream process (ramdisk I/O) is just as fast as the cache (filesystem pages in RAM), then the cache servers no real purpose, yet still consumes resources. The cache only slows things down and wastes memory. Filesystem caches are a huge win for traditional media, but not for ramdisks. That said, if a database on traditional media is not completely read dominated, the bottleneck is still going to be flushing pages all the way to non-volatile storage. If you want to be transaction safe, you can't get around that, and OS based filesystem caches can't speed up verified writes. Device-based non-volatile caches, perhaps, but that's getting pretty exotic for most SQLite deployments. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
