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

Bugs and issues Linux
#1

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
#2

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

image
image1525×1000 420 KB

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:

image
image1525×1000 147 KB

EDIT:

also reported on the forums of opensuse Tumbleweed:

#3

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.

#4

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.

#5

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.

#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
#7

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

Cheers!

#8

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:

insync-insync-3.8.6.50504-fc39.x86_64-ok-Screenshot_20240121_162343
insync-insync-3.8.6.50504-fc39.x86_64-ok-Screenshot_20240121_1623431562×1110 341 KB

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
#9

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
#10

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
#11

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
#12

Hello again @mia ,

are there any updates on this, by any chance?

I’m not looking for a fix ETA, but even just receiving confirmation that the dev team acknowledged this issue and will work/is working on a fix would be reassuring.

Because as it stands, I will have to stay on an older release until this is fixed, and I dread the thought of this issue being left behind while the app moves forward with other fixes and features that I won’t be able to profit from.

Thanks a lot in advance and have a great day! :slight_smile:

1 Like
#13

@Andrea_Ippolito Thank you so much for following up on this, and my apologies for the silence!

I have followed up with our engineers to look at the relation between Insync and LUKS2+btrfs, as well as what changed from 3.8.6 to 3.8.7 that might’ve caused an interference in the sync processes. I’ll update this thread as soon as I know more. :slight_smile:

1 Like
#14

Hi @Andrea_Ippolito

Can you try out this build if it fixes the issue for you?
https://cdn.insynchq.com/test/insync-3.8.7.50540-fc39.x86_64.rpm

#15

Hi @Kurt_Ko,

thanks for sharing the build. Unfortunately the laggy mouse pointer experience is still there :frowning:

Here’s a screenshot from top a few seconds after starting insync with that build installed:

image
image1758×1289 679 KB

I’ll revert to insync-3.8.6.50504-fc39.x86_64 which was working smoothly.

Please let me know if there’s anything I can do to help further.

Thanks

EDIT: by comparison, this is what top looks like a few seconds after starting the downgraded/ok version of insync mentioned above:

image
image1758×1289 674 KB

#16

Hi @Andrea_Ippolito

I see, does this build have an improvement for you?
https://cdn.insynchq.com/test/insync-3.8.7.50550-fc39.x86_64.rpm

#17

Hi @Kurt_Ko,

unfortunately my cursor still lags under the load produced by all the kworkers, also with this build.

image
image1611×1078 496 KB

It seems to last less than a minute once the app has started, but IMO that’s reason enough to consider it a regression.

Instead with build 3.8.6.50504-fc39.x86_64 those kworkers are nowhere to be seen, ever, and the mouse never feels sluggish.

I also don’t know if the sluggishness could come back after the initial ~1’, for example at regular intervals or whenever a file change is detected. That’s why I will revert to 3.8.6 once more, which never shows this behavior.

I’m not sure I’m of much help, by all means let me know if there are any logs I can collect for you or commands to execute, because a screenshot can only tell so much.

Thanks for your continued efforts on this :slight_smile:

FYI, I have tested this on opensuse Tumbleweed running kernel 6.7.7-1-default, as this is my main distro.
I have a fedora 40 installed on another partition but the results of my tests with previous builds were comparable between the two OSs, so I stopped testing on fedora (also because it’s more time consuming as I need to reboot my machine).

1 Like
#18

Hi @Andrea_Ippolito :slight_smile: Thanks for your patience and for testing out the build that @Kurt_Ko shared. I’ve notified him of the persistent issue. We’ll get back to you asap!

1 Like
#19

I have the exact same symptoms on KDE Neon (based on Ubuntu 22.04) and I’m not using BTRFS nor LUKS. My Insync folder is on a NTFS partition.

Downgrading to 3.8.6.50504 solves the issue.

1 Like
#20

Hello @mia,

are there any updates on this issue?

Thanks :slight_smile: