Insync slows down my quite fast machine almost to a halt (lags/freezes)

Hello,

the current version of Insync installed on my machine (3.8.7.50516-fc39, on opensuse Tumbleweed 20240114) is exhibiting some strange behavior.

First of all, it seems like it re-syncs the entire account on every startup. I haven’t noticed if this is the normal behavior also in previous versions, but it slows down my machine considerably (it’s an AMD 7840U with 32GB of RAM, not really the slowest thing on earth). It’s so bad while the sync is running, that the mouse cursor becomes laggy and even audio starts to stutter. I think/hope that your engineers will be able to reproduce this easily once they install a recent opensuse tumbleweed snapshot (KDE + Wayland) and then install insync + insync-dolphin and emblem-icons

And another thing I’ve noticed which baffled me, is that when I renamed a folder locally, it actually deleted it remotely, and recreated it with its new name, and re-uploaded all of its contents inside, which seemed crazy to me.

These are both two critical issues for me, that are making me consider looking for alternatives. The first one is my top gripe right now, the second one is ranked a bit lower.

Thanks

EDIT: you may wonder how I know it’s insync. The moment I kill the app the system instantly becomes snappy again, no mouse lag and no audio stutters. Please also notice that insync behaves itself once the initial sync is complete (the problem is that it runs one at each PC startup!). So if I can bear the sluggishness for a few minutes and let it complete that sync, computer performance is unaffected afterwards.

1 Like

Here’s a screenshot of top while I reproduce the issue:

Top offenders:

15904 root 20 0 0 0 0 D 41.20 0.000 0:09.76 kworker/u32:17+events_unbound
12597 root 20 0 0 0 0 I 21.59 0.000 0:10.94 kworker/u32:3-events_unbound
28888 root 20 0 0 0 0 R 18.60 0.000 0:07.66 kworker/u32:19+efi_rts_wq

I’m using btrfs on my root partition as well as on my (separate) encrypted home partition:

EDIT:

also reported on the forums of opensuse Tumbleweed:

How many files InSync is monitoring on that particular share/storage?

From my personal experience, btrfs has very high overhead on small files on single disk systems, so I’m not using it on any single/personal drive which requires high performance. LUKS also adds its own overhead to the filesystem operations, so it might be creating a perfect storm.

Maybe you can try writing many random small files with a small script (for + dd) comes into my mind, and see whether you can reproduce the spikes that way.

Thanks, I tried to run some dd like explained here:

https://www.baeldung.com/linux/disk-performance-test

And also a couple of random benchmarks in the “Disk” category provided by phoronix-test-suite, but I could not really reproduce any stuttering, so I must be doing something wrong.

I just reproduced this problem on a brand new Fedora 39 install.

Make sure you select an ext4 partition for /boot, and a Luks2 encrypted btrfs partition for / (plus obligatory /boot/EFI on FAT32).

Then install insync from yum (add the repo as explained on the insync website), and start a synchronisation with your Google Drive.

Some kworkers immediately show up in the output of the top command, and they are the most CPU consuming tasks.

If you start moving around the mouse cursor (e.g. draw “circles” non stop) you will notice the cursor lagging behind and jumping around.

This is on fedora 39 KDE, as it comes from the installer, no updates installed. It runs kernel 6.5.6.

Thanks for the update. Looks like LUKS2+BTRFS creates tons of overhead for small file operations. Can you try LUKS2+ext4, so we can be sure that what layer is creating the higher overhead?

This doesn’t mean InSync is perfect, but at least we can create some guidelines and know what to expect. Also, the information will help the devs to recreate and understand what’s happening.

I came here to suggest you trying stress-ng with --aiol 4 option, but recreating a problem on a different distro works as well.

Cheers,

H.

1 Like

Hey, thanks for your reply, I’ll try to run those tests in the upcoming days.

Cheers!

Well, there’s an interesting plot twist.

I have once again booted my “test distro” for the sake of testing a lil bit more.

It’s a clean Fedora 39 KDE install running kernel 6.5.6, I haven’t changed anything except for btrfs + LUKS2 when installing, as mentioned in my previous comment:

I haven’t run any system updates after installing.

In this very easy to reproduce environment, I was able to reproduce the issue immediately by using the latest version of Insync from the recommended Fedora repo (3.8.7).

However, since I’ve used btrfs + LUKS for months now, and this issue appeared only recently on my main distro, I tried a downgrade to a previous version.

And thanks to release announcements in the forums, I was able to pull the RPM for 3.8.6:
https://cdn.insynchq.com/builds/linux/insync-3.8.6.50504-fc39.x86_64.rpm

So I installed it, and guess what? It works just fine. Here’s a screenshot while running top, no weird kworkers eating up CPU cycles:

I started again a sync from scratch of my whole Google Drive (~8GB of data), and my PC doesn’t break a sweat, cursor is as snappy as ever.

Now I’ve booted back into my main/daily system (running opensuse Tumbleweed), and I’ll install that same previous Insync version just to confirm, and will report back.

Cheers!

UPDATE: Eureka! I can confirm that even on my main system running opensuse Tumbleweed (snapshot 20240119) the performance problem is gone by downgrading Insync to version https://cdn.insynchq.com/builds/linux/insync-3.8.6.50504-fc39.x86_64.rpm

I hope this gives you guys a good regression window to investigate. I saw the 3.8.7 changelog mentioning improvements to correctly compute the space used on LUKS encrypted devices, I wonder if the problem lies there.

Looking really forward for a fix. If I can be of any help, please let me know, I’m available next week, then will be AFK for almost a month.

Thanks

3 Likes

Thank you for the incredibly detailed exchange, @Andrea_Ippolito and @bayindirh!

I have forwarded this thread to our Linux team to investigate further. :slight_smile:

1 Like

Similar issue also using LUKS2+btrfs on arch since 3.8.7 in December. downgraded to 3.8.6.5054 and issues have been resolved.

2 Likes

Thanks for your feedback, glad to see I’m not alone and the issue is reproducible, hopefully this makes it easier to fix!

1 Like