SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware 14.2 soon to be Slackware 15
Posts: 699
Rep:
Disk i/o slows down system
I've noticed for a long time that anything doing a lot of disk i/o can bring the system to it knees. This is usually when starting something like a VM or any program that loads a lot of stuff from disk at startup, so it's not a problem most of the time. However, if I have a backup process that is transferring stuff over the network to a storage device at the max rate of the network, which is only 1GB, it causes noticeable performance problem even though there is little cpu or memory being consumed.
(FWIW, Windows is if anything, worse. Something on Windows that hammers the hard drive bring Windows to it's knees just as bad if not worse.)
Is this just the nature of the beast? Are there any kernel options or other settings that can set disk i/o to a lower priority so it does not interfere with the real time operation of a desktop box?
i have found when writing heavily to the disk that holds the operating system is when the system will freeze.
so i always try to use at least a second hard drive to hold data, that way reading/writing to that is less likely to freeze the system.
I also notice major slowdown when I copy large files to USB flash drives through KDE (dolphin).
If I open a console and use midnight-commander to copy the same files to the same flash drive there is no slowdown...
Can I set default i/o with lower priority for dolphin or ioslaves on KDE? (tried ionice, didn't work)
For kernels after 2.6.26 with the CFQ I/O scheduler, a process that has not asked for an I/O priority inherits its CPU scheduling class. The I/O priority is derived from the CPU nice level of the process (same as before kernel 2.6.26).
So if you nice -n 19 whatever it is you're running it should have less of an impact on the responsiveness of the rest of your system while it's running. If you want to lower the priority even further you can put it in SCHED_IDLE using chrt -i and/or ionice -c 3, but usually I find the nice -n 19 more than sufficient to keep the system responsive.
As an example, I use the following in my kernel building script:
Another option might be to swap from the CFS to deadline scheduler, but whether that helps you or not may depend on the characteristics of your workload.
P.S. 'nice' priorities only work relative to other processes in the same cgroup, so if you're using cgroups you'll have to use the cgroup related mechanisms instead. This is one of the reasons I have for not liking cgroups, and by extension systemd which starts everything in its own individual cgroup.
So if you nice -n 19 whatever it is you're running it should have less of an impact on the responsiveness of the rest of your system while it's running. If you want to lower the priority even further you can put it in SCHED_IDLE using chrt -i and/or ionice -c 3, but usually I find the nice -n 19 more than sufficient to keep the system responsive.
...
Another option might be to swap from the CFS to deadline scheduler, but whether that helps you or not may depend on the characteristics of your workload.
was going to say the same
note that ionice only works with the CFQ
deadline, on the other hand, may or may not help
in general it will make the computer faster but it might cause hickups in real-time processes
another potential problem comes if the kernel does too much buffering (that i suspect OP may be experiencing)
that happened to me when copying huge files to usb, as the kernel would have to wait to flush to get some memory back
iotop could help diagnose, slabtop iirc and idk, forgot many of these already
Last edited by genss; 11-03-2015 at 02:25 PM.
Reason: invalid reference
Using legacy IDE mode rather than AHCI shouldn't impact perform that much. You're only dealing with how the disk is managed across the SATA bus. Usually things like disk thrashing from inadequate swap space are my main culprits, or a badly bottlenecked CPU, like a single core.
Try booting with hdparm enabled to optimize disk read/write, and try increasing your physical RAM as well. A new multicore CPU can help greatly. Having your swap space closer to the front of the drive helps also with speed.
Another option might be to swap from the CFS to deadline scheduler, but whether that helps you or not may depend on the characteristics of your workload.
I'll be the third to agree that trying this may resolve the issue. I've used CFQ for a while in the past and I did notice the same symptoms (system slowdown caused by disk I/O). As soon as I switched to deadline, it never happened again.
The way to fix a performance bottleneck is to add more capacity of whatever is causing the bottleneck. I suggest that you install a second hard drive and balance your disk I/O demand across the two drives.
This thread: http://www.linuxquestions.org/questi...ty-4175557039/ was very helpful to me when I had similar performance issues. Mapping out the bad blocks on my disk made a really big difference. There were a lot of bad blocks and I am about to replace the whole drive with a new one (which of course is twice the capacity and costs half as much as the original drive...)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.