Return to Level1Techs.com

Terminal is laggy?

My system has been extremely laggy when doing anything via the terminal, or file browser even just SSH in via my LAN and cd’ing around is slow. Running most programs like a web browser though seem to be fine. Loading up all the cores is fine. I haven’t added or removed packages, nor installed any updates.

The only thing I did today was transfer files to and from an external ssd. I just moved the ssd to a new usb-enclosure, the old one fell apart. The new usb enclosure seemed to be functioning fine. However while transferring ~200GB to the external ssd, the transfer slowed to <1MB/s and the system basically froze for 30 seconds. Tried to delete the partially transferred files, system froze for 30 seconds. Tried to cancel the delete operation. Froze. Left it alone for an hour, some nautilus process was still going. Super laggy. Couldn’t stop the drive, couldnt unmount, nothing worked. I had to eventually just yank the ssd out of the usb port. I since transferred the files completely, and it went reasonably fast. However, file browser and terminal haven’t performed smoothly since. Perhaps just a coincidence?

Tried rebooting. Tried apt-get update. Not sure why the terminal would be laggy. Slow cursor, typing is horrible.

Could I have somehow made Nautilus angry? Not sure how that would affect the terminal though

edit: Some specifics,

Running ubuntu 18.04.4, ryzen 9, latest bios, everything has been stable for weeks.

I was transferring data from a nvme data drive (not my OS drive) to a sata-usb ssd enclosure formatted in exFAT

Check dmesg (sudo dmesg) and see if you’re getting any kind of disk I/O errors.

Loading local apps would generally hit RAM, so disk issues won’t affect their speed, but I/O errors would effect everything else you’re describing.

Things like bash-completion access your disks in order to present you with filenames and commands when you hit tab, so it does a surprising amount of drive access for doing “not much”.

2 Likes

iostat -x and atop will have some typical statistics on how long it takes to do reads/writes on all your devices. (You may have to apt install whatever package they’re in on Ubuntu these days)

don’t see anything in particular that stands out. System is running all nvme ssd’s, not dealing with massively complex directories, so it should be plenty snappy, and it has been. Not sure why it feels so sluggish since this morning when my external ssd seemingly shat itself.

Its just strange even key presses are lagging when typing in the terminal now, or sometimes i’m getting 50 letters when I only type one.

i’ll check it out. I think I’ve used iotop, I assume they’re all the same

I’m getting wild R/W performance on my sata drives. My NVME drives are fine. Sata ssd’s are all over the place. (the external is a sata ssd too). getting sequential writes of ~30MB/s where previous it’d be around 300-400MB/s. Very strange. Also when I go to ‘safely remove’ the external usb ssd I’m now getting an error “Unable to Stop Drive: No object for D-Bus interface”

Is it possible my system is behaving strange because my external ssd is the exact same drive, didn’t reformat, but I just changed to a new usb enclosure with a different internal controller. This enclosure is a j-micron, the old one was as-media (maybe?).

A bad bug in any of the drivers (even for usb hdds) could make your system crawl like that.

What’s your average io duration on that usb drive? (Should be less than 1ms as it’s an SSD) . Long read/write durations could indicate something is hinky with the enclosure, which means something is definitely buggy with the driver, drivers should be resilient to bad hardware (sometimes they’re not).

You are probably dealing with a UAS issue. Another user on the Forvm had this issue as well, last week. Do a search for it but basically he had to blacklist the USB UAS driver loaded and fall back to regular USB driver. He added the blacklist entry to the modprobe.d directory.

UAS issue have become a thing in the 5.x kernel where previously it seemed to only be affecting ARM SBCs.

1 Like