High Memory usage

[kollokollo]

The app takes all the available memory on my (rather old) Android Phone after more than one year of usage, so that I could not install any additional app anymore. I have looked at the Settings-->Apps page on Android system to see that delta chat has "Data" of more than 110 MBytes. Becaue I always delete old chats and old messages in delta chat I could not imaging having so much stored messages to fill up 110 MByes. Also removing some of the messages did not help.

So I ended up in "stop app" and "delete data" for delta chat (curing the memory problem but making delta chat behave like it just has been newly installed. This created a problem of getting my key back to delta chat, which was already addressed as a bug in another issue.
See: Issue #279 )

Delta Chat version
v0.18.2

Expected behavior
Free internally used memory when messages are removed.

Actual behavior

I think all messages (even when removed) resides in Memory (in the database?) Maybe the database should be "compressed" or "vacuumed" from time to time. People with newer devices will hardly see this kind of problem, because they have tons of memory. I dont. (Android 4.01).

Steps to reproduce the problem

1. use delta chat (starting with early versions from July 2017, and successively upgrade)
2. remove some old messages, keep some others
3. Watch memory usage ("Data", not cache in the Android-->Settings-->App menu)
4. delete "data"
5. Have Problem Issue 279.

Screen snapshots
too late.

[r10s]

hi @kollokollo thank you for you post.
so, it's mainly about messages not deleted from the database? as in this issue: #22 ?

[kollokollo]

Well, it could be. I cannot really confirm this. All that I have seen is that delta chat used more and more (internal) memory on the phone. And I could not help it by deleting messages in the chat (leaving them on the server).

Unfortunaltely I cannot reproduce it at the moment, because my main issue is, how to get my keys back from thunderbird/enigmail (#279). Once this would have been done, the next issue is how to import all old messages from the mail sever again. I think the latter has also been addressed in one of the issues (#338).

[r10s]

with "memory" you mean "disk-memory" or "ram"?

[kollokollo]

It is disk memory, but "internal" not on "SD card". And the internal is limited to about 600MB for all apps together. (called "Interner Speicher" or on "App-Info" it is called "Daten") I think all app internal/private data are stored there.

[Ji-eF]

how to get my keys back from thunderbird/enigmail

You can get your keys back to DeltaChat if you have a copy of your PRIVATE key on Enigmail :

• From Thunderbird/Seamonkey Mail, go to Enigmail > Key Management
• Right-Click on a key you want to restore > "Export key to file"
• You now have a copy of your private key as an ASCII file, open it with a Text Editor
• Delete the PUBLIC KEY so ONLY the PRIVATE key section is on the file as in

-----BEGIN PGP PRIVATE KEY BLOCK-----

blablahhhh
blablahhhh
blablahhhh

-----END PGP PRIVATE KEY BLOCK-----

• Send this file to your Phone, in the "Download" folder, this is important
• From your phone, open DeltaChat > "Settings" > "Advanced" > "Manage keys" > "Import secret key"
• Done, DeltaChat should have your keys. Check at DeltaChat > "Settings" > "About Delta Chat" > Click on the little "Info" at the bottom. You should see the fingerprint of your key in this log.

[csb0730]

On my phone (Android 4.1.2) I see a memory consumption (App-Info->Daten) of 0.9GB. If I make an export of the database from settings I see a database file of around that size. So because the database resides in internal memory of the phone I assume that the database itself uses that memory.

From my experience with other databases (mySQL, MS SQL) I know that deleting of data sets is not enough to shrink the physically needed memory. There are some special maintenance functions to do that. For mysql there is a command called "optimize database".
Well, for now neither I know if such a function is necessary for sqlite (I suspect it is necessary!) nor if it is implemented yet. Maybe @r10s may answer this.

As a workaround You could try to export the database by settings and re-import it again. Depending on how the export function is implemented this should export only the used data sets and exported file should be shrinked to the real needs.

I think this issue is important to secure a durable and stable operation of the app!

[csb0730]

And yes, #22 is the user part of that issue and this issue #364 here refers to the technical needs to handle database properly :)

[kollokollo]

@Ji-eF : It didnot work. Is it of any importace to choose a specific password, when the key is exported from enigmail?

[kollokollo]

I think other mail clients have the same issue solved with a function "compress account". This can be triggered manually from the menu (in thunderbird e.g.) and additionally the app comes up with a message, if the internal memory usage is over a certain limit and sggests to compress.

For example the spam folder accumulates a lot of messages, as well as the trash folder. And even when they have been deleted manually, the file size of the database files stay the same until such a "compress" action is triggered. I have observed this with the thunderbird client on a linux system.

[Ji-eF]

@kollokollo see this comment, the key should not be passwd-protected :

#303 (comment)

Also, check the autocrypt setup messages in the Thunderbird enigmail settings for easy keys sharing.

[kollokollo]

If i set no password when exporting the key to a file in enigmail i get a warning and then only the public key is saved into that file. With autocrypt setup message the passphrase is 1234-1234-1234-... but doesn't work.

[csb0730]

Hi guy's, are You mixing a few things together here?
Isn't the main issue here why memory usage is high? This is not related to pgp key handling.

As far as I found by now there is really an issue about high memory usage.

For the database pragma's I see there is "Auto vacuum" set to "None", means that database vacuum is not done automatically.
In sources I can't find any "vacuum" statement so that I suspect that this is really not done.

Maybe @r10s can have a look at this issue?

[r10s]

no there is no vavuum yet, it wouldn't help until data really gets deleted, as mentioned, this is planned in a way, see #22

i think we can regard this issue as an duplicate, so maybe we should just close it and continue discussion about deletion and cleaning up disk-memory in #22.

[csb0730]

Agree 👍