SSD performance problems -- config problem or old drive?

[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]

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]

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]

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]

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