On Fri, Feb 17, 2017 at 8:37 PM, Richard Hipp <d...@sqlite.org> wrote: > On 2/17/17, Kim Gräsman <kim.gras...@gmail.com> wrote: >> >> Thanks, shrink_memory could come in handy. But this is not the problem >> we're trying to solve -- rather we want to claim as much memory as possible >> up-front to make mem usage deterministic and make it easier to diagnose >> other subsystems with run-away memory usage. > > In that case, consider using MEMSYS5 > (https://www.sqlite.org/malloc.html#experimental_memory_allocators). > You give SQLite a single big chunk of RAM up front, and that is all > the memory it will ever use. And it won't share any of it with any > other subsystems.
As I've said earlier, we don't want to risk SQLITE_NOMEM. But if we can combine sqlite_soft_heap_limit64 with SQLITE_CONFIG_HEAP, that might give us a nice self-adjusting system (where caches are flushed when heap is running low) in the rare cases that this might happen. Do the two play nice together? I guess the challenge is to find a good number for the limit, but we can afford to "waste" some memory to play it safe here. Thank you, - Kim _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
