Hi Richard, On Sat, Jan 14, 2017 at 2:17 PM, Richard Hipp <d...@sqlite.org> wrote: > On 1/13/17, Kim Gräsman <kim.gras...@gmail.com> wrote: >> >> In an effort to reduce memory usage/fragmentation, we're trying to >> configure SQLite to allocate as much memory as necessary up-front >> (based on the excellent information in >> https://www.sqlite.org/malloc.html). >> > > The easiest way to do this is to compile with SQLITE_ENABLE_MEMSYS5 > then give SQLite 10 or 20MB of memory to use at start-time by invoking > > sqlite3_config(SQLITE_CONFIG_HEAP, malloc(10000000), 10000000, 64); > > or similar. The page-cache and scratch memory will both be > automatically served from this pool if you take no further actions, > and this usually works just fine. Use sqlite3_memory_highwater(0) to > see how close you are getting to memory exhaustion so that you can > judge if 10MB is too little or too much and make appropriate changes. > > Note that you cannot increase or decrease the amount of memory > available to memsys5 at runtime, except by completely closing all > SQLite database connections and interfaces, running sqlite3_shutdown() > and then redoing the sqlite3_config() call above with the new memory > size.
I like the sound of 'easiest' :-) Two concerns; 1) If I configure a global SQLite heap with SQLITE_CONFIG_HEAP, won't I just trade malloc heap fragmentation for SQLite private heap fragmentation? Or does SQLite's fragmentation-prevention strategy work well even in the face of multiple page sizes and connections? 2) What happens if the configured heap is depleted? Thanks, - Kim _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
