Thanks Simon for quick reply. That main problem is that we are working with managed code and .net wrapper packaged in System.Data.Sqlite :)
Our Sqlite usage boils down to the following: 1. Fetch ready to use Sqlite database from server 2. Open one Sqlite connection 2. Working only with this one connection on the device for some period of time 3. After that we close a connection, delete db from storage 4. Fetch another database from server which may be completely different All connections get closed correctly because we wait for them to complete via .NET framework events. However virtual memory used by previous connections seems not to reset. Thanks, Pavlo. -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Simon Slavin Sent: Monday, November 10, 2014 6:27 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Virtual memory management of Sqlite core on Windows Mobile 6.5 with .NET CF 3.5 On 10 Nov 2014, at 3:45pm, Pavlo <pavlo_kru...@5pro-software.com> wrote: > Total Virtual memory allocations size made by Sqlite core seems to > grow in time in application process even though Sqlite connection get > closed on a regular basis. > For example if we do search touching several tables in sqlite database > it seems like sqlite core uses memory-mapped IO to do its job done > before returning results of a query. > There are of course other quires that touch almost all tables in the > database. It results in growing virtual memory footprint and fragmentation. > However it looks like Sqlite never releases that allocated virtual > memory space in application process even after we close the sqlite > connection and delete sqlite DB file from storage. > So you imagine if for several days database changes and sqlite engine > uses more and more memory-mapped pages we will end-up with "Out-of-memory" > situations. The last point may not be true (unless, of course, you have demonstrated it). SQLite is designed to intelligently use whatever memory is available. It can expand to fill a lot of memory, but then stop. Some things to check: Check the values returned from /all/ sqlite3_ calls, including ones which finalize statements and close connections. Anything that doesn't return SQLITE_OK can sabotage the way future calls use memory. Tracking down a missing _finalize() can completely change the memory footprint. Secondly, from your above description I assume that your application doesn't use SQLite all the time it's running. I think you're describing something that keeps a connection in use only part of the time. If that's the case, as a debugging aid you might try manually calling <https://www.sqlite.org/c3ref/initialize.html> sqlite3_initialize() and sqlite3_shutdown() in that code, then look at memory usage after those calls. This might magically fix your problem. But it might also allow you to figure out what your problem actually is. If SQLite is still using any significant resources after _shutdown(), something is wrong. > Is there any logic behind when sqlite engine releases VM memory? It shouldn't do anything very unusual. But SQLite will not close a connection if a resource (e.g. an unfinalized statement) still exists for the connection. And that's the sort of thing that might trigger what you are reporting. Simon. PS: Thanks for your detailed description of your setup and concerns, which made it unnecessary to ask lots of questions before answering. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
