Out of memory: memory leakage?

Still broke? I got a refund on v3 in Sep 2019 because it was utter pre-alpha level rushed-out garbage, although I was fond of Insync previously and would still like to see a decent release. Just checking in to see if things have improved, a memory leak of the proportion noticed though is simply not acceptable, so I guess not, such a shame.

Me too, I am surprised and curious what would happen. I am still running 1.5.7 because it seems from reports here that the 3.x is still on alpha. However Insync support seems to pretend nothing happens, I just don’t understand because they were soooo good in support.

@mia, can you comment what is happening with the 3.x version and whether you will keep 1.5.7 for new releases (say Ubuntu) until a decent new version is obtained?

Same issue here. More than 7gb of ram occupied by Insync, this happen after uploading large files and running in background for a few hours. Linux Mint 20 | Insync 3.2.1.40839
Restarting works.

2 Likes

Hi guys,

We take full responsibility that there have been major bugs in Insync 3 during and post-alpha which caused problems for our existing users. We’re working to resolve those issues asap so we can release a fix asap. I’ll follow up the memory leak issue with our team so we can finally put this to rest. :slight_smile:

We’re also allocating our resources to the fixes included in upcoming builds and no longer maintaining the 1.5.7 version.

1 Like

At least 3 times a week, I open activity monitor and kill the Insync process, then restart it. This frees up the many GB memory used, and restarts the sync process. I’ve been doing this for >6 months now.

Update, I had a look today & insync was using 17GB of memory…!

Thanks @mia for replying.

As you recognize, Insync 3 has been a struggle. This things can happen, bad luck, I understand. Mistakes and this things can happen, so be it.

What I don’t understand at all is the strategy to deal with that problem, once it happened. You have a version that works very very well and that has made so many very happy. If the new version happened to not be at the standard level, why not to just keep 1.5.7 version running, with no added feature or improvements, granted, until the new version is fixed in full?

Again, I am not asking to improve 1.5.7 and to add features it. NO. Just to keep it running in systems. It is a last resource safety net: keep the stable version while you fix the other, so that at least there is one robust version available.

It seems the strategy, however, is to push users to the buggy version regardless, and hence use them as testers, and ask them to “deal with it”. That is indeed real poor handling of problems I am afraid, and it does not provide evidence of “taking responsibility”, but instead of shifting it to the users. It has to be more than just saying it. Allocation of resources, when this happens, is not good excuse because reasonable allocation has to go to deal with the problem, I think.

Resources are limited, I understand. I also understand Insync really wants to get their new version up and running. BUT, when bad things happen, keeping the bare minimum is fundamental and top priority.

Anyway, since this has been going for more than 1 year I don’t expect it to change. It is a real pity, but I guess the problem is much more than a technical one. Ohh well… :frowning:

1 Like


On macOS Catalina 10.15.6 (19G73) → uptime 2d…
Seriouly, more than Chrome !? ◉_◉

2.11GB! wow, not nice…

v3.2.3 is memory hungry!!!

1 Like

Given the lack of response from InSync, I’m guessing they just don’t care!!!

1 Like

Hi @ssardina,

Apologies for taking a while to respond to this, and thank you for sharing your sentiments. I appreciate users like you!

I have shared this feedback to my team so we can revisit the way we strategize and implement fixes on upcoming builds, as well as how to better prioritize the bigger issues moving forward.

Gave up and got a solution working with rclone now - not realtime but sufficient - I think the original devs of insync have moved on as now the team implement little fixes here and there, shielded by customer awesome agents lol, without addressing the elephant in the room for nearly a year - Same that happened to EverNote…

Still no fix?, A memory leak indicates a coding issue which is probably causing other issues. This should not be difficult to locate!

You may be right Matt, it’s possible that the devs have moved on from this project, and hence they can only reply to the forum politely but with promises that never eventuate; they may have just lost the capacity to do the actual development. :frowning: I stop recommending it to others as I used to do it before…

@Matt_Freeman, is your rclone solution 2-ways (even if online) and complete (ie., does it deal with the new share link types?)

This is still a thing - after almost 10 months since the OP and several releases in between.

Trying to find out when my iMac (32GB ram) was running like water up-hill discovered Insync was consuming over 800GB (yes, you read that right) of virtual memory. It had been running a few weeks uninterrupted. Restarting it recovered system performance immediately, but then lost the next hour+ scanning instead of syncing. Seems like I need to restart it regularly to keep it in check. This is ridiculous for software that needs to run for long stretches of time. Definitely a memory leak.

I restarted Insync just 3 days ago and it’s already up to 65GB according to Activity Monitor.

I am seeing this problem on both:

  • macOS Mojave 10.14.6 - iMac 2014 32GB RAM
  • macOS Catalina 10.15.7 - Macbook Pro 2019 32GB RAM

Both are running Insync 3.2.8.40877.

Both sync the same 2 google + 1 OneDrive accounts.

By way of contrast, Dropbox is using 750MB/517RAM on these systems and is 100% stable in terms of memory use (although CPU use is a completely different story).

After just 3 days… Insync is always top of the memory hogs within hours of (re)starting.

I’m very close to giving up on it, and need some convincing response in order to justify persevering with it.

Hi @deeprave,

Memory leak is one of the issues our engineer is prioritizing since it really has been affecting our users’ workflows when it first appeared. Apologies for not being able to deploy a fix sooner!

Could you send your latest logs.db and out.txt to support@insynchq.com with the link to this post?

Hi,
Same problem here. On Mac Big Sur, I get almost 18gb of ram usage just after a few hour of work forcing me to reboot the computer.
@mia : Do you have an estimated date for the release please? It’s becoming to be really annoying.
Thanks in advance.

Thank you for reaching out, @Stef500! Could you send your logs.db and out.txt to support@insynchq.com so we can check it out further?

There is no ETA yet, but this is one of the top priorities that our engineers are working on. Thank you for your patience-- I really can only imagine how frustrating it has been!

Hi,
Does version 3.3.1 (or 3.3.2) fix this problem? Thank you.