SSD performance problems -- config problem or old drive?

[chconnor]

Gotcha, thanks! I'll play around with this stuff and see if I can make any headway or gather any further clues.

[jlittle]

IIRC the brackets around "mq-deadline" mean it's the current setting. The other words show the possibilities. Back in the day the choices were something like "cfs deadline noop", and "cfs" caused problems by allowing an i/o bound device to dominate physical memory, not just i/o. I suggested "none" because the /sys file shows "none" as a choice.
IIUC, looking at info centre->memory and seeing if the disk cache has filled up physical memory would show if this might be an issue. The disk cache is supposed to fill up available memory but it's meant to give it up easily; it just doesn't give it up quickly enough for other i/o.

[chconnor]

If yours is the same, you could try echo none | sudo tee /sys/block/sdX/queue/scheduler, substituting X with the letter of the device the ntfs is on.

Thanks! -- did you mean "echo deadline" there? Mine are all "none" currently as well.

[jlittle]

I found some old threads on KFN and found:

The slowness may be a Linux I/O scheduler issue.
<discussion=possibly irrelevant>These problems have hit only some systems for a long time, but were sufficiently rare that the Linux devs seemed to deny the problems' existence for years, and there was an underground community of people patching their kernels to avoid it. When I struck a problem about 5 years ago it was just like you report, the desktop becoming unresponsive until I/O to the USB device completes several minutes later; some brain dead scheduling and caching would result in the rest of the system, including the pager (WTF?), being starved of I/O and physical memory. When SSDs became common the problems became mainstream and action was taken, but I'm not sure if the tweaks (f.ex. echo deadline | sudo tee /sys/block/sdX/queue/scheduler) are useful with USB sticks. My hardware with the problem died some years ago.</discussion>

Again, I'll be surprised if this is relevant. Looking at my /sys/block/*/queue/scheduler files on 20.10, they all show

[mq-deadline] none

If yours is the same, you could try echo none | sudo tee /sys/block/sdX/queue/scheduler, substituting X with the letter of the device the ntfs is on.

[chconnor]

Yeah that rings a bell. I'm running 20.10 but the hardware is from ~2012. It's not always laggy when copying is happening, but I definitely associate big copies to/from USB with system sluggishness. Not sure that exactly explains what I started this thread about, though, since it didn't really involve USB storage, at least not always. It's not happening frequently enough to really nail down, which is why I got excited about this gam_server lead, since it was the first identifiable thing I could point to as clearly causing sluggishness...

[jlittle]

... weakness where file I/O (or maybe just USB file I/O?) could cause overall system lag

That seems to be a reference to i/o starvation, which Linux on some hardware was prone to. My old Kubuntu system, in use from 2006 to 2016, was prone to it; if I did a large copy to or from a USB stick everything became very laggy, unusably so.
I'd be surprised if a 20.04 system was affected by it, but computers often surprise me. Changing the scheduler away from CFQ by echoing something to a system file could help; I'll try to dig out a reference to it.

Sent from my VFD 822 using Tapatalk

[chconnor]

Thanks -- I've had indeed had issues with swap in general (when I had less memory), and these days I do have a swap partition set up but it's usage is zero basically all the time unless I'm slamming the system. Doesn't seem related to these issues. (swappiness is at default 60 now...)

I've had Akonadi and Nepomuk disabled forever...

I do have a custom conky setup going... when this issues presents, it's mount.ntfs and gam_server that are causing the issue, at least when it was happening recently. It seems as if the "check for file modification" gamin server had to run through every file on the USB3 drive or something.

