Zulip-desktop: Zulip-electron eats RAM
zulip/electron eats more than 7GB of RAM after 2 days of inactivity on windws 7 64bit
santherics
All 50 comments
@santherics that's weird, I've not seen similar behaviour. Can you tell us how much RAM you have on your computer?
kanishk98
on 1 Apr 2019
16Gb RAM
santherics
on 1 Apr 2019
@zulipbot add "investigate"
kanishk98
on 1 Apr 2019
Eats about 5.1% memory (400 MB / 8 GB) for me when the app is idle.
vsvipul
on 1 Apr 2019
Eats about 5.1% memory (400 MB / 8 GB) for me when the app is idle.
I don't think that says much about the issue. I just read some posts explaining that the app eventually might start hogging memory over time unless the OS puts a lot of pressure on Electron - which is why I asked for the amount of RAM on the OP's system. @santherics can you send us a screenshot of your system's task manager, sorted by memory usage in descending order (assuming Zulip is still taking up RAM)?
@akashnimare have you seen similar reports before? If not, it might be useful to write some methods to log memory usage over time.
kanishk98
on 1 Apr 2019
santherics
on 1 Apr 2019
@santherics, which version of Zulip are you on? There was such a bug about a year ago which was fixed, so it could also be due to Windows 7.
abhigyank
on 1 Apr 2019
santherics
on 2 Apr 2019
Hi Team!
We have the same issue. It is a real blocker since Zulip eats a huge amount of memory. Please help to fix it
KirillKhrushkov
on 2 Apr 2019
@KirillKhrushkov thanks for reaching out.
Do you also have a Windows 7 system like the OP does, and are you also running the same version of Zulip?
@abhigyank once we can reproduce this on our systems, would it be a good idea to periodically check for the process' memory usage and clear the web frame's cache once that usage exceeds a certain threshold?
kanishk98
on 2 Apr 2019
@kanishk98 yes, Windows 7 and the same app version
KirillKhrushkov
on 2 Apr 2019
Hi team!
Zulip app has memory leaks every day this week.
santherics
on 3 Apr 2019
Thanks. @santherics @KirillKhrushkov can you share your JS heap snapshots with us (both for the app (Ctrl + Shift + I to open DevTools) and the active tab (Ctrl + Shift + U))? I think that'll help us isolate a leak.
I'll also post this issue on czo and ask if there's anyone with a Windows 7 machine who can reproduce this problem.
kanishk98
on 3 Apr 2019
@zulipbot claim
kanishk98
on 3 Apr 2019
@kanishk98 Should it be a snapshot made at the time of a large memory leak or at any time? The snapshot contains confidential information. How to remove confidential information from snapshot?
santherics
on 3 Apr 2019
Given past experience, this is very likely an upstream Chromium/Electron issue; should we try posting a beta built off a newer electron to see if that resolves the issue?
timabbott
on 4 Apr 2019
I'm running Zulip client v2.3.82 on Windows 10 and I've experienced this issue twice the latest week. Today, Zulip had consumed 10GB of RAM before I killed it.
JEderonn
on 8 Apr 2019
@kanishk98 Do you still need the heap dumps? If yes, please tell me, how can I remove confidential information from the dumps.
santherics
on 8 Apr 2019
Do you still need the heap dumps? If yes, please tell me, how can I remove confidential information from the dumps.
I've asked Akash about this issue, he said he'll be handling release of a beta to see if this issue persists.
I'll start logging memory usage of Zulip on my machine and see if I can isolate this to a specific reason.
(Sorry for the delayed response, been busy with my GSoC proposal)
kanishk98
on 8 Apr 2019
Can we get this beta for testing in our environment?
santherics
on 9 Apr 2019
Can we get this beta for testing in our environment?
@akashnimare should be able to answer that better. Sorry to see you facing this issue!
kanishk98
on 10 Apr 2019
@akashnimare Can we get this beta for testing in our environment?
santherics
on 10 Apr 2019
Some users reported the same issue with Firefox 65.0.1(64bit) on Ubuntu 14.04 and Zulip application on Ubuntu 16.04
santherics
on 10 Apr 2019
@santherics if folks are seeing this in browsers, I'm curious if there's something unusual in the usage pattern that's causing the app to use a lot of memory -- for the users who are affected, do they have some very old unread messages? E.g. if you click on "All messages" in the left sidebar, how far back in time are those messages?
timabbott
on 11 Apr 2019
@timabbott in my case there were no unread messages. But if I click "All messages" then I'm far back in time
KirillKhrushkov
on 11 Apr 2019
There is some specific pattern on my side:
We have many users pushed to Zulip user list who has never logged in to Zulip.
And all of them are added to common Stream where communication goes very actively.
Can it be the reason that those "offline" users get digests and that leads to memory leaks for other users?
KirillKhrushkov
on 11 Apr 2019
We also get user avatars from LDAP automatically
KirillKhrushkov
on 11 Apr 2019
Offline users should have no material impact on memory usage. @KirillKhrushkov can you try hitting the Home key when you're in that "All messages" view with no unread messages, and then reload the browser? There's some legacy logic in Zulip that controls how much message history gets pulled down into the browser's memory that expects folks to advance the pointer in "All messages" occasionally. I'll bump the priority of replacing that legacy code if this fixes your memory usage issue.
timabbott
on 11 Apr 2019
@timabbott This doesn't help unofrtunately..
The memory rises very quickly. At 7 pm it was around 500mb and at 10am it is about 10Gb already.
Memory is back to normal values after "Ctrl + R" in application.
KirillKhrushkov
on 12 Apr 2019
Memory is back to normal values after "Ctrl + R" in application.
This helps - I'm guessing this is either the webFrame or the session (at least for the desktop app) that's causing memory usage to balloon up.
While the next release of the desktop app should address this issue, I think this is a major problem.
Until that happens, @KirillKhrushkov, I can write a fix to clear cache in a branch on my fork and you can use that to see if the problem persists. (that'll really help us debug this issue, because none of us can repro it locally as far as I know).
If you're okay with that, I'll help you through the setup process.
kanishk98
on 14 Apr 2019
OK, that's interesting. This feels like a browser bug. The next thing to try is I think testing a beta off a newer Electron.
timabbott
on 14 Apr 2019
@kanishk98 yes, please share it with me.
Thank you
KirillKhrushkov
on 15 Apr 2019
@timabbott could you please say when you are planning to deploy a release with Electron?
KirillKhrushkov
on 15 Apr 2019
@kanishk98 yes, please share it with me.
Sure, I'll do that in the evening once my classes get over. :)
In the meantime, please join our community discussion server so I can discuss your personal logs with you over there in PMs and keep this thread clean.
kanishk98
on 15 Apr 2019
@kanishk98 thank you a lot!
Sure, my email in Zulip chat is [email protected]
KirillKhrushkov
on 15 Apr 2019
@kanishk98 any updates on this?
vsvipul
on 17 Apr 2019
Yeah, I've been in touch with Kirill regarding my implementation here. This is basically a hit-and-miss approach to what works with them. Depending on what we decide fixes the issue, I'll start a discussion on czo about how to include that in the app.
kanishk98
on 18 Apr 2019
Hello @kanishk98, you have been unassigned from this issue because you have not updated this issue or any referenced pull requests for over 14 days.
You can reclaim this issue or claim any other issue by commenting @zulipbot claim on that issue.
Thanks for your contributions, and hope to see you again soon!
zulipbot
on 28 Apr 2019
Working on this issue. Sent over a non-signed .exe file to @KirillKhrushkov and waiting for their review. Some time was wasted in trying to get them to build the app on their system, but I spoke to Akash about distributing the exe file and uploaded it once I got the green light for that.
kanishk98
on 28 Apr 2019
akashnimare
on 30 Apr 2019
@akashnimare This might be fixed by merging PR #732 , and then the OP can test if there is high usage even after turning off error reporting or not. Worth a try, i say. @santherics If you have the dev build setup, can you please try PR #732 and then turn of error reporting in the settings and see if that reduces RAM usage for you ?
vsvipul
on 2 May 2019
Hello team!
We have localized the problem. Memory leak happens during synchronization of user profiles via Active Directory.
Do you have any ideas on how to fix it?
KirillKhrushkov
on 15 May 2019
@KirillKhrushkov thanks for the investigation! That's super interesting and very helpful. I bet there's something subtle happening along the lines of "when user profiles are synchronized, something makes the browser download every user's avatar" (where the root bug would be that we're not checking if the avatar hasn't changed, or something like that).
Can you try running that synchronization step with a JavaScript console open to the "Network" tab and see what happens there? Of interest is what types of GET /events responses some back as well as if any resources like images are downloaded.
timabbott
on 17 May 2019
@timabbott I don't see image downloads in Console during User Profiles sync.
Here is a screen:
KirillKhrushkov
on 22 May 2019
Awesome, thanks for the confirmation! Given that it may not be actually re-downloading the images, this may not be the root cause for your issue, but it's certainly possible that it is. Certainly it confirms there's a major wasted resources bug here: https://github.com/zulip/zulip/issues/12381. I'll try to get it fixed in a 2.0.4 release soon so that we can confirm whether that's the root cause of your issue.
@santherics are you folks also using our LDAP integration to sync user avatars?
timabbott
on 22 May 2019
Yes, we are
santherics
on 14 Jun 2019
Great, thanks for the confirmation. I expect we'll have a fix to #12381 soon, which seems likely to be the root cause of this issue.
timabbott
on 20 Jun 2019
I just merged the fix to #12381. Because it involves a database migration, this won't be a commit that is convenient to cherry-pick, so we won't be able to include it in a 2.0.x release.
I expect we'll post a 2.1.0-beta1 next week; if you'd like you can wait for that, but I'm also happy to support either of you folks upgrading to master to verify the fix works for you. (/home/zulip/deployments/current/scripts/upgrade-zulip-from-git master should be all you need to do).
I think it'd be reasonable to close this issue as likely fixed, but I'll leave it open for now pending confirmation that this indeed resolves the problem.
timabbott
on 3 Jul 2019
@akashnimare Hadn't a report on this since a long time, can we close this?
abhigyank
on 2 Jun 2020
Yes, we fixed an issue that was confirmed to cause this, and haven't had new reports since that fix was released.
timabbott
on 2 Jun 2020
Related issues
abhigyank
路
10Comments
swallitsch
路
7Comments
brainwane
路
9Comments
Mentalone
路
10Comments
YJDave
路
6Comments
Most helpful comment
I just merged the fix to #12381. Because it involves a database migration, this won't be a commit that is convenient to cherry-pick, so we won't be able to include it in a 2.0.x release.
I expect we'll post a 2.1.0-beta1 next week; if you'd like you can wait for that, but I'm also happy to support either of you folks upgrading to master to verify the fix works for you. (
/home/zulip/deployments/current/scripts/upgrade-zulip-from-git mastershould be all you need to do).I think it'd be reasonable to close this issue as likely fixed, but I'll leave it open for now pending confirmation that this indeed resolves the problem.