SQLite page cache - memory never recovered

[Todd Orler]

Hi,

We’ve recently been investigating memory usage of our iOS app, and discovered that when using the CBLManager sharedInstance, opening lots of databases, and then closing them (releasing the refs to them), the SQLite page cache memory is not released for those previously opened databases.  We have observed this by watching memory usage in Instruments.

One of my colleagues reported that when constructing our own instance of CBLManager, releasing the refs on the databases would cause the SQLite page cache to release the associated memory for those databases.  As I write this, I’m not sure if our CBLManager instance was also released in order to recover the memory (I’ll try to find out - but he’s currently on vacation).

We’d like to know if this sounds familiar, or is unexpected.  Is the answer to simply use our own CBLManager instance?  I ask, because it seems like a bad idea for the sharedInstance to never release this memory, and I’m wondering if that’s just a bug that needs fixing.

Thanks,

-Todd

[Jens Alfke]

On Aug 22, 2014, at 1:35 PM, Todd Orler <jto...@gmail.com> wrote:

We’ve recently been investigating memory usage of our iOS app, and discovered that when using the CBLManager sharedInstance, opening lots of databases, and then closing them (releasing the refs to them), the SQLite page cache memory is not released for those previously opened databases.

CBLDatabases don't close when you release your refs to them; they only close when the CBLManager is closed.

(Basically, "opening lots of databases" wasn't seen as a common operation. We expected the typical use case to be that you open one or a few databases and keep using them.)

What's your use case for opening lots of databases? I can add a -close method if it's important, I'm just curious why you need a lot of dbs.

—Jens

[Tim Gogolin]

Following up on Todd's question; I work on the same team, so can answer your question before West Coast America wakes up...

Our document model is each user "project" is backed by a CBL database.  Typically a user might have less than a dozen "projects" but it is conceivable to have as many as a hundred on an iOS device.  Our UI presents each project as a cell in a UICollectionView and we assumed that opening each database to gather some display information, AND THEN RELEASING all references to the database would not put us in a position of burning large quantities of RAM, but we found that large numbers of projects on low RAM iOS devices are a real problem for us.

Once a user has interacted with the grid-view, and chosen a project to open, we only deal with content from that one single database, and since our app is somewhat RAM intensive by its nature, at this point we REALLY don't want to pay for the RAM burden from the previous databases that were only opened to present a list of projects.

A -close method on a CBLDatabase would be very helpful to us.

Public access to -allOpenDatabases (currently in CBLManager+Internal.h) would be handy as well, so we could ensure all open databases were closed before opening a single database for an edit session on a project.

-- Tim Gogolin

[Jens Alfke]

On Aug 25, 2014, at 7:49 AM, Tim Gogolin <tgog...@gmail.com> wrote:

Our document model is each user "project" is backed by a CBL database.  Typically a user might have less than a dozen "projects" but it is conceivable to have as many as a hundred on an iOS device.  

Hm, OK, that makes sense. Although you could put all the projects in a single database (but it would take some refactoring of your data model.)

I'll look at adding a public -close method. Filed as #429.

—Jens