I recently had to work with some very large files under Kubuntu 8.10 and found that when I was decompressing or copying these large files the system would become sluggish. Keep in mind this is with dual 3Ghz AMD cores and 4GB of RAM. The CPU load was almost nothing, but for some reason the disks were blocking the whole system.
Looking around, I wasn’t the only one to have this problem. It turns out Linux can use several I/O schedulers or “elevators”. The idea is to try to service disk requests as the heads go by instead of moving the heads back and forth for each request. There are 4 schedulers:
- noop – Don’t schedule
- anticipatory – Try to anticipate disk usage patterns
- deadline – Service requests if they haven’t been serviced by a deadline already
- cfq – Completely fair; this is the default in recent kernels
Turns out the cfq scheduler is what was doing it — not sure if it is a bug per se or just some interaction with my hardware. Anticipatory worked best for me. There are two ways you might change the schedule policy. At run time you can send the right string to /sys/block/XXX/queue/scheduler (where XXX is the device name). So if your main disk is /dev/sda you might say:
You can cat the same file to find out which one is current (it will be in square brackets). You can also edit your bootloader line to include the option elevator=XXX to set the system-wide default (XXX can be noop, as, deadline, or cfq — as is anticipatory).
I wrote a simple Gambas program using Gambas 2.9 to view and set the scheduler. It uses either kdesudo or gksudo to give you root privleges to write to the system file. I haven’t tried to distribute a Gambas program before — I know it depends on having Gambas in the system repositories and of the same version, so I’m not sure how useful it will be to others unless they are Gambas developers. None the less, I have a
and a available.