I heard once (quite possibly from one of y'all on this forum) that the linux kernel architecture had one arguable weakness where file I/O (or maybe just USB file I/O?) could cause overall system lag? Something about how that data had to get shuffled around that would cause things to get laggy... so I got to wondering if all the NTFS partitions I have mounted, combined with mediocre ntfs support in general, combined with a 6TB external drive connected over USB, might just be more than the OS can efficiently handle... but if I could disable gam_server without messing things up that would be a tempting thing to try.

[claydoh]

Thinking a little I wonder if something is causing extra disk i/o? I know some systems seem to like hitting the swap far too early, and that can cause drive related tasks to slow down a LOT, so maybe check swap usage in KSysGuard when you see the lags, as well as cpu usage. Swap usage can also show CPU spikes as the processor can be working overtime reading/writing things to swap which is far far slower than RAM. The swappiness can be adjusted if it is an issue.

[GreyGeek]

Do you have akonadi running?
On some systems it is the prime cause of desktop lagginess.
I disabled it on my system and use "locate" when I need to find stuff.

Also, you may want to run Ksysguard or htop (in a Konsole) to see what is eating your CPU cycles.

[chconnor]

So I haven't seen any speedup of the system since freeing up space on / and /home (now about 78% full on both)... I notice that gam_server (and possibly by extension mount.ntfs) is taking lots of CPU sometimes and that's associated with the lagging... gam_server I guess is part of gamin... any thoughts on its current utility? Most of what I find via googling is 15 year old posts... but I just connected an external USB3 drive with a ton of files on it and the system got super laggy for a long time. Mainly experienced through dolphin being super slow and saving of files, etc, being slow. I.e. file IO is lagging hard... makes me wonder if it's some combo of mediocre ntfs support with an overactive system service trying to index of watch files?

[GreyGeek]

I think what it was was described in e.g. this link which suggests that k/ubuntu installs the package apt-btrfs-snapshots by default: "This package creates a btrfs snapshot each time packages are installed or removed."

Mmmm... news to me!

Current versions of Ubuntu and Kubuntu install a package named apt-btrfs-snapshot by default. This package creates a btrfs snapshot each time packages are installed or removed. These snapshots can take up a lot of space if not cleaned up regularly.

The article was published Dec 8, 2020, so I suspect that "current versions" of Kubuntu means 20.10
I installed Kubuntu 20.04 back when the Alpha was released and apt-btrfs-snapshot wasn't installed during the install back then.
Snapper includes the ability to take "Pre" and "Post" snapshots surrounding the use of the apt command.

Curious, I installed apt-btrfs-snapshot and then used muon to add a couple of packages. Here is what I got:

[FONT=monospace][COLOR=#000000][FONT=monospace][COLOR=#000000]:[/COLOR][COLOR=#5454ff][B]~[/B][/COLOR][COLOR=#000000]$ sudo apt-btrfs-snapshot list [/COLOR]
Available snapshots: 
@apt-snapshot-2021-03-22_13:37:32[/FONT][/COLOR]
[/FONT]

Interesting! Now I am off to find out where that snapshot is located.

EDIT:
BONUS! After being initially stored in /tmp the snapshot ended up being stored exactly where I would store it, under <ROOT_FS>, along side @ and snapshots as a ro snapshot.
apt-btrfs-snapshot is a keeper!

[chconnor]

BTW, "apt" doesn't auto-snapshot by itself. It was related to something else you had installed. This is why I wrote my own snap/backup utility script.

I think what it was was described in e.g. this link which suggests that k/ubuntu installs the package apt-btrfs-snapshots by default: "This package creates a btrfs snapshot each time packages are installed or removed."

[GreyGeek]

IF you use locate to find thing, and Snapper, then you'll want to add "/.snapshots" and "/home/.snapshots" to PRUNEPATH in /etc/updatedb.conf

[oshunluvr]

BTW, "apt" doesn't auto-snapshot by itself. It was related to something else you had installed. This is why I wrote my own snap/backup utility script.

[oshunluvr]

I've only been "forced" to balance twice when I ran out of metadata space. It was an old problem that I think has been fixed or at least lessened to a great extent. A decent write-up here: https://askubuntu.com/questions/4640...ll-but-its-not

Other times I've used balance were related to moving data disk-to-disk or adding/removing devices from an array.