Hi all,
Please send your logs to support@insynchq.com with the link to this post. We are looking into high CPU usage and would love to put this issue to rest as soon as possible!
Having a similar issue 3.1.7.40811 on Mac OS 10.15.4. If I move away from the feed view, the CPU settles right down.
Same here. I am running Linux Mint 19.3, and Insync sometimes uses 100% CPU, which prompts me to restart it, bringing it down to around 20% (still not the best). Maybe giving us an option to disable the feed could be a good temporary solution?
Note: I do code directly on the Drive folder, and the higher number of files generated and edited (e.g. cache files) while coding may be a factor in such a high CPU usage.
Edit: I’ve tried turning off the feed by deselecting the ‘account’ section of the Feed view. This did not solve the problem (CPU usage still ramps up to 100% from time to time), so either the problem is not related to the Feed view, or Feed keeps updating regardless of the view option.
This is still an issue. Today I found CPU usage at 125% on an i7-10875H, even while all files are synced. Can you please move this to top priority? Otherwise, we may need to look for alternatives for https://kfocus.org.
1 Like
Hi @Mike_Mikowski,
Could you let me know if you were doing a large sync when the CPU hit 125%? Please also send your log files to support@insynchq.com (if you haven’t), and include a link to this post.
Hi Miamoran:
Sorry I didn’t seen this until today. I just ran into this again today - 125% CPU usage with the fan spinning up. The syncing also appeared stalled.
I killed the process and restarted it. CPU usage dropped to 0-4% and completed syncing in less than a minute.
I will send you an email with a link to this ticket. It would be good if we could attached to a bug ticket directly.
1 Like
Hi Miamoran:
This happened again today.
The fans spun up and two PIDs were running. Here is a snapshot of the interface. This view did not get resolved even after 5 minutes of waiting.
There is no large sync to my knowledge - certainly nothing I had changed. In fact, I was away from the computer when this started (but in the same room). The numbers kept increasing.
Google Chrome was running at the same time with 16 tabs open. Also a terminal app (Konsole) and Dropbox. The DE is KDE on Kubuntu 20.04. No other user apps were in use. This all occurred on AC power.
Here are all the Insync processes that were running. I killed the third process (3120) which resulted in the interface going blank and all but the 2929 process remaining. CPU usage remained pegged at 125%. I finally killed this process to resolve the issue.
ps -elf |grep insync
5 S mmikows+ 2929 1 30 80 0 - 1995691 futex_ 13:46 ? 01:42:33 /usr/lib/insync/insync start
4 S mmikows+ 3101 2929 0 80 0 - 60214 do_wai 13:46 ? 00:00:00 /usr/lib/insync/PySide2/Qt/libexec/QtWebEngineProcess --type=zygote --webengine-schemes=qrc:sLV --lang=en-US
5 S mmikows+ 3120 3101 0 80 0 - 60214 poll_s 13:46 ? 00:00:00 /usr/lib/insync/PySide2/Qt/libexec/QtWebEngineProcess --type=zygote --webengine-schemes=qrc:sLV --lang=en-US
1 S mmikows+ 3174 3120 0 80 0 - 567739 futex_ 13:46 ? 00:00:03 /usr/lib/insync/PySide2/Qt/libexec/QtWebEngineProcess --type=renderer --disable-gpu-memory-buffer-video-frames --enable-threaded-compositing --enable-features=AllowContentInitiatedDataUrlNavigations --disable-features=MojoVideoCapture,SurfaceSynchronization,UseModernMediaControls,UseVideoCaptureApiForDevToolsSnapshots --disable-gpu-compositing --service-pipe-token=3442027218125797757 --lang=en-US --webengine-schemes=qrc:sLV --num-raster-threads=4 --enable-main-frame-before-activation --service-request-channel-token=3442027218125797757 --renderer-client-id=2 --shared-files
You can see there were no errors. After restart the drive did sync for about 30s and then usage dropped down to 1.3%.
1 Like
I greatly appreciate you sharing all the details here, @Mike_Mikowski! I have also responded to your email requesting for the latest log files. Let me know if you didn’t receive it!
Hi Miamoran:
The issue recurred today. See attached image - two threads are near 100% usage. The destination file system is standard ext4 over standard LUKS full disk encryption.
Sincerely, Mike
ps. I sent you log files the last time, and will follow up on the same thread.
1 Like
This issue appears correlated to the use of custom folder names. I have not heard reports of this issue with default names. I’m suspicious because developers rarely create comprehensive tests for this type of setting. Perhaps I can switch back to default folder names and see if the issue recurs. Is there a simple way to do this?
1 Like
Hi @Mike_Mikowski,
Thank you for that observation. I sent the clarification via email and for those who might stumble upon this thread, I am currently confirming with Mike if he plans to change the location (or recreate) to the default path Insync suggests during onboarding. This is usually ~/Insync/your email/Google Drive (or OneDrive), ~/Shared with me, and ~/Shared Drives (or Sharepoint).
Hi,
Unfortunately, I have the same problem. I reported this in another thread (New Insync version: 3.2.6). Since then, I have to stop Insync since it keeps CPU at 100% and fans running all the time. I have also different default folder names, in case this is related in any way.
Best
So sorry for this! Could you let me know if you’re still on 3.2.6, or have you upgraded to 3.3.4? Also, are you running any other programs and making a lot of offline changes that need to be synced when you run Insync?
Hi,
Sorry, I did not see the message. I am using 3.3.4.40916.
I have seen some progress. Now the problem is that every time I restart the computer, Insync resyncs from scratch. Once it has finished resyncing, the fans stop, and the temperature decreases.
Hope this helps,
Carlos A.
@Carlos_A_Iglesias Hi! When you said it resyncs from scratch, does it say “Scanning” or “Syncing” at the bottom right?
Thanks, I mean scanning. It rescans all the files, it doesn’t matter if they have not been changed.
@Carlos_A_Iglesias Insync scans your entire drive on each boot, to make sure nothing is missed (especially when large changes are made offline). Are you experiencing a long scan time at each boot?
On a laptop it’s sooooo bad. Incredible you sell this software successfully. Guess it’s the lack of alternatives…
It get’s super hot and slow and loud and you battery will die soon!
I don’t have any hope you guys fix this. I mean its been a problem for such a long time now and nothing changed to the better. If you have a look at the change logs you see it’s mainly bug fixes. We really need an alternative.
The only thing I found to make things just a little better is to use cpulimit.
Install cpulimit and then launch insync with:
cpulimit -e insync -l 10
Now it will use less cpu and your laptop does not get as hot and loud anymore.
I like you guys. You’ve been always nice and kind, but unfortunately this fixes no software problems.
1 Like
Thank you for your feedback and my apologies for the experience, @Randalix.
Could you please send your logs.db and out.txt files (guide here) to support@insynchq.com so we can take a look? Are you doing a large sync by any chance?
This problem, reported back in December 2018, is still a problem in September 2021. The longer InSync runs, the more and more slower the computer gets, until a point it’s unusable, so you have to slowly crawl to the Activity Monitor and kill InSync for good to get back the computer to an usable state. The high resource usage happens in both Mac and Windows, but it’s even worse in the Mac version.
How can your product be so unoptimized after all these years? And you sell it as professional product, but this is not ready for use in a professional environment (or even a home environment), because it slows the computer to a crawl!
How come you can’t fix this problem in the 3 years since this was reported?!