Peng Yu <pengyu...@gmail.com> wrote: I have never seen such a dramatic difference in non-sqlite3 > operations. For example, cat has some difference but is ~13%. > > $ time cat file.sqa > /dev/null > > real 0m7.282s > user 0m0.067s > sys 0m2.371s > $ time cat file.sqa > /dev/null > > real 0m6.316s > user 0m0.062s > sys 0m2.319s > > How to prove the large time difference of sqlite3 is indeed due to > cache and where is the cache? >
You can try clearing Linux file system cache to convince yourself that cache misses contributes to performance drop. Run this as root: # sync; echo 3 > /proc/sys/vm/drop_caches See: https://www.tecmint.com/clear-ram-memory-cache-buffer-and-swap-space-on-linux/ Then run your test again (not as root!). Clearing Linux file system cache can of course degrade performance a lot the first time you re-run your test if it's I/O bound. The 2nd time, things will probably be cached and fast again. > Why the caching used by sqlite3 can not persist for a longer time? File system cache only hold the least recently used pages. If other applications do I/Os, Linux will eventually have to discard old pages to accommodate for more recently used ones. To persist longer, you need to have more memory and/or use less memory (kill unused programs...). All unused memory is used to cache files. Dominique _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
