litehelpers / cordova-sqlite-evplus-ext-legacy-build-free

TODO INCORRECT PACKAGE NAME: Cordova sqlite storage plugin, premium enterprise legacy support (GPL or commercial license) for Android, iOS, and Windows
Other
10 stars 9 forks source link

Memory Issue #1

Closed nishadchenicheri closed 8 years ago

nishadchenicheri commented 9 years ago

We replaced the enterprise plugin in the sample project shared earlier(https://github.com/litehelpers/Cordova-sqlite-storage/issues/319) , and performed the same tests to check the memory usage. However we noticed that when we do a bulk CRUD operations, the memory shoots up, but the drop in memory on device idle state(approx 1 min) is between 0.1-0.5 MB. Since our actual app uses lot of SQLite operations, the memory gradually increases which results in app crash. Kindly suggest if we can do anything to improvise the memory release.

Attaching the screenshot that has the profiling details for your reference. memory usage

The source code is available on https://github.com/nishadchenicheri/SQLite-Enterprise-Memory-issue

brodycj commented 9 years ago

What kind of a device do you see this crash on?

UPDATE FYI article for reference: http://stackoverflow.com/questions/6044147/ios-memory-allocation-how-much-memory-can-be-used-in-an-application

nishadchenicheri commented 9 years ago

We use ipod Touch with iOS 8.2, 8.3 and 8.4 to test the app

brodycj commented 9 years ago

We use ipod Touch with iOS 8.2, 8.3 and 8.4 to test the app

Do you know which model of iPod Touch you are using?

Also, do you know how much memory used at the time of the crash?

nishadchenicheri commented 9 years ago

The model we use is MC903J/A We have noticed the app crash when the memory reaches above 200 MB as seen in trace. We launch the app in XCode and use the instruments to verify the memory allocations. We have noticed that the app either crashes or freezes at this moment.

brodycj commented 9 years ago

Your screenshot shows the memory usage up to 28-29 MB. It would help me if you can make the test program that shows the memory usage increase to 200 MB.

nishadchenicheri commented 9 years ago

The app crash on reaching 200 MB is the actual app that we have developed and not the attached sample app. We were trying to simulate the 200 MB memory shoot in the app attached earlier but find it difficult since it requires multiple iterations of CRUD operations. We have updated the source code to insert and select 5000 rows individually. Multiple iterations of inserts and select would simulate memory rise.

The source code is available on https://github.com/nishadchenicheri/SQLite-Enterprise-Memory-issue

We ran a test and the findings are mentioned below: The sample app launch size was 12.6 MB On first insert of 5000 rows memory grew until 29.6 MB. Drop in memory on idle state is 0.1 MB which results to 29.5 MB. On selecting 5000 rows memory grew until 41.3 MB. Drop in memory on idle state is 0.1 MB which results to 41.2 MB.

The next set of operations will start from 41.2 MB We have noticed that the memory always continues to grow upon each operations. Kindly advise.

brodycj commented 9 years ago

I will try this early next week and keep you posted, thanks!

brodycj commented 9 years ago

I tried running this in the iOS profiler with INSERT, UPDATE, and DELETE of 25000 rows and for some reason it seems to be the Javascript part that is consuming most of the memory without releasing it. Unfortunately Xcode does not give me a way to profile the memory consumption in Javascript for an iOS app. My next step is to work on a special version that works in a browser and profile the Javascript there. I will try to have something later this week.

brodycj commented 9 years ago

I had someone help me look at a version of the test running in a Chrome with INSERT of 25000 rows using profiling tools and he pointed out to me that a major issue was issuing a timer for each executeSql() call on the database object. I am planning to fix this sometime in the future but highly recommend that you use a transaction instead. When I modified my version of the test program to use a transaction for the INSERT statements, it was using much less memory.

Then I tried an INSERT of 250000 rows in a transaction and the Javascript was using approximately 120MB. When I tried it again, it would go up to approximately 230 MB or so, then back to approximately 120 MB.

nishadchenicheri commented 9 years ago

Sorry about the late reply. The actual project that we developed uses ngCordova to execute the SQL queries and the execute function is within a transaction. The ngCordova execute function code looks like below

execute: function (db, query, binding) { var q = $q.defer(); db.transaction(function (tx) { tx.executeSql(query, binding, function (tx, result) { q.resolve(result); }, function (transaction, error) { q.reject(error); }); }); return q.promise; }

Let me know if you see any flaw in above code.

kanoshin commented 8 years ago

Hi, I created demo app that causes permanent RAM usage growth - https://github.com/kanoshin/cordova-sqlite-leak-reproduction. It makes a lot of select queries, but even if I do less queries - memory usage increases, but slower. My app has ~2k users on iOS and ~1k on Android, and I have no crash complaints on Android, but iOS app is very unstable. Both are heavily based on your plugin.

If I profile app with Instruments using Allocations template - heap size is not growing, but it grows in Activity Monitor and finally causes crash.

Have you got any clues about this issue?

brodycj commented 8 years ago

Unfortunately I still do not have any clue for you. When I run on simulator with iOS 8.4 the memory usage seems to bob (float) up and down. One thing about your test program is that since it generates sql batch requests much faster than the plugin can handle it will cause some increase of internal resource usage over time.

brodycj commented 8 years ago

I tried it on a 9.2 simulator and do not see anything different. In general the memory will simply float up and down over time. I do not see any evidence in the demos that this plugin has a leak that may cause a crash over time.