0

This is a kind of vague question, and I apologize for that, but it's because of that vagueness that I'm not really sure how to perform a useful Internet search for it.

My problem goes like this: I have a machine running Linux on an ~700 GB hard drive (not an SSD), formatted with a couple of ext4 partitions. That hard drive is currently 89% used. I encounter this problem, and I think I have since I bought that hard drive, where I/O seems to be a huge bottleneck with my machine. I'll have simple tasks, like switching applications, trying to access the taskbar, opening a tab in a browser, lag for seconds or tens of seconds. The window manager itself, or something in the stack, seems slow to switch or repaint windows.

When I notice this lag and I examine "atop", I always see the disk I/O sitting at 100% busy. (It's not always 100% busy when the machine is not acting this laggy.) The process that is busy with the disk can be anything (systemd-journald, firefox, Xorg I think?) Running particularly intensive programs (and I do a lot of development, and often write logs to disk hundreds of MB large) seems to make this situation worse even after the programs exit. Restarting the computer seems to help (it's hard to be sure).

Broadly I'd like to know why this is happening, with my specific hardware and software, but (partly because I think it's a better way to ask the question) I want to know how to determine this for myself. I honestly have no idea how to figure out where these kinds of bottlenecks are, and it's not obvious to me it's just a problem of the hardware being insufficient.

I'm willing to accept my disk is old and needs replacement, and I'm sure an SSD would help no matter what, but I want to be sure that's really what's going on before I spend money on replacing it. [In particular, I do need a decent amount of storage space, and I can't really afford to make that all SSD.]

What makes me unsure is: (1) if my memory serves me correctly, I've had this kind of problem ever since I bought the disk (which I think was about 16 months ago), (2) I've done basic speed tests using hdparm -Tt, and the disk I/O speed, under normal conditions, doesn't seem to be any worse than other machines with hard disks, which aren't similarly obnoxiously slow.

What kind of heuristics, tools, benchmarks, etc., can I use for figuring out why my machine is so slow?

EDIT: More information about my machine, extracted from various tools:

zeb@terabithia:~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 698.7G  0 disk 
├─sda1   8:1    0 689.9G  0 part /
└─sda2   8:2    0   8.8G  0 part [SWAP]
sdb      8:16   0 111.8G  0 disk 
└─sdb1   8:17   0 111.8G  0 part /bridge

zeb@terabithia:~$ df
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/sda1      710941560 600381824  74376176  89% /
/dev/sdb1      114854440  25834416  83142676  24% /bridge

zeb@terabithia:~$ inxi -F
System:    Host: terabithia Kernel: 4.19.118-1-MANJARO x86_64 bits: 64 Console: tty 42 Distro: Manjaro Linux 
Machine:   Type: Desktop Mobo: ASUSTeK model: M5A97 LE R2.0 v: Rev 1.xx serial: <root required> BIOS: American Megatrends 
           v: 2301 date: 01/06/2014 
CPU:       Topology: 8-Core model: AMD FX-8350 bits: 64 type: MCP L2 cache: 2048 KiB 
           Speed: 4113 MHz min/max: 1400/4000 MHz Core speeds (MHz): 1: 4113 2: 4114 3: 4113 4: 4113 5: 4112 6: 4113 7: 4113 
           8: 4113 
Drives:    Local Storage: total: 810.43 GiB used: 600.04 GiB (74.0%) 
           ID-1: /dev/sda vendor: Seagate model: ST3750640NS size: 698.64 GiB 
           ID-2: /dev/sdb vendor: HP model: SSD S700 120GB size: 111.79 GiB 
Partition: ID-1: / size: 678.01 GiB used: 573.12 GiB (84.5%) fs: ext4 dev: /dev/sda1 
           ID-2: swap-1 size: 8.80 GiB used: 2.24 GiB (25.4%) fs: swap dev: /dev/sda2 
Info:      Processes: 294 Uptime: 10d 17h 34m Memory: 7.69 GiB used: 2.00 GiB (26.1%) Init: systemd Shell: bash inxi: 3.0.37 
4
  • Nice topic. Try to do cached read/write tests. Maybe there is some kind of cache memory defect. what is hdd model?
    – geoai777
    May 6, 2020 at 5:49
  • 2
    There are so many unknowns here, it's hard to know where to start. You say your disk is almost chock-full, but you don't say how big is your swap, how many swap partitions you have, what CPU, how much RAM, what Linux you're running, etc... I understand this is more an exercize in reflection than anything else, but your predicament could stem from one or more reasons that are specific to your machine and its hardware and software setup. The age doesn't mean anything: I'm posting from a 2011 Lenovo laptop running Windows 10, with 6GB of RAM clocked at 667MHz, and an SSD, and I'm a happy camper.
    – user1019780
    May 6, 2020 at 7:25
  • Also run SMART tests on the disk in case it is about to fail or throwing errors.
    – DavidPostill
    May 6, 2020 at 8:00
  • Thanks for the comments! I did use hdparm -T, as I said, and the results were comparable with other machines I tested. So it's not obvious that cache memory is the problem. I've tried to add more information about my system to the original post. I haven't run into any I/O errors in normal usage, but running a SMART test anyway sounds like a good idea. Thanks for the advice! May 7, 2020 at 15:24

1 Answer 1

0

I would check whether the RAM is full and if the swap is being used.

Try: free -m to check memory usage;

vmstat 1 5 to monitor various statistics; a high value in so and/or si column means swapping occured, that is the OS is using more memory than you physically have.

From your descriptions it is very much the symptom of not enough pyhsical RAM, I can't be sure until more information obtained. IMHO Linux memory management could be better, in some cases Linux keeps a large amount of disk cache where I think it should remove such cache to give space for application memory. If you have large amount of swap, but also large amount of buffer cache, you might want to experiment with kernel's swappiness settings (ref: https://www.howtogeek.com/449691/what-is-swapiness-on-linux-and-how-to-change-it/)

In other hand, there is a possibility that for some HDD models, the HDD firmware is the culprit. You might want to google your HDD model number, and for instance I found a firmware update here : https://www.seagate.com/id/id/support/kb/firmware-update-for-st3250310ns-st3500320ns-st3750330ns-st31000340ns-207963en/ But please take caution backing up your data, before updating your firmware.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .