On iOS during initial replication memory grows up to 300MB

[Yevgeniy Motov]

During initial db replication the memory grows up to 300MB. It does release most of the memory at the end of the replication however the app is getting memory warnings. The database that is being replicated is about 20MB. 

I ran the app through instruments and saw that memory is being allocated inside [CBL_RevisionList revWithDocID:revID:]. So seems like the docID objects are holding to the memory and not releasing until the end of replication.

It also takes a really long time to replicate, so ideally we need to somehow speed this up. 

Any ideas on how we can optimize it to avoid allocating so much memory? Please, let me know if any other information would helpful here?

Thanks,

Yevgeniy

[Jens Alfke]

On Jan 9, 2014, at 7:10 PM, Yevgeniy Motov <ymo...@gmail.com> wrote:

During initial db replication the memory grows up to 300MB. It does release most of the memory at the end of the replication however the app is getting memory warnings. The database that is being replicated is about 20MB. 

How many documents are in the database, and what’s the average size? Are there attachments?

Also, what are you using to measure the app’s memory usage?

—Jens

[Yevgeniy Motov]

There's about 600 documents. No attachments. Not sure about the size of each document... anyway I can check the document size on the client?

For memory usage I use 'memory report' in Xcode and also saw similar (although slightly less) memory increase in instruments.

--
You received this message because you are subscribed to a topic in the Google Groups "Couchbase Mobile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mobile-couchbase/B06f5Pzo72Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mobile-couchba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/1AC9D6F2-DD0C-44D2-B171-15AFAA30B41E%40couchbase.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Yevgeniy Motov]

Please, let me know if there's a way to optimize the replication and fix the memory hike? Thank you!

On Thursday, January 9, 2014 11:11:08 PM UTC-5, Yevgeniy Motov wrote:

There's about 600 documents. No attachments. Not sure about the size of each document... anyway I can check the document size on the client?

For memory usage I use 'memory report' in Xcode and also saw similar (although slightly less) memory increase in instruments.

On Thu, Jan 9, 2014 at 10:34 PM, Jens Alfke <je...@couchbase.com> wrote:

On Jan 9, 2014, at 7:10 PM, Yevgeniy Motov <ymo...@gmail.com> wrote:

During initial db replication the memory grows up to 300MB. It does release most of the memory at the end of the replication however the app is getting memory warnings. The database that is being replicated is about 20MB. 

How many documents are in the database, and what’s the average size? Are there attachments?

Also, what are you using to measure the app’s memory usage?

—Jens

--
You received this message because you are subscribed to a topic in the Google Groups "Couchbase Mobile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mobile-couchbase/B06f5Pzo72Y/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mobile-couchbase+unsubscribe@googlegroups.com.

[Jens Alfke]

On Jan 9, 2014, at 7:10 PM, Yevgeniy Motov <ymo...@gmail.com> wrote:

I ran the app through instruments and saw that memory is being allocated inside [CBL_RevisionList revWithDocID:revID:].

I don’t think so. That method is an accessor that doesn’t allocate any memory (take a look at its source code.)

I’ll try running a largish replication and look at memory usage in Instruments, and see if I can reproduce this.

Please, let me know if there's a way to optimize the replication and fix the memory hike? Thank you!

If you have an urgent issue that you need to get fixed, then please file it as an issue in Github.

—Jens

[Jens Alfke]

I just ran a pull replication of a 15MB database with 5000 documents. Heap usage stayed between 2MB and 3MB the whole time.

What may be going on in your app is that your UI code has a live-query running that has a very large result set — i.e. it matches all or nearly all docs in the database, and the emitted value is either the entire doc or a large portion of it. As the replication continues, the query keeps updating and its cached result set (CBLLiveQuery caches the result set in its ‘rows’ property) is what’s taking up all the memory.

The way to fix this is to change the query or the map function to return only the data your UI needs. For instance you can emit only the doc properties that are needed to draw the UI, and/or use paging techniques to limit the number of result rows. (CBLUITableSource doesn’t currently implement paging, although it could. That would be a great addition for someone to implement, hint hint.)

—Jens

[K Beyer]

Thanks for the tip - setting limit on the live queries makes a huge difference!

Will look into complexity of adding paging support to CBLUITableSource.  

[AJ]

I never investigated why exactly, but I had similar problems, a few months ago (just before beta 2 from memory).

My app would suck up memory, get to about 300MB from memory, and often get terminated as a result.

In my case I just turned off zombies in Xcode and everything just started working.  Zombies on, crash.  Zombies off, AOK.

Again, I never checked further, as everything seemed to work OK in the end, but this may help investigations.

[Jens Alfke]

On Jan 14, 2014, at 2:00 PM, AJ <ad...@great-sky.net> wrote:

In my case I just turned off zombies in Xcode and everything just started working.  Zombies on, crash.  Zombies off, AOK.

As expected. Zombie mode (NSZombieEnabled) should only be turned on when you’re diagnosing crashes due to messaging dealloced objects. It intentionally prevents any object’s memory from being reclaimed after dealloc, so your process's memory usage will grow continuously.

—Jens