It is quite amazing that this is still going on. I’ve had to force quit InSync in the last week because of it. What is more amazing is how I am still keen to support the product. But maybe reading this forum is reminding me that its time to look for another option?
2 Likes
Hello, perhaps that is one possible issue - when you notice it could you for now just quit Insync and force-quit the isdaemon process as well before restarting Insync? Thank you and we’re sorry for all the trouble.
1 Like
Hello everyone, we really apologize for this long-standing issue. We have not yet been able to replicate it ourselves, even on an M1 Mac, which is why we’ve been fixing other replicable issues first.
We will however be resuming investigations into this issue by next month, and hope to release at least some improvements within a few months.
Thank you all for your patience.
1 Like
Hi jukwaphil,
If you find a reasonable alternative I’d be interested as well.
Google sync and backup has been cobbled and is not functional if it is being used to sync files on more than 1 computer.
Can you describe your test environment? How much data is stored in your test enviornment? What type of files are you storing in your test environment? What is your available network bandwidth? How long does it take you to download / upload a complete copy of your data store? Which cloud service providers are you testing?
In other words, does your test environment represent the typical environment of your user?
@o9p0 For this issue, yes, we’re using a typical M1 MBP, connected to a residential line (~50Mbps). The test files are a mix of documents, small and large files, typically taking a few hours or overnight to fully download/upload.
So yes, we try to represent the typical user environment, and are now looking into stressing the client further and more systematically to expose the leak. Thank you.
Maybe look at file quantity. Microsoft states limits of 100K and 300K, depending on the support document, yet for whatever reason, it doesn’t seem to do a good job of governing this. I have a OneDrive library that I know has well over 500K files, which I have no good ideas how I managed to upload over the years. I may have done that using an early version of InSync, or by using a computer that had massive resources and an older version of the native OneDrive client that just happened to work with those resources.
In any case, now I have trouble using any client on any machine working with this OneDrive library.
Side note: the InSync client has never been fast, responsive, or very usable for me. And always seemed to be a resource hog even before I was using OneDrive.
Hi @jimperio. I’ve posted on this issue here before, but I just wanted to provide some more info incase it might be of some help. When I first encountered the problem (see here), I was using a Mid 2014 MacBook Pro and a 2020 Mac mini M1. Both machines suffered from the memory leak. I have recently switched my laptop to a 2020 MacBook Air M1 and I transferred my data from my old MacBook Pro. Sure enough, the problem persists on my MacBook Air.
I just wanted to provide this information in case it might help solve the problem in any way and ask if there’s anything else I might be able to provide in terms of logs or other data that could be of use.
1 Like
Thank you for sending this information, @cdixon1. Let me forward this to our team and will definitely reach out in case we need more details. 
Hey @mia, I think I may have some more info on this. I’ve been quitting and reopening Insync as usual but today I think I noticed a pattern with the memory usage increases. It seems that every time my Time Machine backup runs (I have it backing up to a network disk attached via NFS—not sure if this detail matters) the memory usage seems to spike a little bit. As Time Machine performs a backup every hour, this could contribute to a large amount of memory being used over time. I have no concrete proof the two events are linked, but it may be worth looking into since it’s now been over two full years since the issue was first reported in this thread.
Hi @cdixon1 – thanks so much for sending this observation our way. Do you mind emailing your latest logs.db and out.txt files to support@insynchq.com? We’ll check it out as well and see if the two events are linked somehow.
@mia, yep I’ll do that now. I did a little test and disabled my Time Machine updates on my other computer for awhile and sure enough Insync’s memory usage did not get out of control. Not concrete proof still but interesting nonetheless. Interestingly on my main computer I noticed that Insync had quit itself at some point (I suspect due to the ballooning memory usage).
1 Like
I’m having the same memory leak issue as many other users. Sent log files, txt file, and settings to support@insynchq. I am running Insync on an MB Pro with M1 Max. I have about 50 GB of files that are being synced. Over 5000 files. A few really big files, one is over 10 GB and another is 9 GB and a third is over 5 GB. Those don’t change very often, but just giving you some background.
1 Like
Hi Andy,
We have received your logs, thank you so much for sending them our way! Just curious - do you also have Time Machine running on your MB Pro with M1 Max?
Yes, I am running Time Machine. However, I excluded the drive from backups. And it was leaking prior to Time Machine actively backing up, as I didn’t have a drive to back up to for some time (about a week ago I got the new drive for backups.) Time Machine was turned on for the last couple of years.
Hey guys! Our engineer has successfully replicated the memory leak issue with Time Machine and deployed an improvement (huge thanks to @cdixon1 again!!)
Could you guys please manually update to 3.7.3 first, and then please let me know if you observe the memory leak persisting?
1 Like
Please. This is eating my SSD in the long-term. Insync is almost unusable on machine that is on 24/7.
Be aware that I do have around 20TB in my GDrive.
But Insync is only used for syncing around 100GB of data.
The rest ist excluded via the gitignore rules from within the base directory.
@mia Thanks for keeping us updated! Unfortunately it still seems like the issue exists. I installed 3.7.3 around 10:00PM EST last night and memory usage was around 250MB. I just checked my Mac mini M1 now at 10:00AM EST and memory usage is currently at 3.75GB. I will keep it running for another day or so to see if it continues to increase.
Edit #1: Now, at 10:26AM EST after one Time Machine backup cycle, the memory usage has increased to 3.87GB 
Edit #2: 11:38AM EST, 3.98GB
Edit #3: 12:40PM EST, 4.10GB
Edit #4: 1:15PM EST, 4.10GB (right before TM cycle)
Edit #5: 1:34PM EST, 4.21GB (right after TM cycle)
Edit #6: 2:45PM EST, 4.32GB
Interestingly the increase was 0.11-0.12GB each time. So over a day 2.88GB, and over a week 20.16GB. Seems like there’s still work to be done!
1 Like
My apologies for the persistent issue, especially after I sent a build that supposed had the improvement
Could you please send your latest logs.db and out.txt to support@insynchq.com so we can check it out?